Re: Rounded corners

Am 30.05.2008 09:51, Don Blaheta schrieb:
Quoth Hans Breuer:
Am 29.05.2008 05:37, Don Blaheta schrieb:
The biggest, I think, is that "corner radius" is being used to mean two
different things: the radius of rounding for a rounded rectangle, and
the radius of rounding for the cap of a regular rectangle.
If I understand the terminology correctly 'caps' are only at the end of lines, see e.g.: [...] ; but we need 'joins' here because we are
talking about the radius between line segments, see: [...]

Aha, I learn something every day.  Yes, I've been using the word "cap"
but I meant "join".  Reading the rest of your email, I'm definitely
convinced that trying to merge the join style with the corner radius is
a losing proposition, but I like this:

"Rounded" would make a radius of
  exactly half the linewidth.  Polylines and zigzaglines get the
  checkbox as well instead of a corner radius option.
The almost independent parameter which could be given to all the renderers is the line join. Maybe we should allow the user to set it, instead of hardcoding the behaviour for radius>=0 && radius<line_width?

Yes!  I didn't realise that JOIN_MITER and so forth were already-available
options, but having a single parameter for all objects-with-corners that
said whether to render it as pointy or round would be pretty much what I
was hoping for before I got carried away with the separate radius stuff.

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. I'm using the cairo renderer as my reference here because cairos main goal is consistent high quality output for different output devices. See:

With the upcoming release the cairo renderer(s) will loose it's marking as 'experimental'. Currently you still have to pass --with-cairo to configure.

How do Visio and other such programs handle any of this?
I Looked at some other renderers Dia has - namely antialised vias cairo and wmf and the implmentation looks like the radius is applied at the control rectangle. For radius 0 it gives sharp edges, for 0.1 it has an outer radius of almost half of the line width.

Almost half? Surely it is slightly more than half?
I didn't do the exact measuring and I did not yet find the parameters for Gdk to make it always look good.

This still strikes
me as a bit hacky (in that it's only a convention that has "0.0" meaning
"mitred join"---telling it to round the join at a radius of 0 in from
the control point would be perfectly sensible too).  Its meaning is also
not quite transparent, which triggers a usability tradeoff: permitting
some range of roundedness in the joins (though not a _full_ range of
roundedness), at the cost of having a single numeric parameter whose
*primary* modality is really just zero/nonzero.  Even if the underlying
renderers *can* handle the join-radius parameter as you describe, it
might be better to just have a "join type" pulldown (mitre or round).
How would this solve the problem of not being able to render small arcs?

It would be irrelevant to an actual rounded rectangle (no joins!) but
relevant to polylines and zigzaglines.  Oh, and polygons.  Oh! and
cusp-controlled bezierlines and beziergons.  (Which, as I check right
now, appear to have a *bevel* join, actually, at least in the gdk

There is a parameter to be passed for the linejoin, looking at objects/standard/bezier(gon).c reveals LINEJOIN_MITER. If you look with the GdkRenderer at some zoom, you will see approxomation artifacts for extreme curves because there is no native bezier in the Gdk API. Again: please consider looking at it with a more capable renderer, i.e. DiaCairoRenderer. Plain Gdk will never give as good results as that - and it depends more on the underlying windowing system (X or win32/GDI for Dia).

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]