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