MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: some answers regarding drawing comments
Thanks for the comments. For the most part I think the suggestions are
reasonable.
> Not sure if we need to specify the "if" function further as it is
> the obvious like in VML and other places where "if" is a ternary
> function.
I suggest that all of the functions, including if, should be
documented...you know, just for the heck of it.
> The stretchpoint is the same as the limo-stretch in vml. When a
> stretchpoint is set, the shape is divided up into three parts, the
> front and the back of the shape remains geometrical unchanged,
> whereas the middle part that is defined by the stretchpoint is
> scaled.
From a high enough level this is accurate, but the described behavior
is "emergent" from the underlying point transformation. I think it is
important to document the actual processing of a custom shape's
coordinates when a stretchpoint is used. Examples would be useful.
> "no mixtures of open and closed curves for one shape" means that the
> OOo implementation does not support the combination of open and
> closed curves in one svg:d attribute. The path described with one
> svg:d attribute is either an open or a closed polygon.
I understand that OOo has limited support for the svg:d attribute, but
my original comment was questioning why optional support needed to be
codified in the ODF spec. I would still strongly prefer to eliminate
the option and file a bug/RFE against OOo.
I also disagree with making elliptical arcs optional (IMHO it is
unlikely that a device capable of otherwise displaying ODF documents
would be stymied by needing to implement elliptical arcs). However, as
far as optional features go this one is okay, because it is clearly
called out and has an obvious fallback (approximating the curves via
cubic beziers), as opposed to the current totally open-ended optional
nature of svg:d.
> The OOo gradients are not documented as they are specified around
> the implementation of gradients inside OOo which itself is not
> documented. My personal opinion is to drop them completly and use
> the documented svg gradients in the near future.
I would not mind this course of action as SVG gradients are clearly
superior. However, just to be clear, last time I checked OOo did not
support SVG gradients, so this is a fairly incompatible change.
> It is correct that "draw:concentric-gradient-fill-allowed" is
> currently only used for round trip and will only makes sense as soon
> as we also specify concentric gradients in ODF. It would make sense
> to remove it from the ODF specification as in the sense of the
> specification it is currently useless. But is it worth it?
Having attributes which exist only for round-tripping seems like a bad
precedent. In any case, that attribute alone is insufficient for
round-tripping, because it only says whether the gradient is allowed;
whether a shape actually uses a concentric gradient is not
round-tripped (at least in the spec). My preference is to add
concentric gradients support to ODF, but if that is not possible then
I cannot see how removing this attribute has any practical
disadvantages.
Chris
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]