Input for ODF plugfest/TC call

[Thorsten Zachmann]

On Thursday, April 19, 2012 13:48:52 you wrote:
> Hi,
> 
> so here my list of issues that I have had with ODF so far. Please consider
> putting them on the table for the plugfest as well as for the TC call :)
> 
> 
> A) no official test suite
> B) spec vs. reality: how to handle files from broken ODF producers
> C) no feedback on office-comment list
> D) handling of custom shapes just a hack ATM?
> E) things I would have posted to the office-comment list if it felt live
> 
> 
> A) No official test suite
> 
> As discussed on the ml, would be really good to have that, similar to what
> there is for SVG at least.
> The "OpenDocument Fellowship Test Suite" as used e.g. for
> http://officeshots.org/galleries/view/opendocument-fellowship-test-suite
> might be a start.

I think the biggest problem here is that everybody would be happy to have 
something like that, but not to many have the time to create it. It is quite 
time consuming to create a test suite when you want to create files that are 
not done in a specific implementation.

> B) Spec vs. reality: how to handle files from broken ODF producers
> 
> E.g. LO (and so might OOo) do not meet the ODF 1.2 spec, section 19.228
> draw:transform, where it says skewX/skewY should be given in degrees.
> Instead they store the angle value as radian (and in clockwise direction)
> (bug filed for LO as https://bugs.freedesktop.org/show_bug.cgi?id=48342).
> And Calligra follows that behaviour.
> 

I did investigate a bit and in the 1.1 version of the spec it was not 
mentioned in which system the angle where given. I have create bug report 

http://tools.oasis-open.org/issues/browse/OFFICE-3750

> Things like this screw the ODF spec. It needs to be handled.
> But how?
> * Fix ODF producers to produce spec-complying documents, and have consumers
> detect the producer version and handle the read values by the version?
> * Adapt the spec to reflect reality?
> 
> Anyway, the current behaviour of the spread ODF producers IMHO should be
> added as note to the spec, so implementors of ODF consumers know what to
> expect.
> 
> 
> C) No feedback on office-comment list
> 
> The official comment mailing list feels like writing to /dev/null. While
> there is an automated monthly reminder which has this section
> --- 8< ---
> 3)  The TC has agreed to consider all submitted comments, regardless of
> when they were submitted.  Although you may not receive an immediate
> response from the TC, be assured that your comments have been archived on
> the list, and you can track their resolution via JIRA, as explained below.
> --- 8< ---
> there has not been any official reply from the TC or any JIRA related
> follow- up, at least visible in the the archives for the emails since Jan.
> 1st 2011 and personally on the emails I posted there the last months.

As far as I know the JIRA should be publicly visible.

> D) Handling of custom shapes just a hack ATM?
> 
> The current storage looks like a hack to me, it is no-where specified in
> the spec, is it? And it does not survive a round-trip to a ODF
> consumer/producer which does not support that custom shape. Which I
> consider a fail :(

This is well defined but as Jos already said some implementations have bugs 
that breaks this. However it seems the situation is improving

> E) Things I would have posted to the office-comment list if it felt live
> 
> 1. line end markers are shitty
> * no support for markers which are not centered at the Y-axis
>   (think half-headed spear arrows)

Theoretically this should be possible as a viewBox is given. However it seems 
that LO/OO does completely igone that. Also Calligra does not do a good job on 
resepecting it. I was able to fake it with a wrong viewBox but that is 
something we should fix.

> * markers do not adapt to the stroke width -> ugly unless certain width
>   while it's nice to be able to freely define the shape of a marker
>   this does not work with the typical arrows.

for which markers do you see problems. A shape adapting the stroke width is 
something the application does and also calligra does that. However it is not 
defined in the spec how that should be done and it also does not belong there 
as it is application defined.

>   given that there is a set of commonly used arrow types it would be better
> to hardcode identifiers for these types and have the ODF consumers care
> for the actual rendering themselves, so being able to take care of nicely
> integrating with the line stroke
>   would also solve the problem with translations of the arrow/marker types
>   the free definition of marker shapes should be still available of course

Where do you see problems

>   or the stroke width should be available as parameter somehow to
>   automatically the marker width, thus the marker fits
> * only width stretching of markers possible, but not independently of
> length * not possible to use multiple colors or fillings, i.e. complex
> shapes e.g. the markers with "holes" in it are ideally filled with e.g.
> white, not transparent. Or think of a pointing hand as arrow. Why not make
> this possible?

if the filling is white I would say it is a bug in the implementation. Does 
that also happen for calligra? To use a point hand maybe a shape is a better 
alternative then using draw markers that are part of the line.

> 2. fillings do not support complex patterns, like SVG does
> 
> 3. spec misses to define for angle parameters the direction of the angle
>    (clockwise or counter-clockwise)

for which attribute is that?

> 4. no parameter to say if fillings should be below or above outer line

does svg support something like that?

We should also notice that ODF is not a standard for graphics but for office 
documents so maybe not all features of graphic application will be there.

In case something more SVG like is needed why not convert it to a svg and add 
it as a draw frame to the document. Apache OpenOffice and LibreOffice should 
support that in the latest release. MSOffice however will not support it as far 
as I have heard.

> In general it might also be a good idea to provide coders of import filters
> a way to collect all things from other formats that cannot be mapped to
> ODF. I would have guessed office-comment list is for that, but well, if it
> is it needs improvements to encourage people to commit there.


Thorsten