openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Draw, make some changes to gradients
Date Tue, 11 Jun 2013 15:50:37 GMT

>Ah, I see. Just curious; how did you find out, it's not really 
>advertized that they use our code...?
>Did you read 


I think that's the same page the person posted to the forum I got the
information from (actually did not read the article).
IIRC I heard it from here:
(comment #26)

 >...(problem is the non-linear (irregular) form of the Ellipsoid and 
>Rectangular ones, another problem is that you can select the number
>steps in AOO, say just eight and get useful nice effects.)
 What do you mean by "non-linear (irregular) form of the Ellipsoid and
Rectangular" ?
is "on-linear (irregular) form of the Ellipsoid " an ellipse with some

> can select the number of steps in AOO

Which steps do you mean?
gradient steps??


On 10.06.2013 at 10:36 AM, "Armin Le Grand"  wrote:Hi bugreporter99,

On 07.06.2013 18:24, wrote:
> Hi Armin,
> I reported the bugs to the LO bugzilla. After finding out that AOO
> sarted the svg import stuff and LO adopted/is adopting it I started
> look at AOO.

Ah, I see. Just curious; how did you find out, it's not really 
advertized that they use our code...?

> So the current bugs I found are somewhere here:
> starting at 64457 and ending at about 64550 (so somewhere in between
> this to bug IDs I think)

I cannot work on LO tasks, please consider to commit these in AOO,
Of course after having a look which still exist, I aloready fixed
working together with another guy who also found out who really is 
behind SVG import and did it...
Did you read 


>> There is an interactive gradient edit mode, have you seen it? It's
>> a little bit hidden...
> Thanks for the hint will look at this one.
> Because I thought that the old gradient stuff can be also done in
> svg way I thought of replacing the old gradient with
> the new one. For example the Border value could be also done with
> hight and width of the gradient in the svg way (at least that's what
> thought). But if that's not possible I guess we would have to have
> Gradient and SVGGradient (was thinking like Gradient + SVGGradient
> newawesomeAOOgradient).

Something like that. OTOH you made me start again thinking about if
possible somehoy, baybe together with the possible UserTransformation 
(problem is the non-linear (irregular) form of the Ellipsoid and 
Rectangular ones, another problem is that you can select the number of

steps in AOO, say just eight and get useful nice effects.)

> regards.
> On 07.06.2013 at 10:16 AM, "Armin Le Grand"  wrote:Hi bugreporter99,
> I see no changes to the old gradient sizes; that's because these are
> historically grown and should not be touched at all. They do not
> own pos/size or whatever attributes, they are just using the area
> are set at. Historically (a lot has changed since then, but to make
> clear why it is as it is):
> - The area wich is maximally covered (and needs to be painted) is
> calculated in pixels (no double precision)
> - This leads to a boundrect
> - The to be filled geometry is set as mask
> - Number of steps (as Integer) is calculated
> - For left/R/T/B an integer add is calculyted to shrink that rect
> (radial: same, ellipse: different)
> - In a loop for n steps the rectangle is shrunk by these values, but
> there were 'if's to not let it overlap itself
> - The rectangle is filled with a calculated color with rect or
> This cannot even be direclty mapped to a transformation (mix of
> local/discrete coordinate system) and depends on object rotation
> It
> was a lot of work to get this mapped to transformations to 'emulate'
> it
> in primitive rendering at all (argh), but it works now. Today a
> primitive is used, all is in double precision. Still, the basic
> principle from the older days has to be used (the boundrect in world
> coordinates) to make it look the same, you do not want older loaded
> files to look diffeent, do you?
> BTW: There is an interactive gradient edit mode, have you seen it?
> It's
> a little bit hidden. Open draw, create a shape with gradient, in the
> drawing toolber (normally at the bottom) there is a 'effects'
> (normally on rotation). Drop it down (or undock it), there are more
> interesting functions there...
> For the SVG gradients we will have better/changed UI; I am thinking
> about a dialog form and also interactive support if possible.
> Suggestions welcome ;-)
> E.G.: Have it as a new fill mode (then two: Gradient and
> or
> as one? One means to change the UI i nthe dialog on gradient
> change, also need a method to determine what kind of gradient to
> create
> newly (old ones still need to be creatable). And and and...
> HTH!
> On 06.06.2013 22:23, wrote:
>> Hi,
>> what do you think about the way the size of the gradient should be
> set
>> (in the future)?
>> I came up with 4 ways:
>> 1. Edit-Box for width and height
>>      width/height is set in percentage
>> 2. Edit-Box for width and height
>>      width/height is set absolute (mm,cm,inch,...)
>> 3. Edit-Box for width and height
>>      width/height is set as a dot seperated value
>>       -> 1.0 would be the same width/height as parent width/height
>> 4. NO Edit-Box for width and hight
>>      handles on the gradient(on canvas) are used to change the size
>> (the Edit Boxes can be seen in my mockup I sent in the first mail)
>> My opinion
>> 1.
>>      cause the size of the gradient can be bigger then the parent's
>>      the value would become bigger than 100% ->weird
>> 2.
>>      if the size is changed and one want to set it to the parent's
> size
>>      it's not that simple (unless there is a reset button)
>> 3.
>>      ok, 1,0 would be the same size as the parent's
>> 4.
>>      cause in my opinion Draw is mostly used to draw simple stuff
>>      the handles may confuse some people and it may be harder to
>> implement
>>      (although I would like this option as well, cause that's the
>>       Inkscape does it)
>> btw. should the Border Edit Box(in the gradient tab) be replaced
> with
>> a width/height Edit Box?
>> I think if one can set the height and widht the border Edit Box
>> becomes obsolete???
>> where can I get the latest snapshot of AOO
>> is this one ok?:
>> I use the LO version from here:
>> On 04.06.2013 at 11:31 PM, "Andrea Pescetti"  wrote:Forwarding
> Armin's
>> and Regina's answers, below, to the original poster.
>> bugreporter99: please follow
>> to read
>> answers
>> (or subscribe to this list, same link). Andrea
>> 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,
>>> AOO has not yet implemented the  and
>>>    (ODF 1.2 section 16.40.2 and 16.40.3). They allow
>>> multiple stop-colors. The schema has
>>> So in this gradient variant, it is already possible to use
>>> color steps (and some other nice stuff).
>>> Therefore I think, that in a first step this should be
>>> We
>>>> have start and end colors, in-between colors would have to be
>> 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
>> 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
>>>> 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
>> about
>>>> 16-20 years ago and of course not state of the art; it was a
>> 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
>> 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
>> 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.
>>> 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:
>>> For additional commands, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message