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