"Uncompressed XML Files" format variants

[Inge Wallin]

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