Input for ODF plugfest/TC call

[Friedrich W. H. Kossebau]

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