Re: Corner handling (was Re: Rounded corners)

[Hans Breuer <hans breuer org>]

Am 31.05.2008 06:18, Don Blaheta schrieb:
> Ok, I think the problem here is that I sidetracked myself into thinking
> primarily about rounded corners, when I was most interested in
> consistent and, preferably, intuitive handling of corners among the
> various object types.  What I've learned is that the various renderers
> have the concept of a line join _built in_, and that the available ones
> are mitre, bevel, and round, present in both the Cairo renderers and in
> the Gdk renderers.
>
> I think that using these will address my concerns; here's the framework
> I suggest (elaborated from a previous version):
>
> 1. Add pulldown "join type" parameter to box, polygon, polyline,
> zigzagline, and possibly bezierline and beziergon (for when they have
> cusp rendering).  This menu would have values mitre (default), bevel,
> and round.
As written before: "But this still does not solve the problem of small 
radius not being rendered well with DiaGdkRenderer. And it is not 
consistent with what other renderers currently do."
So we need to define the behaviour for the radius anyway.

> 2. Remove "corner radius" parameter from polyline, zigzagline, since its
> use is basically subsumed by rounded joins.
This is not true. For radius bigger than line width there is a huge 
difference. And we are not breaking exisiting diagrams/use-cases lightly - 
if at all. So removing the radius is not an option.

> 3. Leave "corner radius" in box, where it triggers a rounded rectangle
> to be drawn instead of a regular rectangle; "join type" is still present
> but is ignored.
It should be set anyway but it probably will not have a visible impact, at 
least not if we solve the small arc issue like I proposed.

> Within that framework, two bugs can be fixed:
>
> #535871, to do with rounded corners on polyline and zigzagline,
> automatically goes away since it arises from manually fiddling with
> arcs.
At the moment this is just a guess, isn't it? The seams you are describing 
in bug #535871 are from my understanding renderer specific. I haven't seen 
them with the cairo renderer yet and from my understanding they are 
probably to be fixed in cairo. At least my understanding is Dia is 
requesting a continous line in diacairorenderer.c(_rounded_rect)

> #534275, to do with (lack of) joins on lines and consistency between
> objects, is likewise fixed.  (Part of this may have already been fixed
> in the SVN trunk even before my report; I don't see a recent change that
> would have fixed it.  Curiously, if I save a file using the SVN version
> and open it with 0.96.1, the boxes *do* have mitred joins, but then if I
> double click them and immediately click "apply" they go away!)
These seams are very hard to get a grip on. I just noticed that not only 
the zoom but also the placement on the screen (just moving aound the 
viewport with the arrow keys) can make them appear or disappear.

> I've done some proof-of-concept hacking and it looks like the Gdk and
> Cairo renderers both handle MITER and ROUND beautifully.  I've got other
> stuff tomorrow, but if the above thoughts seem reasonable I'll try to
> put together a patch on Sunday.
As oulined above and in previos mails I'm fine with explicit adding of 
LINEJOIN to the user interface, if we can find a clean definition. But just 
removing the "corner radius" is not an option.

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert