Last year in September we decided to get rid of the writerfilter-based DOC tokenizer, and I volunteered to actually do this. As cleanups in general have a low priority, I only progressed with this slowly, though yesterday I completed it, that’s why I’m writing this post. :-)
Some background: the writerfilter module is responsible for RTF and DOCX import in Writer. As the above picture shows, the currently used DOC import is independent from it, and there was also an other DOC import filter, that was in writerfilter which was disabled at runtime. As I don’t like duplication, I examined the state of the two filters, and the linked minutes mail details how we decided that the old filter will stay, and we’ll get rid of the writerfilter one. It’s just a matter of deleting that code, right? :-) That’s what I thought first. But then I had to realize that the architecture of writerfilter is a bit more complex:
It has the following components:
the dmapper (domain mapper), that handles all the nasty complexities of mapping Word concepts to Writer concepts (think of e.g. sections ↔ page styles)
one tokenizer for each (RTF, DOCX, DOC) format
The traffic between the tokenizers and dmapper is called tokens. Naturally it’s not enough that tokenizers send and dmapper receives these tokens, they should be defined somewhere as well. And that’s where I realized this work will take a bit more time: instead of having a single token definition, actually the ooxml tokenizer defined its own grammar, and doctok also defined two additional grammars. And of course dmapper had to handle all of that. ;-) Given that OOXML is a superset of the DOC/RTF format, it makes sense to just use the ooxml grammar, and get rid of the other two.
Especially that — by now you probably found this out — if I wanted to kill doctok, I had to kill the sprm and rtf grammars as well. Otherwise just removing doctok would break the RTF and DOCX import as well, as those also used the rtf/sprm grammars.
So at the end, the cleaned up architecture now looks like this:
And that has multiple advantages:
It removes quite some code: In
libreoffice-4-1, the doctok was 78849 (!)
lines of code (well, part of that was XML data, and some scripts generated
C++ code from that).
dmapper now doesn’t have to handle the rtf and sprm grammars anymore, so now there is a single place in dmapper that handles e.g. the italic character property.
Smaller writerfilter binary for the end user: even if doctok wasn’t enabled at runtime, it was shipped in the installation set.
Hopefully it’s now a bit more easy to understand writerfilter: at least e.g. if you want to look up the place where dmapper handles the character bold ("b") XML tag of OOXML, you don’t have to know that the binary DOC equivalent of that is sprmCFBold, just because we have an unused DOC tokenizer there as well. :-)
Given that DOC and RTF formats are a dead end, I think it’s a good thing that in writerfilter now the grammar is OOXML (that keeps introducing new features), rather than some dead format. ;-)
Leginkább a The Social Networkhöz tudnám hasonlítani ezt a könyvet, itt se törekedett a szerző arra, hogy csak pozitív vélemények jelenjenek meg a könyvben, sőt. Talán ami a legjobban tetszett benne az pont ez: azzal, hogy Jobsot rendszeresen bírálja a fekete-fehér látásmódja miatt, maga a könyv sokkal árnyaltabb képet fest az emberről, és így nekem hitelesebb is.
Friday, 28 February 2014
LibreOffice Writer now supports nested comments in its DOC/RTF filters (Comments)
If you ever tried to use nested comments in Writer (make a selection, Insert → Comment, then make an overlapping selection, and do it again), you may have noticed that only the ODF filter can load and save such a document properly. Recently I have improved this situation a lot. Motivated by seeing this is now supported in the DOCX import filter, I now added support for this also to the DOCX export, RTF import/export and binary DOC import/export filters.
Múlt hét elején láttuk ezt a darabot, egy mondatban a Kontrasztkiállítás színpadi adaptációjaként tudnám jellemezni, de mivel musical, azért ez kicsit emészthetőbb és élvezetesebb volt. ;-)
Here are a few talks I enjoyed, not counting the LibreOffice ones:
Simplifying reuse with metadata support in ODF and plugin APIs — finally a simple way to copy&paste images from Firefox to LibreOffice with source attribution.
Combining the power of Valgrind and GDB — useful to know about this possibility
Two uses cases for the clang C++ parser: Online Code Browser and Qt moc Replacement. — maybe the first could replace our crappy Java-based opengrok? We’ll see.
I was also happy to meet Jacobo, Matus, Tim and Tomaž finally personally. :-)
Ha nem szerepelne a filmben Béla (Eperjes Károly) karaktere, biztosan azt hittem volna, hogy ez a film valójában még a rendszerváltás előtt játszódik. Leginkább a Szamárköhögésre emlékeztet stílusában, talán nem is véletlen, hogy a Nagyit mindkét filmben Töröcsik Mari játssza…
Amúgy az hogy van, hogy IMDB-n '92-es, port.hu szerint viszont '90-es a film? ;-)
Saturday, 11 January 2014
OOXML shape improvements in LibreOffice Writer 4.3 (Comments)
Although LibreOffice 4.2.0 is
not yet released, it was
already branched off from
master in November last year, and improvements for
the next release are already cooking in
master. One of these will be a major
improvement of shape handling in the DOCX import/export filter.
Some background: when DOCX was initially introduced, it still used VML (which is in short an XML equivalent of the binary shape format), and only Word 2010 started to write shapes using drawingML. Given that Word still understands VML, it wasn’t urgent for us to write shapes using the drawingML markup. As for import, Word still writes an approximate version of the shape in VML as a fallback — that’s what we read till now. Needless to say, newer drawingML features have no VML equivalent so with time it became more and more important for us to finally read and write shapes in DOCX using drawingML, which just happened in Writer.
I’m posting here a few screenshots showing the improvements I’ve implemented. Note that final 4.3 is still far from being released, so this is not a complete list. :-) In each case I’m providing a screenshot showing how it looked (at the end of an import/export/import again roundtrip) before, how it looks now in 4.3 and the reference layout. Click on the images to get a larger image:
document with different colors (test doc):
OK, this has four pictures: before, now, Word 2007 and Word2010. As you can see now we’re now on par with Word 2010. ;-)
document with textboxes inside a group shape (test doc):
document with a shape having a custom adjustment (test doc):
document with different colors (test doc):
If you want to try these out yourself, get a daily build and play with it! If something goes wrong, report it to us in the Bugzilla, so we can try fix it before 4.3 gets branched off. Last, but not at least, thanks for CloudOn for funding these improvements! :-)
A szituáció abszurdságát tekintve akár "adathalászat Jemenben" is lehetett volna a film címe, de a film végére a nézőt valóban érdekli, hogy a lazacok úsznak-e felfelé. ;-)
You may remember that I wrote about my little
ged2dot project about two months ago.
It’s a Python script that can be used from commandline with quite some
options. I’m happy to announce that there is a GUI for it now, in the form of
a LibreOffice Draw import filter. If you open
file, you’ll see something similar to the above image. You can simply build
.oxt from the Git repo, or just get
it from the
Technical details for the interested readers: the import filter just glues
together existing pieces. First it runs
dot to generate an
SVG. To keep things simple, then the filter "inlineizes" all the included
images, finally the already existing SVG import filter does the real work. I
find it elegant that each step works from and to the memory, and not ugly
temporary files. :-) It works on Linux and Windows, feedback on if it works on
Mac is appreciated.
Also, if you ask why this is an extension, not part of LibreOffice core: I guess most users are not interested in building family trees; also being someone who works on the core most of the time, I wanted to try out how implementing an import filter as an extension (filter detection, import options dialog, etc.) works. ;-)
Eredetileg azért érdekelt a film, mert kíváncsi voltam, mi adta a névötletet a hasonló nevű "sorozathoz", amit kifejezetten értékesnek tartok. A film se rosszabb, bár kevesebb százalékban szól túrázásról.