Input for ODF plugfest/TC call

[Thorsten Zachmann]

Hello,

On Tuesday, April 24, 2012 23:57:54 Friedrich W. H. Kossebau wrote:
> 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.

unfortunately this happens quite often in the spec and I agree it would make 
sense to have some predefined stuff. However I'm not sure this is going to 
happend. E.g. for animations of shapes there where the old type which defined 
that was done e.g. "fly in from top". The new way however is to define everthing 
in smil which makes it basically very hard to have a UI for it. OO/LO solved 
that by using the type and adding a ooo: prefixed not specified type to it.

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

I think it might be possible to try to get something like that into the spec. 
However then it needs to be really specified how these stuff should behave and 
as far as I can see most people would say it is application specific.

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

Seems like in svg there is more control over all this properties. Maybe it 
would make sense to try to get those into odf. 

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

Some of those might be handy on or the other time. However to be it of use it 
needs to be something most odf implementations do implement and if a feature 
gets more complicated it might be that not all implementers might implement 
the full set.

Thorsten