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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
