Valamiért sose fogott meg a japán anime műfaj, de erről annyi pozitívumot olvastam, hogy megnéztük. Tényleg nem rossz.

(imdb, trailer)

When using text frames in Writer, you can always choose if you set an absolute size for it or you set a relative one. Oddly enough, in case of relative sizes, it wasn’t entirely clear what 100% percent means. With a bit of searching, the help says "it’s the page text area", which in practice means the page size, excluding the margins.

And that’s where the problem lies: in many cases (importing foreign formats, cover page of a document, etc.) you want to have a textframe which is 100% wide, compared to the full page size, including margins. It was already possible previously to work this around by manually specifying the same size what was used for page size, but that’s ugly, you duplicate the setting at two places.

As you can see on the above screenshot, in LibreOffice 4.3, I now implemented this as a new option, you can choose what 100% means for both width and height. File filters are also updated accordingly: in case of ODF an extension is proposed, and also DOCX and RTF filters are updated, where the file format already supported this feature.

For the curious ones, the feature is in master for almost two months now, but I only implemented my favorite part — RTF filter — only last week, that’s the "news" here. ;-)

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 this improvement! :-)

Délelőtt a Kavicsos-tónál jártunk, illetve egész pontosan erre. Az ötletet a holkerekparozzak.hu egyik GPS trackje adta, azt leszámítva, hogy ténylegesen a tököli reptér mellett simán úgy elmentünk, hogy észre se vettük…

Jah, és még egy érdekesség: miért van Közvágóhídnak elnevezve ez meg az a megálló is? ;-)

I’m sure in this case a few words are worth more than the above picture, so let me describe what you see above. :-)

In case of opening an ODT, DOC or RTF document in LibreOffice Writer, you already got some feedback on where the importer is, in case the process needed more time than what you feel "instant". However, this wasn’t supported for DOCX. According to git blame, I added this to my todo on 2012-10-29, and a few months later also a bugreport was opened, requesting the same, but up to yesterday, nothing changed. However, now I’ve implemented this on master, it’ll be part of the 4.3 release.

Back to where I started, what you actually see there is when LibreOffice is in the middle of the import process of the Holy Bible in DOCX format, which takes around 12 seconds on my machine. One could say that speed up quite acceptable for that amount of data, but with a progressbar, it’s definitely better. ;-)

Ma láttam ezt a filmet, csak ajánlani tudom. Tipikus példája annak, hogy annak ellenére, hogy ez 8.1 pontot kapott IMDB-n, míg pl. A Wall Street farkasa a 8.4-et, mégis nekem az egyértelműen jobban tetszett.

Pedig nem volt benne se orrvérzésig kokózabálás, se szaporodás, és még szakkifejezésből is alig. :-)

(imdb, trailer)

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 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:

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.

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.

If you want to try this out, core.git has a ODT and DOC samples to play with.

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. ;-)

(wikipédia, musicalinfo)

I’ve arrived home yesterday from Brussels where I presented at FOSDEM 2014, in the Open document editors devroom.

We also had a Hackfest, kindly hosted by Betacowork on Monday and Tuesday.

Here are a few talks I enjoyed, not counting the LibreOffice ones:

I was also happy to meet Jacobo, Matus, Tim and Tomaž finally personally. :-)

Quite some other slides are now available on Planet, don’t miss them. I also took some pictures, available here, including photos of all speakers in our devroom.