On 08/03/13 09:55, Markus Mohrhard wrote: >> On Wednesday 06 March 2013 17:00:56 Markus Mohrhard wrote:
>>> The import for files written by gnumeric should map the values to the >>> corresponding ODF values and during export we only want to export them >>> as ODF and never into the gnumeric namespace. This also means to >> >> OK. I thought that it would be nice for somebody that wrote the file with >> Gnumeric not to silently convert it to something that might not be read back >> the same in Gnumeric. That's why I added all these GNM_* values. But I can >> understand your POV. the problem is that an attribute can have only one value, and it's far better in the long run to write the value that is in a current ODF draft than the value that will only be understood by Gnumeric. >>> remove all the references to the GNM_* values in the other source >>> files. For that to correctly work we need to register the gnumeric >>> namespace and map the elements in the chart namespace and the elements >>> in the gnumeric namesapce to the same UNO attributes. >> >> Could you explain this a bit more. Are we talking about the XML namespace or >> the C++ namespace ? I see some references in the code related to Gnumeric >> and a link with orcus. > > We are talking about XML namespaces. The gnumeric elements with gnm > prefix are in an gnumeric namespace. The other links you see to > gnumeric code is in calc and orcus for the gnumeric import which is > only a proof of concept right now. you have fallen into the same trap as i have 2 weeks ago: the "gnm:" prefix is part of the value, not any attribute or element name, and thus no namespace needs to be declared to support it. >>> into the gnumeric namespace. Additionally we need to take care of the >>> ODF version during export and make sure we only export it into ODF1.2 >>> extended. I think Thorsten was fine with exporting the elements into >>> the chart namespace but only for ODF 1.2 extended. >> >> First a general question. I found the option for selecting the ODF type. But >> how does that work when somebody requires, e.g., strict ODF1.2 or lower >> compliance. Is there a warning given when the file is written ? Do we hide >> the option for stepped lines then ? > > We warn the user that choosing anything except ODF 1.2 extended may > loose data but we don't hide anything in the UI. We just drop the > elements during export. in the latter Sun days there were plans to query the ODF version from the configuration in the UI and only allow inserting those content elements that are supported by the selected ODF version. i can't remember if anything was ever implemented for that, but in general it would be a good idea. (except it would not be worth the effort for 1.1 because there is just too much missing there; it was only intended for post-ODF 1.2 features). >> Secondly, can you point to an example where the above is done ? Then I can >> implement something similar. > > Sadly this one is a bit tricky. Normally the magic happens in how we > specify the attribute values in the map but for this one I need to > explore it a bit more. some maps have an additional element to store the required version which is then checked on export but apparently this one does not (yet). for example there is a MAP_ENTRY_ODF_EXT macro in that PropertyMap.hxx... oh actually that applies to entire attributes while here we want to only handle certain values of the attribute differently... i guess it needs some "special" handling then, there is some flag MID_FLAG_SPECIAL_ITEM_EXPORT which causes a call to the handleSpecialItem() method, which can then mangle the attribute in arbitrary ways, so you can use it to generate appropriate fall-back values for older ODF versions. also, your changes to xmloff/source/transform/StyleOASISTContext.cxx seem a bit pointless to me: source/transform is for the OpenOffice.org XML format, which is a predecessor of ODF and a legacy format and usually does not get new features added :) well i guess nobody will complain about some different values there. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice