Re: Trying to figure out some rasterization problems
David Kastrup <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
Behdad Esfahbod <[email protected]> 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 heuristics. At any rate, thanks for the info. I think I can now find a reasonably rendering expression for our features on multiple output devices. -- David Kastrup -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo