openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: Draw, make some changes to gradients
Date Wed, 05 Jun 2013 09:30:14 GMT
     Hi Regina,

On 04.06.2013 20:07, Regina Henschel wrote:
> 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.
Yes, that would be good.
>
>  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.
Yes, I know SVG ;-)
>
>>
>> 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.

Is it possible to use stop-opacity (and similar stuff) inside the old 
gradient definitions? I do not think so, maybe I got you wrong here.

>
>>
>> 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. 
Yes, +1
> 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.
Yes, changes happened without them discussing outside their ecosystem at 
all, we should not do the same.
>
>>
>> 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.
It works, it was just a remark that adding even more transparency is not 
fancy in all areas. There are areas where transparecy is not so welcome 
(ask people who need PDF1/A and maybe printer driver developers ;-)

>
> I'm not the right person to do it, but shouldn't be the way to use 
> modern graphic cards for the calculations?

In a multiplattform environment this is always difficult; you do not 
even have the same API to the graphic HW on the same system when using 
another OS. But sure this is the direction for the future.

>
> Kind regards
> Regina
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Sincerely,
     Armin
--
ALG

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message