fdo#61135 New feature in Calc: Stepped Lines graphs - first part of code submitted

[Michael Stahl]

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.