"Uncompressed XML Files" format variants

[Jaroslaw Staniek]

I'd like to propose to add a cmake option, off by default, making it
available regardless of presence of DEBUG flag. I bet distros do not
touch advanced options, so the effect shall be positive.

On 12/11/2012, Inge Wallin <inge at lysator.liu.se> wrote:
> On Monday, November 12, 2012 15:31:00 Jos van den Oever wrote:
>> On 11/12/2012 03:26 PM, Inge Wallin wrote:
>> > On Monday, November 12, 2012 15:22:01 Jos van den Oever wrote:
>> >> On 11/12/2012 01:34 AM, Friedrich W. H. Kossebau wrote:
>> >>> Hi,
>> >>>
>> >>> I would propose to remove the option "Uncompressed XML Files" for
>> >>> non-
>> >>> developer buils, or positively said, only enable it for developer
>> >>> builds. Reasoning:
>> >>> * only confuses the user ("what is the difference to compressed?")
>> >>> * cannot be opened in other ODF programs
>> >>> * results in data without a mimetype, so badly shown in
>> >>> filemanagers/-dialogs * no/wrong thumbnails (for content.xml or
>> >>> directory)
>> >>>
>> >>> Anyone objecting to this? If not, I will finish/prepare a patch and
>> >>> upload for review which adds support for uncompressed/directory store
>> >>> formats only in developer-like builds. Such a build I assume if
>> >>> NDEBUG
>> >>> is _not_ set. Or any better idea what the condition should be?
>> >>>
>> >>> And while I twist around with that code I would like to change what
>> >>> filename is used as id for a document in uncompressed files format,
>> >>> which is currently "content.xml". But this id is also used in the
>> >>> window title and in the recent documents list so it makes life not
>> >>> easy if there is multiple times just "content.xml". I would change
>> >>> the
>> >>> code to use the name of the base dir instead.
>> >>
>> >> LibreOffice support fodt (the whole contents in one xml file) and a
>> >> standardized way to store ODF in a flat XML file. Using that format
>> >> instead of the current uncompressed format seems like a good
>> >> compromise
>> >> which will still allow people to store the files in a version control
>> >> system nicely.
>> >
>> > Didn't you say that there are features in odt that are not supported by
>> > fodt? I forgot the details but I think it would be good to have the
>> > info
>> > before we make the decision.
>>
>> The mayor missing feature in the flat format is RDF, simply because
>> including that has not been specified for 1.2. There is not much else
>> that is not supported by the flat format. The flat format basically
>> combines meta.xml, settings.xml, content.xml and styles.xml into one
>> file. Obviously the files will be larger and bitmap images will be
>> embedded as base64 which is not so pretty.
>
> How about manifest.xml? Or is type info stored in some other way?
>
>> Cheers,
>> Jos
>>
>>
>> _______________________________________________
>> calligra-devel mailing list
>> calligra-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>


-- 
regards / pozdrawiam, Jaroslaw Staniek
http://www.linkedin.com/in/jstaniek
Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
KDE Software Development Platform on MS Windows (windows.kde.org)