Input for ODF plugfest/TC call

[jaham at gmx.net]

On Thursday 19 April 2012 13:48:52 Friedrich W. H. Kossebau 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.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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 :(
> 
> 
> 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)
> * 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.
>   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
>   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?
> 
> 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)
> 
> 4. no parameter to say if fillings should be below or above outer line
> 
> 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.
> 
> Cheers
> Friedrich

Sorry for not replying in a productive way, but I just wanted to say:

Welcome to the wonderful world of odf!

Ciao Jan