Arrow heads with hole

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Arrow heads with hole

Regina Henschel
Hi all,

I have expanded the standard.soe with some arrow heads with hole. The
file is attached to https://issues.apache.org/ooo/show_bug.cgi?id=123758.
If you like them, we can consider to use this palette as default.

Kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Joost Andrae-2
Moin Regina,

I like this pallette.

Am 26.11.2013 16:33, schrieb Regina Henschel:
> Hi all,
>
> I have expanded the standard.soe with some arrow heads with hole. The
> file is attached to https://issues.apache.org/ooo/show_bug.cgi?id=123758.
> If you like them, we can consider to use this palette as default.

Kind regards, Joost



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Andrea Pescetti-2
In reply to this post by Regina Henschel
On 26/11/2013 Regina Henschel wrote:
> I have expanded the standard.soe with some arrow heads with hole. The
> file is attached to https://issues.apache.org/ooo/show_bug.cgi?id=123758.
> If you like them, we can consider to use this palette as default.

I added a screenshot to the issue for clearer comparison. The new styles
are nice and it would be good to have them in 4.1.

In some cases, in the preview, I see the main line of the arrow going
(seemingly) too far within the arrow head, see
http://imagebin.org/280257 for an example. Is this wanted?

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Regina Henschel
Hi Andrea,

Andrea Pescetti schrieb:

> On 26/11/2013 Regina Henschel wrote:
>> I have expanded the standard.soe with some arrow heads with hole. The
>> file is attached to https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>> If you like them, we can consider to use this palette as default.
>
> I added a screenshot to the issue for clearer comparison. The new styles
> are nice and it would be good to have them in 4.1.
>
> In some cases, in the preview, I see the main line of the arrow going
> (seemingly) too far within the arrow head, see
> http://imagebin.org/280257 for an example. Is this wanted?

No, that is not wanted. I will explain the problem in more detail:

If you stop the line at the very place where the arrow head starts, you
get a visible gap between the "square 45°" and the line itself for fat
lines (and same for circle or any peak shape). Therefore an overlap was
introduced. For the filled arrow heads, it does not matter whether the
line is drawn a little bit longer.

For the arrow heads with hole you have to find a compromise between
showing a gap at the outer part and showing a little bit line in the hole.

Currently the amount by which the line is drawn longer does not depend
on the kind of arrow head, but on the length of the arrow head. It is in
file polygonprimitive2d.cxx in method
PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547 the
statement "fStart *= 0.8;"
In LO I have changed that to "fStartOverlap = getStart().getWidth() /
15.0;", so that it depends on the width of the arrow head, which also
determines the 'stroke' width in the non-filled arrow heads. It is a
compromise too. (It is not really a 'stroke', but the area between two
combined paths.)

We could copy that in AOO. But perhaps someone has a better idea?

Kind regards
Regina



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Jürgen Schmidt-3
On 12/2/13 11:45 PM, Regina Henschel wrote:

> Hi Andrea,
>
> Andrea Pescetti schrieb:
>> On 26/11/2013 Regina Henschel wrote:
>>> I have expanded the standard.soe with some arrow heads with hole. The
>>> file is attached to
>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>> If you like them, we can consider to use this palette as default.
>>
>> I added a screenshot to the issue for clearer comparison. The new styles
>> are nice and it would be good to have them in 4.1.
>>
>> In some cases, in the preview, I see the main line of the arrow going
>> (seemingly) too far within the arrow head, see
>> http://imagebin.org/280257 for an example. Is this wanted?
>
> No, that is not wanted. I will explain the problem in more detail:
>
> If you stop the line at the very place where the arrow head starts, you
> get a visible gap between the "square 45°" and the line itself for fat
> lines (and same for circle or any peak shape). Therefore an overlap was
> introduced. For the filled arrow heads, it does not matter whether the
> line is drawn a little bit longer.
>
> For the arrow heads with hole you have to find a compromise between
> showing a gap at the outer part and showing a little bit line in the hole.
>
> Currently the amount by which the line is drawn longer does not depend
> on the kind of arrow head, but on the length of the arrow head. It is in
> file polygonprimitive2d.cxx in method
> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547 the
> statement "fStart *= 0.8;"
> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
> 15.0;", so that it depends on the width of the arrow head, which also
> determines the 'stroke' width in the non-filled arrow heads. It is a
> compromise too. (It is not really a 'stroke', but the area between two
> combined paths.)
>
> We could copy that in AOO. But perhaps someone has a better idea?

perhaps Armin our graphic guru has a further idea otherwise I would
suggest you add this code a change and the new palette. I like it

Juergen

>
> Kind regards
> Regina
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Armin.Le.Grand@me.com
In reply to this post by Regina Henschel
     Hi Regina,

On 02.12.2013 23:45, Regina Henschel wrote:

> Hi Andrea,
>
> Andrea Pescetti schrieb:
>> On 26/11/2013 Regina Henschel wrote:
>>> I have expanded the standard.soe with some arrow heads with hole. The
>>> file is attached to
>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>> If you like them, we can consider to use this palette as default.
>>
>> I added a screenshot to the issue for clearer comparison. The new styles
>> are nice and it would be good to have them in 4.1.
>>
>> In some cases, in the preview, I see the main line of the arrow going
>> (seemingly) too far within the arrow head, see
>> http://imagebin.org/280257 for an example. Is this wanted?
>
> No, that is not wanted. I will explain the problem in more detail:

First: nice arrowheads! I am currently on something else, but I have
already a grep on the task which you wrote.

Background:
- The arrows traditionally only used polygons (topologically: no
poly-polygons which allows holes). This is alrteady changed and implemented.
- The arrow heads and line overlapping traditionally use a 0.0 or 0.8
factor of overlap, according to 0% or 80% overlap. These values are
handles relative to the arrow head sizes already, but are treated as a
boolean (one or the other). In the core these values are prepared to be
0-100%, freely choosable. In the UI you can switch between 0% and 80% in
the lines dialog in it's first page (line ends-> 'centered' for right
and left arrow). Missing is to have a value input instead of that simple
switch and to get that 0-100% value over the API and to ODF. This is
where normally Regina knows if this is possible ;-)
Thus: Old. historical limitations, some more way to go to get over
these. When one day it will be possible to choose that value freely
(prepared in core and primitives) you will be able to trim these to
connect to your arrow head as you want it to be.
If there would be a way to do this automatically could also be
considered; the old overlapping paint was probably only implemented
since no one wanted to do it better from the beginning (time constrains?
other?).

Regina, this sounds as if we could use a feature task for his...

>
> If you stop the line at the very place where the arrow head starts,
> you get a visible gap between the "square 45°" and the line itself for
> fat lines (and same for circle or any peak shape). Therefore an
> overlap was introduced. For the filled arrow heads, it does not matter
> whether the line is drawn a little bit longer.
>
> For the arrow heads with hole you have to find a compromise between
> showing a gap at the outer part and showing a little bit line in the
> hole.
>
> Currently the amount by which the line is drawn longer does not depend
> on the kind of arrow head, but on the length of the arrow head. It is
> in file polygonprimitive2d.cxx in method
> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
> the statement "fStart *= 0.8;"
> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
> 15.0;", so that it depends on the width of the arrow head, which also
> determines the 'stroke' width in the non-filled arrow heads. It is a
> compromise too. (It is not really a 'stroke', but the area between two
> combined paths.)
>
> We could copy that in AOO. But perhaps someone has a better idea?
>
> Kind regards
> Regina
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Jürgen Schmidt-3
On 12/3/13 6:05 PM, Armin Le Grand wrote:

>     Hi Regina,
>
> On 02.12.2013 23:45, Regina Henschel wrote:
>> Hi Andrea,
>>
>> Andrea Pescetti schrieb:
>>> On 26/11/2013 Regina Henschel wrote:
>>>> I have expanded the standard.soe with some arrow heads with hole. The
>>>> file is attached to
>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>> If you like them, we can consider to use this palette as default.
>>>
>>> I added a screenshot to the issue for clearer comparison. The new styles
>>> are nice and it would be good to have them in 4.1.
>>>
>>> In some cases, in the preview, I see the main line of the arrow going
>>> (seemingly) too far within the arrow head, see
>>> http://imagebin.org/280257 for an example. Is this wanted?
>>
>> No, that is not wanted. I will explain the problem in more detail:
>
> First: nice arrowheads! I am currently on something else, but I have
> already a grep on the task which you wrote.
>
> Background:
> - The arrows traditionally only used polygons (topologically: no
> poly-polygons which allows holes). This is alrteady changed and
> implemented.
> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
> factor of overlap, according to 0% or 80% overlap. These values are
> handles relative to the arrow head sizes already, but are treated as a
> boolean (one or the other). In the core these values are prepared to be
> 0-100%, freely choosable. In the UI you can switch between 0% and 80% in
> the lines dialog in it's first page (line ends-> 'centered' for right
> and left arrow). Missing is to have a value input instead of that simple
> switch and to get that 0-100% value over the API and to ODF. This is
> where normally Regina knows if this is possible ;-)
> Thus: Old. historical limitations, some more way to go to get over
> these. When one day it will be possible to choose that value freely
> (prepared in core and primitives) you will be able to trim these to
> connect to your arrow head as you want it to be.
> If there would be a way to do this automatically could also be
> considered; the old overlapping paint was probably only implemented
> since no one wanted to do it better from the beginning (time constrains?
> other?).
>
> Regina, this sounds as if we could use a feature task for his...
>

Do I understand correct that with Reginas fix the arrows looks much
better and the problem is less obvious.

If yes I would still integrate it because it is an improvement. And if
possible improve it further later on. But we should not wait for a 100%
solution that most of the user even don't recognize.

Well that is only my personal opinion.

Juergen


>>
>> If you stop the line at the very place where the arrow head starts,
>> you get a visible gap between the "square 45°" and the line itself for
>> fat lines (and same for circle or any peak shape). Therefore an
>> overlap was introduced. For the filled arrow heads, it does not matter
>> whether the line is drawn a little bit longer.
>>
>> For the arrow heads with hole you have to find a compromise between
>> showing a gap at the outer part and showing a little bit line in the
>> hole.
>>
>> Currently the amount by which the line is drawn longer does not depend
>> on the kind of arrow head, but on the length of the arrow head. It is
>> in file polygonprimitive2d.cxx in method
>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>> the statement "fStart *= 0.8;"
>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>> 15.0;", so that it depends on the width of the arrow head, which also
>> determines the 'stroke' width in the non-filled arrow heads. It is a
>> compromise too. (It is not really a 'stroke', but the area between two
>> combined paths.)
>>
>> We could copy that in AOO. But perhaps someone has a better idea?
>>
>> Kind regards
>> Regina
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Armin Le Grand-3
Hi Juergen,

yes, of course we should add that stuff, that's what I had in mind. I already have a grep on the task, just wanted to give some background information.
thanks go to regina for alwas bringing something forward!

--
ALG (iPad)

> Am 04.12.2013 um 09:07 schrieb Jürgen Schmidt <[hidden email]>:
>
>> On 12/3/13 6:05 PM, Armin Le Grand wrote:
>>    Hi Regina,
>>
>>> On 02.12.2013 23:45, Regina Henschel wrote:
>>> Hi Andrea,
>>>
>>> Andrea Pescetti schrieb:
>>>>> On 26/11/2013 Regina Henschel wrote:
>>>>> I have expanded the standard.soe with some arrow heads with hole. The
>>>>> file is attached to
>>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>>> If you like them, we can consider to use this palette as default.
>>>>
>>>> I added a screenshot to the issue for clearer comparison. The new styles
>>>> are nice and it would be good to have them in 4.1.
>>>>
>>>> In some cases, in the preview, I see the main line of the arrow going
>>>> (seemingly) too far within the arrow head, see
>>>> http://imagebin.org/280257 for an example. Is this wanted?
>>>
>>> No, that is not wanted. I will explain the problem in more detail:
>>
>> First: nice arrowheads! I am currently on something else, but I have
>> already a grep on the task which you wrote.
>>
>> Background:
>> - The arrows traditionally only used polygons (topologically: no
>> poly-polygons which allows holes). This is alrteady changed and
>> implemented.
>> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
>> factor of overlap, according to 0% or 80% overlap. These values are
>> handles relative to the arrow head sizes already, but are treated as a
>> boolean (one or the other). In the core these values are prepared to be
>> 0-100%, freely choosable. In the UI you can switch between 0% and 80% in
>> the lines dialog in it's first page (line ends-> 'centered' for right
>> and left arrow). Missing is to have a value input instead of that simple
>> switch and to get that 0-100% value over the API and to ODF. This is
>> where normally Regina knows if this is possible ;-)
>> Thus: Old. historical limitations, some more way to go to get over
>> these. When one day it will be possible to choose that value freely
>> (prepared in core and primitives) you will be able to trim these to
>> connect to your arrow head as you want it to be.
>> If there would be a way to do this automatically could also be
>> considered; the old overlapping paint was probably only implemented
>> since no one wanted to do it better from the beginning (time constrains?
>> other?).
>>
>> Regina, this sounds as if we could use a feature task for his...
>>
>
> Do I understand correct that with Reginas fix the arrows looks much
> better and the problem is less obvious.
>
> If yes I would still integrate it because it is an improvement. And if
> possible improve it further later on. But we should not wait for a 100%
> solution that most of the user even don't recognize.
>
> Well that is only my personal opinion.
>
> Juergen
>
>
>>>
>>> If you stop the line at the very place where the arrow head starts,
>>> you get a visible gap between the "square 45°" and the line itself for
>>> fat lines (and same for circle or any peak shape). Therefore an
>>> overlap was introduced. For the filled arrow heads, it does not matter
>>> whether the line is drawn a little bit longer.
>>>
>>> For the arrow heads with hole you have to find a compromise between
>>> showing a gap at the outer part and showing a little bit line in the
>>> hole.
>>>
>>> Currently the amount by which the line is drawn longer does not depend
>>> on the kind of arrow head, but on the length of the arrow head. It is
>>> in file polygonprimitive2d.cxx in method
>>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>>> the statement "fStart *= 0.8;"
>>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>>> 15.0;", so that it depends on the width of the arrow head, which also
>>> determines the 'stroke' width in the non-filled arrow heads. It is a
>>> compromise too. (It is not really a 'stroke', but the area between two
>>> combined paths.)
>>>
>>> We could copy that in AOO. But perhaps someone has a better idea?
>>>
>>> Kind regards
>>> Regina
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Jürgen Schmidt-3
On 12/5/13 12:34 AM, Armin Le Grand wrote:
> Hi Juergen,
>
> yes, of course we should add that stuff, that's what I had in mind. I already have a grep on the task, just wanted to give some background information.
> thanks go to regina for alwas bringing something forward!

well I don't understand why you grep the task, I believe Regina is
knowing quite well what she is doing. We want to grow our developer
community and want to motivate people to work on the code on their own.
We all know that Regina is already working independent and she need if
at all mainly some interlock to discuss, brainstorm certain issues,
problems or solutions.

Independent of this I believe that the experienced developers should
give more guidance to others and help to solve their problems. Even if
it takes longer. This is the way to move forward, let people work on the
code and with the code and provide guidance where necessary.

We don't need to discuss this further and I hope I made my point clearer.

And I hope Regina simply integrate here good work ;-)

Thanks

Regina


>
> --
> ALG (iPad)
>
>> Am 04.12.2013 um 09:07 schrieb Jürgen Schmidt <[hidden email]>:
>>
>>> On 12/3/13 6:05 PM, Armin Le Grand wrote:
>>>    Hi Regina,
>>>
>>>> On 02.12.2013 23:45, Regina Henschel wrote:
>>>> Hi Andrea,
>>>>
>>>> Andrea Pescetti schrieb:
>>>>>> On 26/11/2013 Regina Henschel wrote:
>>>>>> I have expanded the standard.soe with some arrow heads with hole. The
>>>>>> file is attached to
>>>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>>>> If you like them, we can consider to use this palette as default.
>>>>>
>>>>> I added a screenshot to the issue for clearer comparison. The new styles
>>>>> are nice and it would be good to have them in 4.1.
>>>>>
>>>>> In some cases, in the preview, I see the main line of the arrow going
>>>>> (seemingly) too far within the arrow head, see
>>>>> http://imagebin.org/280257 for an example. Is this wanted?
>>>>
>>>> No, that is not wanted. I will explain the problem in more detail:
>>>
>>> First: nice arrowheads! I am currently on something else, but I have
>>> already a grep on the task which you wrote.
>>>
>>> Background:
>>> - The arrows traditionally only used polygons (topologically: no
>>> poly-polygons which allows holes). This is alrteady changed and
>>> implemented.
>>> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
>>> factor of overlap, according to 0% or 80% overlap. These values are
>>> handles relative to the arrow head sizes already, but are treated as a
>>> boolean (one or the other). In the core these values are prepared to be
>>> 0-100%, freely choosable. In the UI you can switch between 0% and 80% in
>>> the lines dialog in it's first page (line ends-> 'centered' for right
>>> and left arrow). Missing is to have a value input instead of that simple
>>> switch and to get that 0-100% value over the API and to ODF. This is
>>> where normally Regina knows if this is possible ;-)
>>> Thus: Old. historical limitations, some more way to go to get over
>>> these. When one day it will be possible to choose that value freely
>>> (prepared in core and primitives) you will be able to trim these to
>>> connect to your arrow head as you want it to be.
>>> If there would be a way to do this automatically could also be
>>> considered; the old overlapping paint was probably only implemented
>>> since no one wanted to do it better from the beginning (time constrains?
>>> other?).
>>>
>>> Regina, this sounds as if we could use a feature task for his...
>>>
>>
>> Do I understand correct that with Reginas fix the arrows looks much
>> better and the problem is less obvious.
>>
>> If yes I would still integrate it because it is an improvement. And if
>> possible improve it further later on. But we should not wait for a 100%
>> solution that most of the user even don't recognize.
>>
>> Well that is only my personal opinion.
>>
>> Juergen
>>
>>
>>>>
>>>> If you stop the line at the very place where the arrow head starts,
>>>> you get a visible gap between the "square 45°" and the line itself for
>>>> fat lines (and same for circle or any peak shape). Therefore an
>>>> overlap was introduced. For the filled arrow heads, it does not matter
>>>> whether the line is drawn a little bit longer.
>>>>
>>>> For the arrow heads with hole you have to find a compromise between
>>>> showing a gap at the outer part and showing a little bit line in the
>>>> hole.
>>>>
>>>> Currently the amount by which the line is drawn longer does not depend
>>>> on the kind of arrow head, but on the length of the arrow head. It is
>>>> in file polygonprimitive2d.cxx in method
>>>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>>>> the statement "fStart *= 0.8;"
>>>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>>>> 15.0;", so that it depends on the width of the arrow head, which also
>>>> determines the 'stroke' width in the non-filled arrow heads. It is a
>>>> compromise too. (It is not really a 'stroke', but the area between two
>>>> combined paths.)
>>>>
>>>> We could copy that in AOO. But perhaps someone has a better idea?
>>>>
>>>> Kind regards
>>>> Regina
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Andre Fischer
On 05.12.2013 08:41, Jürgen Schmidt wrote:
> On 12/5/13 12:34 AM, Armin Le Grand wrote:
>> Hi Juergen,
>>
>> yes, of course we should add that stuff, that's what I had in mind. I already have a grep on the task, just wanted to give some background information.
>> thanks go to regina for alwas bringing something forward!
> well I don't understand why you grep the task, I believe Regina is

