Hi Armin,
Armin Le Grand schrieb:
Hi Regina and bugreporter99,
a very interesting topic...
@bugreporter99: Which tasks did you commit for SVG? I did the SVG
import, so these should got to AOO probably, did they...?
Using multiple color steps in old gradients: A good idea, I already
thought about it. Problem is (as often) that we would need a ODF change
for it. Regina, could you think about something like that, please?
AOO has not yet implemented the <svg:radialGradient> and
<svg:linearGradient> (ODF 1.2 section 16.40.2 and 16.40.3). They allow
multiple stop-colors. The schema has
<zeroOrMore> <ref name="svg-stop"/> </zeroOrMore>
So in this gradient variant, it is already possible to use multiple
color steps (and some other nice stuff).
Therefore I think, that in a first step this should be implemented.
We
have start and end colors, in-between colors would have to be some value
pair of float [0..1] and color value...
The element svg:stop has the attributes
svg:offset, svg:stop-color, and svg:stop-opacity.
The offset is double (actual from 0..1) or percent, stop-color is
#rrggbb, and opacity is double (from 0..1). All is already in the standard.
Transparency: I thought myself about this; the current 100-0% setting to
blent the start/end color against black is really not very useful; it's
just handy to not change the color yourself. If adding an alpha value to
each color definition, these value entries in the UI could be reused. I
would guess users who know more modern apps think these values are
exactly that, sigh. Also needs a ODF change, though.
It is possible already using stop-opacity. I don't think, that we should
go the way to try to get additional attributes/subelements into
draw:gradient, but implement the two svg-gradients.
BoundRects of old gradients: This is old stuff some people thought about
16-20 years ago and of course not state of the art; it was a handy way
to draw these gradients at all (think 640kb systems) and got into ODF
later, sigh, but cannot be changed
SVG gradients: We already have these in the ODF spec, thus it will be
better to go forward and offer these for the current draw objects
directly., I think. Regina, what about ODF here and that it only allows
one of the SVG mapping modes, I think both should be possible.
Currently only objectBoundingBox is allowed. I think, that AOO should
have it implemented in a way, that both svg:gradientUnits methods are
possible. If an application supports a feature, it is easier to get it
into ODF. It can be done by using a gradientUnits in an own namespace
and later on, when it is in the ODF, map it to the official one on
reading. For such a namespace, discussion with Thorsten would be useful.
With all this, do not forget: More transparency makes all stuff more
fancy, BUT also makes printing more expensive (preparation, handling)
and also PDF export, especially PDF1/A stuff that does not allow
transparencies at all...
But that is needed already for proper rendering of svg graphics. So
hopefully many parts can be reused.
I'm not the right person to do it, but shouldn't be the way to use
modern graphic cards for the calculations?
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
