You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by bu...@hushmail.com on 2013/06/03 17:46:29 UTC
Draw, make some changes to gradients
Dear Apache Open Office/Libre Office devs,
the reason why I'm writing is, cause I can't code and want to make OO
better.
Specially the way gradients in Draw works. At the moment the gradients
stuff is rudimentary.
Well I guess little kids may have fun with this but you can't do real
work with that.
So this HAS to be changed.
At least the following things should be added:
- possibility to use more than two colors for the gradient
- set the hight and width of the gradient
- the percentage of the color should change the transparency and not
the "blackness" of the color
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64469
Because this will break compatibillity with older Versions of OO I
think there should be as much changes as
possible to prevent having to do big changes in the future to the
gradients stuff.
So here is my suggestion to the GUI part (pdf file:
http://temp-share.com/show/f3Ygit6Xn).
The coding part is up to you cause that's out of my scope.
I would like you guys to think about how this could be implemented and
if there is a better way to
do it on the GUI side (maybe an extra button which will pop-up an
extra window for the editing of
the gradient???).
Please fuck the licensing issues so the code can be used in both
projects.
Re: Draw, make some changes to gradients
Posted by Alexandro Colorado <jz...@oooes.org>.
On 6/6/13, bugreporter99@hushmail.com <bu...@hushmail.com> 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)
> http://temp-share.com/show/f3Ygit6Xn
>
> My opinion
> 1.
> cause the size of the gradient can be bigger then the parent's
> the value would become bigger than 100% ->weird
I think the dialog should be more graphical and less numerical, most
program have both but people end up using the graphical more than the
numerical, except when you are cloning something and have pre-defined
values.
> 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 way
> 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?:
> https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
>
> I use the LO version from here:
> http://dev-builds.libreoffice.org/daily/
> 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
> http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, please?
>>
>> 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 multiple
>> color steps (and some other nice stuff).
>>
>> Therefore I think, that in a first step this should be implemented.
I think this would have made a great Google of Summer project.
>>
>> 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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Regina Henschel <rb...@t-online.de>.
Hi,
bugreporter99@hushmail.com schrieb:
> hey,
>
>> In Ellipsoid and Rectangular (play with it) the center of the
> gradient
>> gets to a line. There is no linear transformation to map this to SVG
>> gradients. Anyways there is no mapping to Rectangluar at all.
>
> Was trying to cheat but seems not to work the way I want it to look
> like.
> For the rectangular gradient I tried to use three instead of two
> colors, so to imitate a black to white gradient(the old school way) I
> just used a black to white to black gradient (SVGgradient). Just kind
> of "mirror" the colors at the middle line/color.
> http://i39.tinypic.com/302ctw9.png
> the ellepsoid es even harder to imitate
This simple kind of gradient you made with Inkscape in that picture is
called "Axial" in AOO.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
Hi bugreporter99,
On 13.06.2013 18:48, bugreporter99@hushmail.com wrote:
> hey,
>
>> In Ellipsoid and Rectangular (play with it) the center of the
> gradient
>> gets to a line. There is no linear transformation to map this to SVG
>> gradients. Anyways there is no mapping to Rectangluar at all.
> Was trying to cheat but seems not to work the way I want it to look
> like.
> For the rectangular gradient I tried to use three instead of two
> colors, so to imitate a black to white gradient(the old school way) I
> just used a black to white to black gradient (SVGgradient). Just kind
> of "mirror" the colors at the middle line/color.
> http://i39.tinypic.com/302ctw9.png
> the ellepsoid es even harder to imitate
Yes, but that's the 'Axial' type, not too hard and doable as you
describe. To make it clear, here is how to find all six types:
- start impress
- press 'Area' button in the 'Line and Filling' Toolbar (the can in the
upper toolbar)
- You get the area dialog
- There, select the tab 'Gradients'
- Play with Type, you have six kinds of gradients
- Also play with the other values, lots of things to do here...
The types 'Linear' and 'Axial' are simple.
The type 'Radial' is simple.
The type 'Ellipsoid is *not* simple, put 50% in CenterY and CenterY to
see that is has no single *center*.
The types 'Square' and 'Rectangular' have similar problems, plus that
they are based on rectangles, not available in SVG
- close the dialog
- create a rectangle, keep it selected
- open the dialog again
- in the 'Area' tab, select 'Gradient' in the Fill DropDown
- Choose any gradient
- At 'Increments' at the right, switch off 'Automatic' and choose a
small value (e.g. three)
->No way to do that with SVG.
Hope this gets clearer now. If you find ways to map these to SVG stuff,
tell me, I will be happy.
BTW: Didi you commit some tasks in bugzilla for SVG import recently? If
yes, thanks for that, I will look asap ;-)
Sincerely,
Armin
>
> On 12.06.2013 at 11:10 AM, "Armin Le Grand" wrote:Hi bugreporter99,
>
> On 11.06.2013 17:50, bugreporter99@hushmail.com wrote:
>> Hi,
>>
>>> Ah, I see. Just curious; how did you find out, it's not really
>>> advertized that they use our code...?
>> ...
>>> Did you read
>>>
> (https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
>>> btw...?
>> 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:
>> http://en.libreofficeforum.org/node/293#comment-22501
>> (comment #26)
> Ah okay. They should at least tell people that it's not useful to
> write
> tasks for LO for an AOO-feature. I will not even see them there, I am
> not working at/for/on LO.
>
>> >...(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.)
>> 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
>> bumps???
> In Ellipsoid and Rectangular (play with it) the center of the gradient
>
> gets to a line. There is no linear transformation to map this to SVG
> gradients. Anyways there is no mapping to Rectangluar at all.
>
>>> ...you can select the number of steps in AOO
>> Which steps do you mean?
>> gradient steps??
> Yes. In the fill attributes you can set the step cout to e.g.
> user-defined 3 steps. This is useful in arious cases, but will also
> not
> map to SVG where this is not possible.
>
>> regards.
>>
>> On 10.06.2013 at 10:36 AM, "Armin Le Grand" wrote:Hi bugreporter99,
>>
> [deletd some older stuff here]
> --
> ALG
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
hey,
>In Ellipsoid and Rectangular (play with it) the center of the
gradient
>gets to a line. There is no linear transformation to map this to SVG
>gradients. Anyways there is no mapping to Rectangluar at all.
Was trying to cheat but seems not to work the way I want it to look
like.
For the rectangular gradient I tried to use three instead of two
colors, so to imitate a black to white gradient(the old school way) I
just used a black to white to black gradient (SVGgradient). Just kind
of "mirror" the colors at the middle line/color.
http://i39.tinypic.com/302ctw9.png
the ellepsoid es even harder to imitate
On 12.06.2013 at 11:10 AM, "Armin Le Grand" wrote:Hi bugreporter99,
On 11.06.2013 17:50, bugreporter99@hushmail.com wrote:
> Hi,
>
>> Ah, I see. Just curious; how did you find out, it's not really
>> advertized that they use our code...?
> ...
>> Did you read
>>
(https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
>> btw...?
> 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:
> http://en.libreofficeforum.org/node/293#comment-22501
> (comment #26)
Ah okay. They should at least tell people that it's not useful to
write
tasks for LO for an AOO-feature. I will not even see them there, I am
not working at/for/on LO.
>
> >...(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.)
> 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
> bumps???
In Ellipsoid and Rectangular (play with it) the center of the gradient
gets to a line. There is no linear transformation to map this to SVG
gradients. Anyways there is no mapping to Rectangluar at all.
>
>> ...you can select the number of steps in AOO
> Which steps do you mean?
> gradient steps??
Yes. In the fill attributes you can set the step cout to e.g.
user-defined 3 steps. This is useful in arious cases, but will also
not
map to SVG where this is not possible.
>
> regards.
>
> On 10.06.2013 at 10:36 AM, "Armin Le Grand" wrote:Hi bugreporter99,
>
[deletd some older stuff here]
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
Hi bugreporter99,
On 11.06.2013 17:50, bugreporter99@hushmail.com wrote:
> Hi,
>
>> Ah, I see. Just curious; how did you find out, it's not really
>> advertized that they use our code...?
> ...
>> Did you read
>> (https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
>> btw...?
> 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:
> http://en.libreofficeforum.org/node/293#comment-22501
> (comment #26)
Ah okay. They should at least tell people that it's not useful to write
tasks for LO for an AOO-feature. I will not even see them there, I am
not working at/for/on LO.
>
> >...(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.)
> 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
> bumps???
In Ellipsoid and Rectangular (play with it) the center of the gradient
gets to a line. There is no linear transformation to map this to SVG
gradients. Anyways there is no mapping to Rectangluar at all.
>
>> ...you can select the number of steps in AOO
> Which steps do you mean?
> gradient steps??
Yes. In the fill attributes you can set the step cout to e.g.
user-defined 3 steps. This is useful in arious cases, but will also not
map to SVG where this is not possible.
>
> regards.
>
> On 10.06.2013 at 10:36 AM, "Armin Le Grand" wrote:Hi bugreporter99,
>
[deletd some older stuff here]
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
Hi,
>Ah, I see. Just curious; how did you find out, it's not really
>advertized that they use our code...?
...
>Did you read
>(https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
>btw...?
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:
http://en.libreofficeforum.org/node/293#comment-22501
(comment #26)
>...(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.)
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
bumps???
>...you can select the number of steps in AOO
Which steps do you mean?
gradient steps??
regards.
On 10.06.2013 at 10:36 AM, "Armin Le Grand" wrote:Hi bugreporter99,
On 07.06.2013 18:24, bugreporter99@hushmail.com 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
to
> 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:
>
https://www.libreoffice.org/bugzilla/buglist.cgi?component=Drawing&product=LibreOffice&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on=
> 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,
too.
Of course after having a look which still exist, I aloready fixed
some,
working together with another guy who also found out who really is
behind SVG import and did it...
Did you read
(https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
btw...?
>> 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
the
> svg way I thought of replacing the old gradient with
> the new one. For example the Border value could be also done with
the
> hight and width of the gradient in the svg way (at least that's what
I
> 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
it's
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.)
Sincerely,
Armin
>
> 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
have
> own pos/size or whatever attributes, they are just using the area
they
>
> 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
ellipse
>
> 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'
DropDown
>
> (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
SVGGradient)
> or
> as one? One means to change the UI i nthe dialog on gradient
selection
>
> 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, bugreporter99@hushmail.com 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)
>> http://temp-share.com/show/f3Ygit6Xn
>>
>> 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
way
>> 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?:
>>
>
https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
>> I use the LO version from here:
>> http://dev-builds.libreoffice.org/daily/
>> 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
>> http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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,
please?
>>> 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
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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
Hi bugreporter99,
On 07.06.2013 18:24, bugreporter99@hushmail.com 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 to
> 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:
> https://www.libreoffice.org/bugzilla/buglist.cgi?component=Drawing&product=LibreOffice&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on=
> 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, too.
Of course after having a look which still exist, I aloready fixed some,
working together with another guy who also found out who really is
behind SVG import and did it...
Did you read
(https://blogs.apache.org/OOo/entry/good_news_libreoffice_is_integrating),
btw...?
>> 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 the
> svg way I thought of replacing the old gradient with
> the new one. For example the Border value could be also done with the
> hight and width of the gradient in the svg way (at least that's what I
> 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 it's
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.)
Sincerely,
Armin
>
> 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 have
> own pos/size or whatever attributes, they are just using the area they
>
> 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 ellipse
>
> 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' DropDown
>
> (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 SVGGradient)
> or
> as one? One means to change the UI i nthe dialog on gradient selection
>
> 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, bugreporter99@hushmail.com 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)
>> http://temp-share.com/show/f3Ygit6Xn
>>
>> 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 way
>> 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?:
>>
> https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
>> I use the LO version from here:
>> http://dev-builds.libreoffice.org/daily/
>> 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
>> http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, please?
>>> 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 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-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
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 to
look at AOO.
So the current bugs I found are somewhere here:
https://www.libreoffice.org/bugzilla/buglist.cgi?component=Drawing&product=LibreOffice&query_format=advanced&resolution=---&order=bug_id%20DESC&query_based_on=
starting at 64457 and ending at about 64550 (so somewhere in between
this to bug IDs I think)
>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 the
svg way I thought of replacing the old gradient with
the new one. For example the Border value could be also done with the
hight and width of the gradient in the svg way (at least that's what I
thought). But if that's not possible I guess we would have to have
Gradient and SVGGradient (was thinking like Gradient + SVGGradient ==
newawesomeAOOgradient).
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 have
own pos/size or whatever attributes, they are just using the area they
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 ellipse
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' DropDown
(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 SVGGradient)
or
as one? One means to change the UI i nthe dialog on gradient selection
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, bugreporter99@hushmail.com 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)
> http://temp-share.com/show/f3Ygit6Xn
>
> 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 way
> 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?:
>
https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
>
> I use the LO version from here:
> http://dev-builds.libreoffice.org/daily/
> 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
> http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, please?
>> 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 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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
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 have
own pos/size or whatever attributes, they are just using the area they
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 ellipse
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' DropDown
(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 SVGGradient) or
as one? One means to change the UI i nthe dialog on gradient selection
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, bugreporter99@hushmail.com 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)
> http://temp-share.com/show/f3Ygit6Xn
>
> 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 way
> 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?:
> https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
>
> I use the LO version from here:
> http://dev-builds.libreoffice.org/daily/
> 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
> http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, please?
>> 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 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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
Hi bugreporter99,
Ah, forgot one: What about the SVG error reports, I am interested in
these ;-)
Sincerely,
Armin
On 06.06.2013 22:23, bugreporter99@hushmail.com wrote:
> Hi,
>
> [stuff deleted]
>
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
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)
http://temp-share.com/show/f3Ygit6Xn
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 way
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?:
https://cwiki.apache.org/OOOUSERS/development-snapshot-builds.html#DevelopmentSnapshotBuilds-AOOSnapshotfullsets
I use the LO version from here:
http://dev-builds.libreoffice.org/daily/
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
http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, please?
>
> 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 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Draw, make some changes to gradients
Posted by Andrea Pescetti <pe...@apache.org>.
Forwarding Armin's and Regina's answers, below, to the original poster.
bugreporter99: please follow
http://mail-archives.apache.org/mod_mbox/openoffice-dev/ 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, 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
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
Re: Draw, make some changes to gradients
Posted by Regina Henschel <rb...@t-online.de>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by Armin Le Grand <Ar...@me.com>.
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? We
have start and end colors, in-between colors would have to be some value
pair of float [0..1] and color value...
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.
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.
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...
Just my 2 cents...
On 04.06.2013 17:14, Regina Henschel wrote:
> Hi,
>
> bugreporter99@hushmail.com schrieb:
>> Many thanks for the answer Regina,
>>
>> (thought I would be dopped to the spam folder ;) )
>>
>>> Coding is not the only way to make AOO better. For example there are
>>> always people needed to test the product, whether the new features work
>>> as intended and whether no regressions slipped in. Also usability is a
>>> topic for non coder, and usability is not about a single design
>>> opinion,
>>> but making tests like the icon test in LO.
>>
>> actually I do report bugs, when I find some (in most cases svg stuff
>> atm)
>>
>>> Currently the gradient is relative to the shape. Adjustments are done
>>> with the Border property. With svg it is possible to define the
>>> gradient
>>> relative to the parent of the shape and that is rendered correctly
>>> in AOO.
>>
>> Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered
>> correctly.
>> for example:
>> on AOO3.4.1 (can't tell about newer versions)
>
> Please do not test with AOO 3.4.1. Rendering svg and rendering
> gradients have been reworked. Please use a current snapshot of AOO4.0
>
> [..]
>>> Transparency is an additional feature. You can already combine
>>> transparency with solid color (I guess from the pdf-file, that you want
>>> that), but you can also combine transparency with gradients. You need
>>> not even use the same kind of gradient. It seems you have not yet
>>> discovered the property 'Gradient' in the Transparency tab of the Area
>>> dialog.
>>
>> Yes, but if you look at the attachement
>> (https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
>> bugreport I mentioned, it does not makde that much sense (imo) to use
>> the percentage for the blackness. The transparency tab would just change
>> the WHOLE gradient transparency.
>
> The transparency itself can be defined as gradient.
>
> But I'd like also to set the
>> transparency of each gradient color.
>
> Transparency it a forth channel besides RGB. There exist nothing like
> a "transparency of a color". Each value of a pixel consists of four
> parts: Red, Green, Blue and transparency, each in the range of 0 to 255.
>
> I do not really understand, which result you want to get. Your
> attachment shows some changes in UI, but do not explain, what the
> resulting gradient should look like.
>
> Kind regards
> Regina
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
Hello,
>>But I'd like also to set the
>>transparency of each gradient color.
>Transparency it a forth channel besides RGB. There exist nothing like
a
>"transparency of a color". Each value of a pixel consists of four
parts:
>Red, Green, Blue and transparency, each in the range of 0 to 255.
>I do not really understand, which result you want to get....
tried to make an image in Inkscape ;) to make it a little bit clearer.
http://i40.tinypic.com/358dtly.png
On 04.06.2013 at 5:14 PM, "Regina Henschel" wrote:Hi,
bugreporter99@hushmail.com schrieb:
> Many thanks for the answer Regina,
>
> (thought I would be dopped to the spam folder ;) )
>
>>Coding is not the only way to make AOO better. For example there are
>>always people needed to test the product, whether the new features
work
>>as intended and whether no regressions slipped in. Also usability is
a
>>topic for non coder, and usability is not about a single design
opinion,
>>but making tests like the icon test in LO.
>
> actually I do report bugs, when I find some (in most cases svg stuff
atm)
>
>>Currently the gradient is relative to the shape. Adjustments are
done
>>with the Border property. With svg it is possible to define the
gradient
>>relative to the parent of the shape and that is rendered correctly
in AOO.
>
> Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered
correctly.
> for example:
> on AOO3.4.1 (can't tell about newer versions)
Please do not test with AOO 3.4.1. Rendering svg and rendering
gradients
have been reworked. Please use a current snapshot of AOO4.0
[..]
>>Transparency is an additional feature. You can already combine
>>transparency with solid color (I guess from the pdf-file, that you
want
>>that), but you can also combine transparency with gradients. You
need
>>not even use the same kind of gradient. It seems you have not yet
>>discovered the property 'Gradient' in the Transparency tab of the
Area
>>dialog.
>
> Yes, but if you look at the attachement
> (https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of
the
> bugreport I mentioned, it does not makde that much sense (imo) to
use
> the percentage for the blackness. The transparency tab would just
change
> the WHOLE gradient transparency.
The transparency itself can be defined as gradient.
But I'd like also to set the
> transparency of each gradient color.
Transparency it a forth channel besides RGB. There exist nothing like
a
"transparency of a color". Each value of a pixel consists of four
parts:
Red, Green, Blue and transparency, each in the range of 0 to 255.
I do not really understand, which result you want to get. Your
attachment shows some changes in UI, but do not explain, what the
resulting gradient should look like.
Kind regards
Regina
Re: Draw, make some changes to gradients
Posted by Regina Henschel <rb...@t-online.de>.
Hi,
bugreporter99@hushmail.com schrieb:
> Many thanks for the answer Regina,
>
> (thought I would be dopped to the spam folder ;) )
>
>>Coding is not the only way to make AOO better. For example there are
>>always people needed to test the product, whether the new features work
>>as intended and whether no regressions slipped in. Also usability is a
>>topic for non coder, and usability is not about a single design opinion,
>>but making tests like the icon test in LO.
>
> actually I do report bugs, when I find some (in most cases svg stuff atm)
>
>>Currently the gradient is relative to the shape. Adjustments are done
>>with the Border property. With svg it is possible to define the gradient
>>relative to the parent of the shape and that is rendered correctly in AOO.
>
> Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered correctly.
> for example:
> on AOO3.4.1 (can't tell about newer versions)
Please do not test with AOO 3.4.1. Rendering svg and rendering gradients
have been reworked. Please use a current snapshot of AOO4.0
[..]
>>Transparency is an additional feature. You can already combine
>>transparency with solid color (I guess from the pdf-file, that you want
>>that), but you can also combine transparency with gradients. You need
>>not even use the same kind of gradient. It seems you have not yet
>>discovered the property 'Gradient' in the Transparency tab of the Area
>>dialog.
>
> Yes, but if you look at the attachement
> (https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
> bugreport I mentioned, it does not makde that much sense (imo) to use
> the percentage for the blackness. The transparency tab would just change
> the WHOLE gradient transparency.
The transparency itself can be defined as gradient.
But I'd like also to set the
> transparency of each gradient color.
Transparency it a forth channel besides RGB. There exist nothing like a
"transparency of a color". Each value of a pixel consists of four parts:
Red, Green, Blue and transparency, each in the range of 0 to 255.
I do not really understand, which result you want to get. Your
attachment shows some changes in UI, but do not explain, what the
resulting gradient should look like.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Draw, make some changes to gradients
Posted by bu...@hushmail.com.
Many thanks for the answer Regina,
(thought I would be dopped to the spam folder ;) )
>Coding is not the only way to make AOO better. For example there are
>always people needed to test the product, whether the new features
work
>as intended and whether no regressions slipped in. Also usability is
a
>topic for non coder, and usability is not about a single design
opinion,
>but making tests like the icon test in LO.
actually I do report bugs, when I find some (in most cases svg stuff
atm)
>Currently the gradient is relative to the shape. Adjustments are done
>with the Border property. With svg it is possible to define the
gradient
>relative to the parent of the shape and that is rendered correctly in
AOO.
Looking at LO4.0.4 and AOO3.4.1 the gradients are not rendered
correctly.
for example:
on AOO3.4.1 (can't tell about newer versions)
# the ellipsoid gradient (having more than 2 colors) is rendered
wrongly
#also the hight of the ellipsoid gradient is rendered wrongly (cause
there is not option atm to set the hight/width of the gradient)
on LO4.0.4
#the same but seems like the issue with ellipsoid gradients with
more than 2 colors is maybe fixed in 4.1beta
>Transparency is an additional feature. You can already combine
>transparency with solid color (I guess from the pdf-file, that you
want
>that), but you can also combine transparency with gradients. You need
>not even use the same kind of gradient. It seems you have not yet
>discovered the property 'Gradient' in the Transparency tab of the
Area
>dialog.
Yes, but if you look at the attachement
(https://www.libreoffice.org/bugzilla/attachment.cgi?id=79272) of the
bugreport I mentioned, it does not makde that much sense (imo) to use
the percentage for the blackness. The transparency tab would just
change the WHOLE gradient transparency. But I'd like also to set the
transparency of each gradient color.
>We tend to make the draw stuff more like svg. Already now it is
possible
>to use a svg-graphic; and its gradients are rendered nicely.
+2
>Area > Gradient is already the dialog page to edit gradients. What
>editing feature do you miss on that page? But keep in mind, that
color
>gradient and transparency are independent properties.
as described above that maybe should be changed a little (allowoing
also to change the transparency of each gradient color)
>Besides that, changes have to be compatible with ODF or find its way
in
>the next version of ODF.
ODF needs to update faster so it can support the important/widely used
things of svg ;)
As you may noticed I'm a spoiled Inkscape user who just wants to
import some svg drawing into AOO/LO (at least some basic svg drawings
no animation or such things) :)
Kind regards bugreporter99.
On 03.06.2013 at 6:35 PM, "Regina Henschel" wrote:Hi ???,
bugreporter99@hushmail.com schrieb:
> Dear Apache Open Office/Libre Office devs,
> the reason why I'm writing is, cause I can't code and want to make
OO
> better.
Coding is not the only way to make AOO better. For example there are
always people needed to test the product, whether the new features
work
as intended and whether no regressions slipped in. Also usability is a
topic for non coder, and usability is not about a single design
opinion,
but making tests like the icon test in LO.
> Specially the way gradients in Draw works. At the moment the
gradients
> stuff is rudimentary.
> Well I guess little kids may have fun with this but you can't do
real
> work with that.
> So this HAS to be changed.
> At least the following things should be added:
> - possibility to use more than two colors for the gradient
+1
> - set the hight and width of the gradient
Currently the gradient is relative to the shape. Adjustments are done
with the Border property. With svg it is possible to define the
gradient
relative to the parent of the shape and that is rendered correctly in
AOO.
> - the percentage of the color should change the transparency and not
> the "blackness" of the color
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64469
-1
Transparency is an additional feature. You can already combine
transparency with solid color (I guess from the pdf-file, that you
want
that), but you can also combine transparency with gradients. You need
not even use the same kind of gradient. It seems you have not yet
discovered the property 'Gradient' in the Transparency tab of the Area
dialog.
> Because this will break compatibillity with older Versions of OO I
> think there should be as much changes as
> possible to prevent having to do big changes in the future to the
> gradients stuff.
> So here is my suggestion to the GUI part (pdf file:
> http://temp-share.com/show/f3Ygit6Xn).
> The coding part is up to you cause that's out of my scope.
We tend to make the draw stuff more like svg. Already now it is
possible
to use a svg-graphic; and its gradients are rendered nicely.
Besides that, changes have to be compatible with ODF or find its way
in
the next version of ODF.
> I would like you guys to think about how this could be implemented
and
> if there is a better way to
> do it on the GUI side (maybe an extra button which will pop-up an
> extra window for the editing of
> the gradient???).
Area > Gradient is already the dialog page to edit gradients. What
editing feature do you miss on that page? But keep in mind, that color
gradient and transparency are independent properties.
> Please fuck the licensing issues so the code can be used in both
> projects.
>
If a developer provides his work under AL2, it can be used in both
projects. So its up to the individual developer. Changes done in AOO
can
always be used in LO.
Kind regards
Regina
Re: Draw, make some changes to gradients
Posted by Regina Henschel <rb...@t-online.de>.
Hi ???,
bugreporter99@hushmail.com schrieb:
> Dear Apache Open Office/Libre Office devs,
> the reason why I'm writing is, cause I can't code and want to make OO
> better.
Coding is not the only way to make AOO better. For example there are
always people needed to test the product, whether the new features work
as intended and whether no regressions slipped in. Also usability is a
topic for non coder, and usability is not about a single design opinion,
but making tests like the icon test in LO.
> Specially the way gradients in Draw works. At the moment the gradients
> stuff is rudimentary.
> Well I guess little kids may have fun with this but you can't do real
> work with that.
> So this HAS to be changed.
> At least the following things should be added:
> - possibility to use more than two colors for the gradient
+1
> - set the hight and width of the gradient
Currently the gradient is relative to the shape. Adjustments are done
with the Border property. With svg it is possible to define the gradient
relative to the parent of the shape and that is rendered correctly in AOO.
> - the percentage of the color should change the transparency and not
> the "blackness" of the color
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64469
-1
Transparency is an additional feature. You can already combine
transparency with solid color (I guess from the pdf-file, that you want
that), but you can also combine transparency with gradients. You need
not even use the same kind of gradient. It seems you have not yet
discovered the property 'Gradient' in the Transparency tab of the Area
dialog.
> Because this will break compatibillity with older Versions of OO I
> think there should be as much changes as
> possible to prevent having to do big changes in the future to the
> gradients stuff.
> So here is my suggestion to the GUI part (pdf file:
> http://temp-share.com/show/f3Ygit6Xn).
> The coding part is up to you cause that's out of my scope.
We tend to make the draw stuff more like svg. Already now it is possible
to use a svg-graphic; and its gradients are rendered nicely.
Besides that, changes have to be compatible with ODF or find its way in
the next version of ODF.
> I would like you guys to think about how this could be implemented and
> if there is a better way to
> do it on the GUI side (maybe an extra button which will pop-up an
> extra window for the editing of
> the gradient???).
Area > Gradient is already the dialog page to edit gradients. What
editing feature do you miss on that page? But keep in mind, that color
gradient and transparency are independent properties.
> Please fuck the licensing issues so the code can be used in both
> projects.
>
If a developer provides his work under AL2, it can be used in both
projects. So its up to the individual developer. Changes done in AOO can
always be used in LO.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org