I usually know what you mean by grep, but this time I am not sure:
'grep' like the searching the patch for certain key words or 'grab' like
changing owner of the issue ?

> knowing quite well what she is doing. We want to grow our developer
> community and want to motivate people to work on the code on their own.
> We all know that Regina is already working independent and she need if
> at all mainly some interlock to discuss, brainstorm certain issues,
> problems or solutions.
>
> Independent of this I believe that the experienced developers should
> give more guidance to others and help to solve their problems. Even if
> it takes longer. This is the way to move forward, let people work on the
> code and with the code and provide guidance where necessary.
>
> We don't need to discuss this further and I hope I made my point clearer.
>
> And I hope Regina simply integrate here good work ;-)
>
> Thanks
>
> Regina
>
>
>> --
>> ALG (iPad)
>>
>>> Am 04.12.2013 um 09:07 schrieb Jürgen Schmidt <[hidden email]>:
>>>
>>>> On 12/3/13 6:05 PM, Armin Le Grand wrote:
>>>>     Hi Regina,
>>>>
>>>>> On 02.12.2013 23:45, Regina Henschel wrote:
>>>>> Hi Andrea,
>>>>>
>>>>> Andrea Pescetti schrieb:
>>>>>>> On 26/11/2013 Regina Henschel wrote:
>>>>>>> I have expanded the standard.soe with some arrow heads with hole. The
>>>>>>> file is attached to
>>>>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>>>>> If you like them, we can consider to use this palette as default.
>>>>>> I added a screenshot to the issue for clearer comparison. The new styles
>>>>>> are nice and it would be good to have them in 4.1.
>>>>>>
>>>>>> In some cases, in the preview, I see the main line of the arrow going
>>>>>> (seemingly) too far within the arrow head, see
>>>>>> http://imagebin.org/280257 for an example. Is this wanted?
>>>>> No, that is not wanted. I will explain the problem in more detail:
>>>> First: nice arrowheads! I am currently on something else, but I have
>>>> already a grep on the task which you wrote.
>>>>
>>>> Background:
>>>> - The arrows traditionally only used polygons (topologically: no
>>>> poly-polygons which allows holes). This is alrteady changed and
>>>> implemented.
>>>> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
>>>> factor of overlap, according to 0% or 80% overlap. These values are
>>>> handles relative to the arrow head sizes already, but are treated as a
>>>> boolean (one or the other). In the core these values are prepared to be
>>>> 0-100%, freely choosable. In the UI you can switch between 0% and 80% in
>>>> the lines dialog in it's first page (line ends-> 'centered' for right
>>>> and left arrow). Missing is to have a value input instead of that simple
>>>> switch and to get that 0-100% value over the API and to ODF. This is
>>>> where normally Regina knows if this is possible ;-)
>>>> Thus: Old. historical limitations, some more way to go to get over
>>>> these. When one day it will be possible to choose that value freely
>>>> (prepared in core and primitives) you will be able to trim these to
>>>> connect to your arrow head as you want it to be.
>>>> If there would be a way to do this automatically could also be
>>>> considered; the old overlapping paint was probably only implemented
>>>> since no one wanted to do it better from the beginning (time constrains?
>>>> other?).
>>>>
>>>> Regina, this sounds as if we could use a feature task for his...
>>>>
>>> Do I understand correct that with Reginas fix the arrows looks much
>>> better and the problem is less obvious.
>>>
>>> If yes I would still integrate it because it is an improvement. And if
>>> possible improve it further later on. But we should not wait for a 100%
>>> solution that most of the user even don't recognize.
>>>
>>> Well that is only my personal opinion.
>>>
>>> Juergen
>>>
>>>
>>>>> If you stop the line at the very place where the arrow head starts,
>>>>> you get a visible gap between the "square 45°" and the line itself for
>>>>> fat lines (and same for circle or any peak shape). Therefore an
>>>>> overlap was introduced. For the filled arrow heads, it does not matter
>>>>> whether the line is drawn a little bit longer.
>>>>>
>>>>> For the arrow heads with hole you have to find a compromise between
>>>>> showing a gap at the outer part and showing a little bit line in the
>>>>> hole.
>>>>>
>>>>> Currently the amount by which the line is drawn longer does not depend
>>>>> on the kind of arrow head, but on the length of the arrow head. It is
>>>>> in file polygonprimitive2d.cxx in method
>>>>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>>>>> the statement "fStart *= 0.8;"
>>>>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>>>>> 15.0;", so that it depends on the width of the arrow head, which also
>>>>> determines the 'stroke' width in the non-filled arrow heads. It is a
>>>>> compromise too. (It is not really a 'stroke', but the area between two
>>>>> combined paths.)
>>>>>
>>>>> We could copy that in AOO. But perhaps someone has a better idea?
>>>>>
>>>>> Kind regards
>>>>> Regina
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
l

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Jürgen Schmidt-3
On 12/5/13 9:17 AM, Andre Fischer wrote:

