Input for ODF plugfest/TC call

[Friedrich W. H. Kossebau]

Hi Thorsten,

Am Samstag, 21. April 2012, 06:42:28 schrieb 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.

Yes, I guess it will be quite a task. But then this task is ideally spread 
among all the ODF interest groups. Perhaps there can be some fame game to 
motivate people to contribute, like having the producer of a test document be 
named somewhere.
And Jos already earned first fame, at least with me :)

> > 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

Good, thanks.

> > 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.

Yes, e.g. the above OFFICE-3750 is for me. But there has never been any reply 
to an email saying
	 "Thanks for your input, please track how we deal with the issue at
	  http://tools.oasis-open.org/issues/browse/YOUR_ISSUE"
. Instead there is silence from the TC side. Just the monthly reminder, which 
feels like the not-shut-down automatic announcement system on a dead train 
station where you walk lonely on a platform, which is now and then reminding 
people to take care of one's luggage</prose>.

> > 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

I was totally imprecise about what I actually meant, sorry. Next try:

For custom embedded objects at least to me the ODF 1.2 spec is not really 
clear how to properly store them, especially together with a fallback image in 
case the consumer does not have a handler for the original format of the 
object.

"10.4.6.1 General" talks about two types, object with an OpenDocument 
representation and objects without. The first are to be referenced by a 
<draw:object> tag and the latter?
"10.4.6.3 <draw:object-ole>" says: "The <draw:object-ole> element represents 
objects that do not have an OpenDocument representation.".

My question 1: All, or just those with OLE properties (which is platform 
dependent, no?)? And if the latter, how to store non-OLE objects?

At least the mapshape code, which I used as template for the barcode shape I 
did, stored its data in a custom element container, without wrapping it in 
<draw:object-ole> or something else.

Same with the fallback image/object: I learned from someone and the mapshape 
code, that the fallback image should be placed behind the actual content token 
in the <draw:frame>, as any ODF consumer which does not recognize the content 
token will just skip that and read the fallback image as content for the 
<draw:frame>, while ODF consumers which do recognize it expect only one token 
(as defined by the spec) in the <draw:frame> and skip the fallback image 
token.

But I cannot find that approach being described in the spec.
My question 2:  Did I just miss it? Or does that need to be specified?

> > 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.

I also tried to get it with the viewBox but failed (was a few weeks ago).
Rereading the sentence "The geometry is horizontally centered." in "16.40.8 
<draw:marker>" left me thinking that the spec indeed does not demand that the 
y-axis of the viewBox is to be taken as center, but instead to take the middle 
of the actual shape.

Looking at the existing default marker shapes those are indeed all not 
centered around the y-axis of the viewBox, so changing the code to take the 
viewBox y-axis into account would break for the existing markers, no?

So that would need another solution.

> > * 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.

I see the problem for all stroke-like markers, like e.g. the line arrow:
	____\
	    /
For these IMHO the thickness of the strokes in the marker should automatically 
match the thickness of the stroke of the line, for a natural look. Just play 
around with a line with the line arrow: change the line width and see yourself 
how the marker only looks alright with a certain width.

(BTW, the Calligra UI is missing controls for draw:marker-{start,end}-width 
and draw:marker-{start,end}-center, I started to play around with adding that, 
but had not yet found a nice UI layout so far)

> >   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

a) Translation of the marker type names
At least LO/AOO label the default marker types. And IMHO that make sense, as 
indeed you might want to talk about a marker type by name.

b) marker defined by actual rendering, not base type
If using a marker, one choses a certain marker because of the basic shape, not 
the actual exact rendering. Think line markers as used in UML. There are 
actual types of markers, like there are characters in the alphabet. Which font 
is used does not change the meaning. Similar that is true for markers.
(Actually unicode even has arrow characters, which are lines with typical 
markers. Fire up KCharSelect and type "arrow" in the search bar).

You can see how Calligra needs to take care to have the very same marker 
definition in its default marker list then LO/AOO have, so there is no 
duplication in the marker list if documents are shown from LO/AOO which use 
markers from their default list, as matching is done by the shape definition, 
not by the type.

So I propose to have an "alphabet" of markers, or set of types. The actual 
rendering could be separated into "marker fonts", which would also ensure that 
all markers look consistent together, if the same "marker font" is used for 
them.

And next to these defined types there should also be custom markers possible, 
like it is now.

