Currently attending the Libre Graphics Meeting in Wrocław - incredible congregation of bright people from vastly different areas. Well worth the visit.
-
« Home
Pages
-
Categories
-
Archives
Category Archives: OpenOffice.org
Most of the external header guards now removed from the OOo source tree.
This was a great week! After some days of congregation with the Novell team (hacking, planning, team building, late-night-bar-takeovers), the week was topped off by the public GoOOCon on Friday and Saturday with some very interesting talks. Nice to meet all the (also non-Novell) OOo hackers in person again - and had the most intense & exciting moments since quite a while when flying in mid-air about 10 meters above the ground:
Legend: climbing the 10-meter-pole, on which to stand & then jump across a largish gap to a swing. Last image: the surviving crop of GoOOers - we lost a few of them in action 
Big thanks to everyone who contributed, and especially to the local organizers Kendy, Petr & the SuSE Prague team!
After some folks asking about portability of OOo to mobile devices (and even good old Amiga), I decided that we need a canvas implementation that runs everywhere (or should I even say WORA?). Naturally, that entails a few compromises in rendering speed and quality, but OOo users are already pretty well adapted to ugly rendering & UI - or are they?
At any rate, I decided that probably the most ubiquituous output device technology is the the text terminal, spanning decades of IT hardware and orders of magnitude in computing power - portability at its best! Antialiasing on these kind of devices is a bit hard, but luckily OOo is not quite up to make use of it , anyways. Thusly, our office users don’t miss out on anything, quite the contrary - as I now expect a slew of ports to all those nifty mobile phones, pocket PCs etc…
So, based on the excellent libcaca, here are some first promising asciicanvas results:
This parable gave me a good laugh this morning!
Two weeks ago, I had the privilege to work on a fun project using company time - it was Novell HackWeek again. So I teamed up with friend & colleague Fridrich to finally get OOo its long-deserved built-in SVG import - in fact, this is the most voted-for feature of the whole project.
So we started off of kendy’s work in ooo-build, and hacked up a native C++ component (the external implementation unfortunately has strong dependencies on Java5 and Batik, and is GPL-licensed - but great work, and a piece still superior in import quality) that sucks in a DOM tree from the SVG file, subverts that into a temporary container for ODF styles (which, unfortunately, needs to be written before referencing them in a flat ODF file), and then pushes out events for a SAX parser, which has the nice side effect of making standalone svg-odf conversion trivial (in fact, a svg2odf command line tool is on my disk). This stuff has been committed to ooo-build.
What’s working? See for yourself:
What’s missing yet: text and gradients are clearly very noticeably lacking - though this is luckily totally unapparent from the screenshots
We’ll keep working on this in our spare time, so there’ll hopefully be updates soonish. It would just be great to take advantage of the vast amount of svg cliparts out there - without needing to convert them to png, as OOo currently does…
While updating the OOo coding standards in late 2006, especially the IncGuards item sparked some discussion about why not removing all those existing external guards. Kendy quickly came up with a removal script, but a few tests showed that builds using the old wntmsci10 (MSVC 2003) compiler became significantly slower (external header guards had originally been put there for performance reasons). Since Hamburg RelEng, as the main victim of increased build times, now switched to MSVC 2005, it’s about time to bin these warts - currently committing the bulk of the changes to CWS incguards01.
I hereby happily announce that starting this Friday, I’ll be part of the great OpenOffice.org team at Novell. Being fully home-assigned and saving the ~2 hours commute every day, I can now hopefully push my hidden gsl agenda even more.
While hunting down broken images in the pdf import, I came across a very weird behaviour, that was seemingly caused by plain C stream IO: every once in a while, streams that were explicitely opnened in binary mode converted 0×0A into 0×0D. One-on-one substitution, not the usual 0×0A to 0×0A 0×0D lineend conversion, notably. I wasted about a day trying to track that down, suspecting everything from crazy filesystem flags, to symbol hijacking during link time (i.e. somebody sneaking in own fwrite/putc/whatever into the binary). Laboriously ruled out one after the other.
Finally, I did what I should have done in the first place: I used a different hex editor. And lo and behold, the trusty midnight commander showed all the files with correct 0×0A. Caught in the act and proven guilty: emacs’ hexl-mode.
Well, kind of. It turned out to be a rather unlucky combination of things going wrong: emacs with its buffer encoding scheme, which tries to be smart and detect the actual encoding - if there’s a 0×0A in the file before a 0×0D, emacs assumes raw-text-unix and leaves line ends alone. If there’s a 0×0D in the file before any 0×0A, emancs assumes raw-text-mac, and converts all assumed lineends to 0×0D. And since hexl-mode seems to work on top of an existing buffer (and never loads the file directly from disk), this resulted in the described mess.
So, to save yourself some trouble: don’t trust your tools. And make sure to have files you want to work on with hexl-mode match something in file-coding-system-alist’s content, that enforces binary reads (elc, png, jpeg, ar, gz etc. for my setup).