> On 05.12.2013 08:41, Jürgen Schmidt wrote:
>> On 12/5/13 12:34 AM, Armin Le Grand wrote:
>>> Hi Juergen,
>>>
>>> yes, of course we should add that stuff, that's what I had in mind. I
>>> already have a grep on the task, just wanted to give some background
>>> information.
>>> thanks go to regina for alwas bringing something forward!
>> well I don't understand why you grep the task, I believe Regina is
>
> I usually know what you mean by grep, but this time I am not sure:
> 'grep' like the searching the patch for certain key words or 'grab' like
> changing owner of the issue ?

I noticed this just after sending the mail, it should have been grab of
course ;-)

Juergen

>
>> knowing quite well what she is doing. We want to grow our developer
>> community and want to motivate people to work on the code on their own.
>> We all know that Regina is already working independent and she need if
>> at all mainly some interlock to discuss, brainstorm certain issues,
>> problems or solutions.
>>
>> Independent of this I believe that the experienced developers should
>> give more guidance to others and help to solve their problems. Even if
>> it takes longer. This is the way to move forward, let people work on the
>> code and with the code and provide guidance where necessary.
>>
>> We don't need to discuss this further and I hope I made my point clearer.
>>
>> And I hope Regina simply integrate here good work ;-)
>>
>> Thanks
>>
>> Regina
>>
>>
>>> --
>>> ALG (iPad)
>>>
>>>> Am 04.12.2013 um 09:07 schrieb Jürgen Schmidt <[hidden email]>:
>>>>
>>>>> On 12/3/13 6:05 PM, Armin Le Grand wrote:
>>>>>     Hi Regina,
>>>>>
>>>>>> On 02.12.2013 23:45, Regina Henschel wrote:
>>>>>> Hi Andrea,
>>>>>>
>>>>>> Andrea Pescetti schrieb:
>>>>>>>> On 26/11/2013 Regina Henschel wrote:
>>>>>>>> I have expanded the standard.soe with some arrow heads with
>>>>>>>> hole. The
>>>>>>>> file is attached to
>>>>>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>>>>>> If you like them, we can consider to use this palette as default.
>>>>>>> I added a screenshot to the issue for clearer comparison. The new
>>>>>>> styles
>>>>>>> are nice and it would be good to have them in 4.1.
>>>>>>>
>>>>>>> In some cases, in the preview, I see the main line of the arrow
>>>>>>> going
>>>>>>> (seemingly) too far within the arrow head, see
>>>>>>> http://imagebin.org/280257 for an example. Is this wanted?
>>>>>> No, that is not wanted. I will explain the problem in more detail:
>>>>> First: nice arrowheads! I am currently on something else, but I have
>>>>> already a grep on the task which you wrote.
>>>>>
>>>>> Background:
>>>>> - The arrows traditionally only used polygons (topologically: no
>>>>> poly-polygons which allows holes). This is alrteady changed and
>>>>> implemented.
>>>>> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
>>>>> factor of overlap, according to 0% or 80% overlap. These values are
>>>>> handles relative to the arrow head sizes already, but are treated as a
>>>>> boolean (one or the other). In the core these values are prepared
>>>>> to be
>>>>> 0-100%, freely choosable. In the UI you can switch between 0% and
>>>>> 80% in
>>>>> the lines dialog in it's first page (line ends-> 'centered' for right
>>>>> and left arrow). Missing is to have a value input instead of that
>>>>> simple
>>>>> switch and to get that 0-100% value over the API and to ODF. This is
>>>>> where normally Regina knows if this is possible ;-)
>>>>> Thus: Old. historical limitations, some more way to go to get over
>>>>> these. When one day it will be possible to choose that value freely
>>>>> (prepared in core and primitives) you will be able to trim these to
>>>>> connect to your arrow head as you want it to be.
>>>>> If there would be a way to do this automatically could also be
>>>>> considered; the old overlapping paint was probably only implemented
>>>>> since no one wanted to do it better from the beginning (time
>>>>> constrains?
>>>>> other?).
>>>>>
>>>>> Regina, this sounds as if we could use a feature task for his...
>>>>>
>>>> Do I understand correct that with Reginas fix the arrows looks much
>>>> better and the problem is less obvious.
>>>>
>>>> If yes I would still integrate it because it is an improvement. And if
>>>> possible improve it further later on. But we should not wait for a 100%
>>>> solution that most of the user even don't recognize.
>>>>
>>>> Well that is only my personal opinion.
>>>>
>>>> Juergen
>>>>
>>>>
>>>>>> If you stop the line at the very place where the arrow head starts,
>>>>>> you get a visible gap between the "square 45°" and the line itself
>>>>>> for
>>>>>> fat lines (and same for circle or any peak shape). Therefore an
>>>>>> overlap was introduced. For the filled arrow heads, it does not
>>>>>> matter
>>>>>> whether the line is drawn a little bit longer.
>>>>>>
>>>>>> For the arrow heads with hole you have to find a compromise between
>>>>>> showing a gap at the outer part and showing a little bit line in the
>>>>>> hole.
>>>>>>
>>>>>> Currently the amount by which the line is drawn longer does not
>>>>>> depend
>>>>>> on the kind of arrow head, but on the length of the arrow head. It is
>>>>>> in file polygonprimitive2d.cxx in method
>>>>>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>>>>>> the statement "fStart *= 0.8;"
>>>>>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>>>>>> 15.0;", so that it depends on the width of the arrow head, which also
>>>>>> determines the 'stroke' width in the non-filled arrow heads. It is a
>>>>>> compromise too. (It is not really a 'stroke', but the area between
>>>>>> two
>>>>>> combined paths.)
>>>>>>
>>>>>> We could copy that in AOO. But perhaps someone has a better idea?
>>>>>>
>>>>>> Kind regards
>>>>>> Regina
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> l
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Andrea Pescetti-2
In reply to this post by Jürgen Schmidt-3
On 04/12/2013 Jürgen Schmidt wrote:
> Do I understand correct that with Reginas fix the arrows looks much
> better and the problem is less obvious.

