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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
