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: 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