Regina's changes introduce more styles for arrow heads, see the
comparison I posted at
https://issues.apache.org/ooo/show_bug.cgi?id=123758

Unfortunately, some of the new "outline" arrow heads exhibit the graphic
problem being dicussed here (i.e., the arrow "body" goes into the arrow
head), but I don't consider this a blocker.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Arrow heads with hole

Armin.Le.Grand@me.com
In reply to this post by Jürgen Schmidt-3
     Hi Juergen,

On 05.12.2013 08:41, Jürgen Schmidt wrote:
> On 12/5/13 12:34 AM, Armin Le Grand wrote:
>> Hi Juergen,
>>
>> yes, of course we should add that stuff, that's what I had in mind. I already have a grep on the task, just wanted to give some background information.
>> thanks go to regina for alwas bringing something forward!
> well I don't understand why you grep the task, I believe Regina is
> knowing quite well what she is doing.

That's right, 'grep' was not in the sense that I will do it, more in
having a hook on it to not loose it out of sight...

> We want to grow our developer
> community and want to motivate people to work on the code on their own.
> We all know that Regina is already working independent and she need if
> at all mainly some interlock to discuss, brainstorm certain issues,
> problems or solutions.

Yes, that's what I and Regina normally do.

>
> Independent of this I believe that the experienced developers should
> give more guidance to others and help to solve their problems. Even if
> it takes longer. This is the way to move forward, let people work on the
> code and with the code and provide guidance where necessary.
>
> We don't need to discuss this further and I hope I made my point clearer.

