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 <jogischm...@gmail.com>:
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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
