Improve RTF Import (RTF Tokenizer)

LibreOffice Writer’s import functionality basically has two forms. The old style ones are C++ filters are subcalled from the Reader class (for example: RtfReader for RTF, AsciiReader for ASCII, HTMLReader for HTML). The new style ones are implemented as an UNO component (for example: the writerfilter/source/ooxml directory for DOCX). There are currently two general problems with the RTF import filter:

Porting RtfReader to use the new filter framework has been started (see writerfilter/source/rtftok/), but is not yet done. This summer I would like to finish it.

Additionally - as time permits, after porting is done - I want to pick up features from RTF specification which are not yet supported by LibreOffice’s RTF import filter and add support for them.

When the project is completed, users who use the RTF import filter can have a better one: from a technical view it will use a more modern API, from a practical view, it’ll be improved in general.

I got the idea of working on this because when I did the RTF export filter, I had to use Microsoft Office to test the result. Also, whenever a user saves a document in RTF, then opens it, all the benefits of the new exporter goes away, as the importer does not understand those new features. This gave me a feeling that improving RTF support would be a good idea in general.

Regarding implementation, I want to take the DOCX import filter as an example (without over-complicating it!) and implement the new RTF filter in a similar way - but of course heavily based on the current RtfReader implementation where it makes sense.

I don’t know exact details, because I haven’t (yet) read the started RTF tokenizer nor the relevant part (writerfilter) of the LibreOffice API, but I expect to read and understand the code from the sw/source/filter/rtf directory and I want to place the new RTF code under writerfilter/source/rtftok, where the DOCX one already is.

I’m aware that it would be possible to use XSL transformations to create a new RTF filter as well, but not ignoring performance aspects and my (quite weak) XSLT knowledge, I decided to create a C++ filter.

So I would like the first version of the new RTF filter ready by the time of mid-term evaluation, then I can work out the minor problems, write documentation and if time permits - implement new features from the specification in the second half of the summer. I used concrete dates so that I can be checked easily if I’m on track, but of course I may finish with a given part a bit earlier or I may have a little delay.

I’m a student in Hungary, and here the exam period is between 2011.05.23 and 2011.06.20. Sadly this has a big overlap with the Summer of Code, which starts on 2011.05.23. I’m aware of this and last year I managed to get over this as well. I plan to work on my project 40 hours a week, which permits to spend entire days on my project, then work nothing a few days before the exam. I don’t know the exact date, but probably after the mid-term evaluation I’ll have a week of holiday. I think once I returned I can work more productive on my project with a fresh mind, compared to going nowhere during the whole summer.

My experience is that IRC is handy for quick questions, but sometimes email is better to communicate in an asynchronous way. I also like writing each day about what did I do in a blog-like form. If this is OK for my mentor, then I would like to use these for this project as well.

I’m doing trivial git-related (or other areas where I’m familiar with the codebase) small fixes before the SoC starts, just to get used to the new build system, etc. I plan to work 40 hours a week during the SoC. (Well, basically. I do not use a timer, the average is about something like this.) I don’t know the future, I hope I can do some contribution after SoC as well.

I don’t know anything about it so far, but I’m sure there will be new ideas during the implementation of the project. I’m sure I’ll at least document these ideas once the project is finished, so I or others can work on them after the end of SoC.

As every average Linux user - I’m using LibreOffice on a daily basis, to read/write/convert any non-ascii document (well, except PDF). I use Writer / Calc / Impress whenever the document is not long/technical enough that using Latex worths considering.

I expect that I’ll need to write C++ code during the project. I contributed to various projects written in that language, most notably I added a new RTF exporter to Go-oo last summer, which was implemented in about 8000 lines of C++ code.

I’m a Linux guy, I used OS X for a long time (but not currently), mainly for testing purposes as well. I do not really use Windows, but I have one installed in a virtual machine (can be useful when I want to see what MSO exports in RTF to feed it to the RTF importer :-) ). I’m familiar with gcc and make, I used autotools for other projects previously as well. I’m familiar with git as well, but I’m quite new to LibreOffice’s new build system (though right now writerfilter uses dmake, it seems).

I’m hanging around on #libreoffice-dev, and I’m subscribed to the developer mailing list.

Education: Completing an M.Sc. degree in Computer Science (to be finished this year, December - final exams in January) at Budapest University of Technology and Economics. I work for SZTAKI (http://www.sztaki.hu/?en, part time - 1 day in a week, since 2004). I have a page with a few minor projects: http://vmiklos.hu/projects/

A have a page with links to patches I contributed to other FOSS projects: http://vmiklos.hu/portfolio/ Mostly minor code and/or documentation fixes. I contributed a few more complex patches to the pacman package manager, the bitlbee IM gateway, Git, SWIG and OpenOffice.org (these are C and C++ projects). I’m generally a bash, C/C++ and Python guy. I know some perl/Java/XSL as well.

vmiklos