You are storming open doors here.

>
> And I hope Regina simply integrate here good work ;-)
>
> Thanks
>
> Regina
>
>
>> --
>> ALG (iPad)
>>
>>> Am 04.12.2013 um 09:07 schrieb Jürgen Schmidt <[hidden email]>:
>>>
>>>> On 12/3/13 6:05 PM, Armin Le Grand wrote:
>>>>     Hi Regina,
>>>>
>>>>> On 02.12.2013 23:45, Regina Henschel wrote:
>>>>> Hi Andrea,
>>>>>
>>>>> Andrea Pescetti schrieb:
>>>>>>> On 26/11/2013 Regina Henschel wrote:
>>>>>>> I have expanded the standard.soe with some arrow heads with hole. The
>>>>>>> file is attached to
>>>>>>> https://issues.apache.org/ooo/show_bug.cgi?id=123758.
>>>>>>> If you like them, we can consider to use this palette as default.
>>>>>> I added a screenshot to the issue for clearer comparison. The new styles
>>>>>> are nice and it would be good to have them in 4.1.
>>>>>>
>>>>>> In some cases, in the preview, I see the main line of the arrow going
>>>>>> (seemingly) too far within the arrow head, see
>>>>>> http://imagebin.org/280257 for an example. Is this wanted?
>>>>> No, that is not wanted. I will explain the problem in more detail:
>>>> First: nice arrowheads! I am currently on something else, but I have
>>>> already a grep on the task which you wrote.
>>>>
>>>> Background:
>>>> - The arrows traditionally only used polygons (topologically: no
>>>> poly-polygons which allows holes). This is alrteady changed and
>>>> implemented.
>>>> - The arrow heads and line overlapping traditionally use a 0.0 or 0.8
>>>> factor of overlap, according to 0% or 80% overlap. These values are
>>>> handles relative to the arrow head sizes already, but are treated as a
>>>> boolean (one or the other). In the core these values are prepared to be
>>>> 0-100%, freely choosable. In the UI you can switch between 0% and 80% in
>>>> the lines dialog in it's first page (line ends-> 'centered' for right
>>>> and left arrow). Missing is to have a value input instead of that simple
>>>> switch and to get that 0-100% value over the API and to ODF. This is
>>>> where normally Regina knows if this is possible ;-)
>>>> Thus: Old. historical limitations, some more way to go to get over
>>>> these. When one day it will be possible to choose that value freely
>>>> (prepared in core and primitives) you will be able to trim these to
>>>> connect to your arrow head as you want it to be.
>>>> If there would be a way to do this automatically could also be
>>>> considered; the old overlapping paint was probably only implemented
>>>> since no one wanted to do it better from the beginning (time constrains?
>>>> other?).
>>>>
>>>> Regina, this sounds as if we could use a feature task for his...
>>>>
>>> Do I understand correct that with Reginas fix the arrows looks much
>>> better and the problem is less obvious.
>>>
>>> If yes I would still integrate it because it is an improvement. And if
>>> possible improve it further later on. But we should not wait for a 100%
>>> solution that most of the user even don't recognize.
>>>
>>> Well that is only my personal opinion.
>>>
>>> Juergen
>>>
>>>
>>>>> If you stop the line at the very place where the arrow head starts,
>>>>> you get a visible gap between the "square 45°" and the line itself for
>>>>> fat lines (and same for circle or any peak shape). Therefore an
>>>>> overlap was introduced. For the filled arrow heads, it does not matter
>>>>> whether the line is drawn a little bit longer.
>>>>>
>>>>> For the arrow heads with hole you have to find a compromise between
>>>>> showing a gap at the outer part and showing a little bit line in the
>>>>> hole.
>>>>>
>>>>> Currently the amount by which the line is drawn longer does not depend
>>>>> on the kind of arrow head, but on the length of the arrow head. It is
>>>>> in file polygonprimitive2d.cxx in method
>>>>> PolygonStrokeArrowPrimitive2D::create2DDecomposition around line#547
>>>>> the statement "fStart *= 0.8;"
>>>>> In LO I have changed that to "fStartOverlap = getStart().getWidth() /
>>>>> 15.0;", so that it depends on the width of the arrow head, which also
>>>>> determines the 'stroke' width in the non-filled arrow heads. It is a
>>>>> compromise too. (It is not really a 'stroke', but the area between two
>>>>> combined paths.)
>>>>>
>>>>> We could copy that in AOO. But perhaps someone has a better idea?
>>>>>
>>>>> Kind regards
>>>>> Regina
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]