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