Review Request 117626: Implement the first version of a DOCX export filter

Jarosław Staniek staniek at kde.org
Sat Apr 19 19:53:23 BST 2014 


> On April 19, 2014, 12:28 a.m., Inge Wallin wrote:
> > Hi Jaroslaw. Thanks for a super thorough review, this is much appreciated!
> > 
> > When it comes to your comments to merge with libmsooxml, I suggest the following course: Keep it as it is for now, and then in a separate patch identify common functionality and merge them. Reasons:
> >  - The patch is already quite big and would be even bigger if we start to hack in libooxml too. I suggest to keep each patch focused.
> >  - The ooxml library is very heavily slanted towards reading ooxml, not writing it. I remember looking at it early and finding that changing the code there would be bigger. Some data structures in libmsooxml need to be changed too for dual purpose (read+write).
> >  - We should move everything that has to do with OPC out into it's own library which can also be reused for other filters.

Sure, feel free to split this into steps as described. I recommend using the Branch field of the reviewboard to indicate this is a certain patch for a feature branch.

Incremental refactorings come while subsequent features get implemented. This was the case in the OOXML import and most likely would be also in case of export. 


> On April 19, 2014, 12:28 a.m., Inge Wallin wrote:
> > filters/words/docx/export/OdfTextReaderDocxBackend.cpp, line 112
> > <https://git.reviewboard.kde.org/r/117626/diff/1/?file=266875#file266875line112>
> >
> >     There is a paired endElement(). Look below in the else branch.  This backend method is called twice by the reader: When the tag starts and when it ends.  So we need to write <w:p> into the docx file when the text:p starts in the odt, and </w:p> when the text:p ends in the odt. But in between we need to convert the contents of the text:p, which is done by other methods in this backend.
> >     
> >     I have thought of developing macros like your READ_* in the ooxml import filters. But you have hard coded your readers for the filters and we have split up the process into a reader class and a backend class. This makes the reader reusable with other backends (see the ascii export filter for an example) and this makes the macros only usable in the reader itself. 
> >     
> >     I'm all for it if you can find a good set of macros but I don't think it's in the scope of this patch.

Most likely scenario is that more code appears and I am trying to refactor using convenient new macros that fit best. That's how the OOXML import got incremental refactoring. I am not pushing for reuse where 2 lines would be reused, that would be done if clear benefits appear, sure.

So far I tried to also look at using same terms where possible. It may be that something is still missing but we clearly want to use consistent terms and techniques both for import and export :)


- Jarosław


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117626/#review56042
-----------------------------------------------------------


On April 18, 2014, 9:38 a.m., Inge Wallin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117626/
> -----------------------------------------------------------
> 
> (Updated April 18, 2014, 9:38 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> -------
> 
> This patch implements the first simple version of a docx export filter. It has support for simple character formatting and paragraph formatting, including named styles. It can also distinguish between headers and normal paragraphs [This turned out not to be true when I look at the code in the RR now. But it will be before it's merged. We will concentrate on this now]. Other than that it's an unwritten page.  A special thanks to Lassi Nieminen who helped me with converting the styles.
> 
> The patch itself is very straightforward and mostly self contained in the filters/words/docx subdirectory. It builds on my previous work with libodfreader and libodf2, which are both in filters/. The only problem was that the KoZipStore and KoEncryptedStore backends create a file called "mimetype" automatically when a KoStore is created in write mode. I tried to work around this with as little impact as possible to the code in libs/odf and with full source compatibility with the previous API. If you think there is a better way to solve this problem than the one I implemented, then please tell me.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 78421c5 
>   filters/libodf2/KoOdfStyle.h 558ade9 
>   filters/libodf2/KoOdfStyle.cpp 2b4eb95 
>   filters/libodf2/KoOdfStyleManager.h 3761d38 
>   filters/libodf2/KoOdfStyleManager.cpp a7f18a2 
>   filters/libodf2/KoOdfStyleProperties.h 1bfbb5c 
>   filters/libodf2/KoOdfStyleProperties.cpp 186e971 
>   filters/libodfreader/OdtReader.h 64e0584 
>   filters/libodfreader/OdtReader.cpp 6fa8ce6 
>   filters/words/docx/CMakeLists.txt f38a2bb 
>   filters/words/docx/export/CMakeLists.txt PRE-CREATION 
>   filters/words/docx/export/DocxExport.h PRE-CREATION 
>   filters/words/docx/export/DocxExport.cpp PRE-CREATION 
>   filters/words/docx/export/DocxFile.h PRE-CREATION 
>   filters/words/docx/export/DocxFile.cpp PRE-CREATION 
>   filters/words/docx/export/DocxStyleHelper.h PRE-CREATION 
>   filters/words/docx/export/DocxStyleHelper.cpp PRE-CREATION 
>   filters/words/docx/export/DocxStyleWriter.h PRE-CREATION 
>   filters/words/docx/export/DocxStyleWriter.cpp PRE-CREATION 
>   filters/words/docx/export/FileCollector.h PRE-CREATION 
>   filters/words/docx/export/FileCollector.cpp PRE-CREATION 
>   filters/words/docx/export/OdfReaderDocxContext.h PRE-CREATION 
>   filters/words/docx/export/OdfReaderDocxContext.cpp PRE-CREATION 
>   filters/words/docx/export/OdfTextReaderDocxBackend.h PRE-CREATION 
>   filters/words/docx/export/OdfTextReaderDocxBackend.cpp PRE-CREATION 
>   filters/words/docx/export/OdtReaderDocxBackend.h PRE-CREATION 
>   filters/words/docx/export/OdtReaderDocxBackend.cpp PRE-CREATION 
>   filters/words/docx/export/OpcContentTypes.h PRE-CREATION 
>   filters/words/docx/export/OpcContentTypes.cpp PRE-CREATION 
>   filters/words/docx/export/OpcRelSet.h PRE-CREATION 
>   filters/words/docx/export/OpcRelSet.cpp PRE-CREATION 
>   filters/words/docx/export/OpcRelSetManager.h PRE-CREATION 
>   filters/words/docx/export/OpcRelSetManager.cpp PRE-CREATION 
>   filters/words/docx/export/README PRE-CREATION 
>   filters/words/docx/export/UnitConversions.h PRE-CREATION 
>   filters/words/docx/export/UnitConversions.cpp PRE-CREATION 
>   filters/words/docx/export/words_docx_export.desktop PRE-CREATION 
>   libs/odf/KoDirectoryStore.h 19c059d 
>   libs/odf/KoDirectoryStore.cpp c893d47 
>   libs/odf/KoEncryptedStore.h 0edd892 
>   libs/odf/KoEncryptedStore.cpp 315df1a 
>   libs/odf/KoStore.h dadecd1 
>   libs/odf/KoStore.cpp fd42378 
>   libs/odf/KoStore_p.h 2e518c1 
>   libs/odf/KoTarStore.h d99f09b 
>   libs/odf/KoTarStore.cpp 6829f34 
>   libs/odf/KoZipStore.h 90ffcb0 
>   libs/odf/KoZipStore.cpp 4235134 
> 
> Diff: https://git.reviewboard.kde.org/r/117626/diff/
> 
> 
> Testing
> -------
> 
> Testing with a number of odt files. Lassi did all the testing involving MS Office since I don't have that.
> 
> 
> Thanks,
> 
> Inge Wallin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20140419/ea8166a7/attachment.htm>

More information about the calligra-devel mailing list