On Monday, November 12, 2012 15:45:07 Jos van den Oever wrote:
> On 11/12/2012 03:34 PM, Inge Wallin 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?
>
> The manifest.xml lists what files are in the ZIP. In the flat file
> format you do not need manifest.xml at all. Also the file 'mimetype' is
> not present, the mimetype is an attribute in the root element.
So the mimetype is an attribute of each embedded object? If not, I still don't
fully get it. How do I know what data type this nice content - a blob of
bytes - of my draw:frame is? Do I have to try to deduce it from the blob
itself?
>
> Cheers,
> Jos
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
