[cairo] Trying to figure out some rasterization problems
dak at gnu.org
Sun Apr 21 08:45:42 PDT 2013
Behdad Esfahbod <behdad at behdad.org> writes:
> On 13-04-21 11:13 AM, David Kastrup wrote:
>>>> >> Unfortunately, it _does_ make a difference. Why do we care? Because
>>>> >> note stems are rectangles with rounded corners. Not completely circular
>>>> >> stroke ends, just rounded corners. If we care for stroke adjustment
>>>> >> (which we do), that means our actual shape needs to be represented as an
>>>> >> intersection of a stroke-adjusted rectangle and clipping off the rounded
>>>> >> corners. That clipping apparently removes too much. An easy solution
>>>> >> appears to be to restroke the middle part of the rectangle without any
>>>> >> clipping. Which comes to problem b) which I think Cairo might be
>>>> >> responsible for:
>>> > I still have no idea what you are talking about. Perhaps some images
>>> > would help?
>> What's wrong with "a rectangle with rounded corners"? At any rate,
>> stroke adjustment deals with rasterization on a black&white device: if
>> you have a thin line, the normal PostScript/PDF way is to color all
>> pixels black that have any part inside covered by the filled/stroked
>> region. For thin lines, this adds up to one line of blackness too much
>> on each side. Stroke adjustment checks the total width and reduces it
>> (starting on the side with the larger overhang) by 1 pixel until it is
>> not off more than half a pixel. So 0, 1 or two pixels are culled from
>> the width, depending on where it lies in the rasterization.
> Ok, it makes more sense now.
> But I have to ask: in 2013, who cares about stroke adjustment? Just
> draw a shape and fill it. I'm sure no print would look bad.
The PDF previews on screen look appalling...
This is <URL:http://code.google.com/p/lilypond/issues/detail?id=2658>
and has been rehashed several times over the years. The rendering on
the web pages looks sub-par as well. At any rate, your Duff-Porter
reference makes clear that clip regions and strokes in Cairo should not
cross the same pixel in parallel lines but rather at sufficiently large
angle, and strokes should not have outlines overlapping at small angles.
That kind of information is important for creating PDF files that don't
look awful in Evince and similar previewers when displaying small
features. I haven't found it anywhere.
Ghostview (and similar) work by just rendering opaquely at higher
resolution, then reducing for display. Requires storage and
performance, but is robust against failing assumptions for the
At any rate, thanks for the info. I think I can now find a reasonably
rendering expression for our features on multiple output devices.
More information about the cairo