c) combining the line with the marker
E.g. for an arrow with a sharp end the actual line needs to end at the proper 
place, to not stick out of the arrow, independently of the width of the 
stroke. To spare the user finding out which value she ideally sets for 
draw:marker-{start,end}-center to get the needed overlapping of the stroke and 
the marker ideally the program knows how to do it.

BTW: talking about markers it would be also great to have markers on points in 
the line, like a horizontal stroke.

> >   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?

No, I meant that someone would like to have the filling white (or whatever 
other color or filling). Imagine markers which are used for lines over colored 
and/or complex backgrounds. So one would like to enforce what is painted in 
the "hole", i.e. define a filling for that area. Actually just see the markers 
without a hole to be actually filled with the stroke color :)

> To use a point hand maybe a shape is a better
> alternative then using draw markers that are part of the line.

The markers are kind of shapes, with the advantage of being automatically 
rotated (and scaled as wanted) so they point into the direction of the end of 
the line.
(and talking about that I also would like a mirror-flag for non-symmetric 
markers, so one copy is enough).

> > 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?

For all. While the definition of angle is the same as in
--- 8< ---
18.3.1 angle
An angle, as defined in §4.1 of [SVG]. An angle is a double value that may be 
followed immediately by one of the following angle unit identifiers: deg 
(degrees), grad (gradiants) or rad (radians). If no unit identifier is 
specified, the value is assumed to be in degrees.
--- 8< ---
both SVG and ODF do not tell if which direction the + and resp. the - values 
are measured for the given directed rotation axis (for rotation in the 2D 
layer the rotation axis should be the z-axis, which points towards the viewer 
of the xy layer, at least by the cartesian coordinate system I assume to be 
the base for all geometry data here? Perhaps that needs to be defined 
explicitely as well?).

Or is counter-clockwise as rotation direction simply part of the cartesian 
coordinate system and I am just a clue-less pupil whose geometry lessons are 
far too long ago? :) Still, given the different interpretations by the 
existing ODF producers/consumers that better is explicitely defined.

> > 4. no parameter to say if fillings should be below or above outer line
> 
> does svg support something like that?

Not that I found. But some graphic programs do (Corel Draw, and forgot which 
else). Thinking more about it now, there should be rather an option  "Center 
outline on points|Paint outline outside of points|Paint outline inside of 
points", so especially when working with wider strokes one does not have to 
calculate the shape points by taking the stroke width into account, instead 
being able to tell "the stroke should not be painted outside/inside of the 
actual outline".

But no pressing issue for me currently. Just remember I made use of the 
stroke-behind-filling quite a few times back then when I was in vector graphic 
works. E.g. when doing font arts, where I used wider strokes for the outline 
but did not want them to lap inside the actual glyph shape, to keep the 
outline intact. Same should be true for all figures with parts that can be 
similar thin as the outline stroke is wide, think drawings of people, animals 
or other stuff, where a wide stroke is useful to make it stick out a complex 
background, but where the stroke should not kill the outline of the shape 
itself.

> 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.

Hm, the "O" in ODF is for "Open", not "Office", or? ;)

And IMHO ODF should also try to offer a standard format for graphics-oriented 
documents. And with ODG they actually try, no? Otherwise any graphics-oriented 
elements should have been left-out of ODF and should have been subject to 
embedded SVG objects.

I look at this mainly from a DTP, science paper, slides, poster, sticker, 
booklet perspective:
with ODF I hope for a format for composed paged documents, where one can put 
all kinds of objects inside a document which share as many as possible 
settings/properties. E.g. palettes or font styles. If I change the default 
font style, for all objects who use styles which inherit from that default 
style those styles should be updated, disregarding if it is the style of a 
diagram labeling, of a paragraph header, of a text line in a graphic or 
whatever. Or if I change the global color palette all styles which make use of 
that should update themselves, in whatever object type. To have a consistent 
(and that way good) looking document.

Using e.g. only SVG for graphic objects would make the sharing of 
settings/properties complicated, if SVG makes references to settings outside 
of the SVG object/stylesheet world complicated (what I expect).

And with ODF I also hope that the programs dealing with files in that format 
start to provide better support for composed documents, like Calligra tries.

In the end it will be only the usecase that decides which actual UI variant I 
choose to work on an ODF-based file, with UI=set of tools+arrangement. If I 
create a comic book or some sheets of music or a big poster for an event or a 
set of stickers/name tags or a monthly report of a project's activity or 
whatever, the storing format will be ODF-based and the actual document simply 
a composition of the building blocks/objects.

Boy, long text, sorry. No idea where to cut. Perhaps simply a complex thingie.

Cheers
Friedrich