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

Inge Wallin inge at lysator.liu.se
Sat Apr 19 01:28:18 BST 2014 

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


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.


CMakeLists.txt
<https://git.reviewboard.kde.org/r/117626/#comment39100>

    Bug: Also needs LIB_KOODF2



filters/words/docx/export/OdfTextReaderDocxBackend.cpp
<https://git.reviewboard.kde.org/r/117626/#comment39101>

    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.



filters/words/docx/export/OpcRelSet.h
<https://git.reviewboard.kde.org/r/117626/#comment39102>

    Or the other way around? These are not actually only ooxml relationships, they are general relationships for the Open Packaging Conventions. I suggest keeping it as it is for this patch and then merge the two into a general OPC library. This library will also be usable in filters for other formats that use Opc, which is a bunch.



filters/words/docx/export/words_docx_export.desktop
<https://git.reviewboard.kde.org/r/117626/#comment39103>

    Why only 2007? It's not clear which version of ooxml we are targetting. I suggest not changing this until we have decided.


- Inge Wallin


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/db642ae0/attachment.htm>

More information about the calligra-devel mailing list