Carl Peterson <carlopeter...@gmail.com> writes: > On Tue, Apr 9, 2013 at 4:45 PM, David Kastrup <d...@gnu.org> wrote: > > Carl Peterson <carlopeter...@gmail.com> writes: > > > I'm not an expert on GhostScript, but in practice it is nearly > always > > best to rasterize vector graphics at the intended output > resolution. > > > Except when it isn't. What makes you think that the PDF viewers > are > doing anything but rasterizing vector graphics at the intended > output > resolution? > > Even though a PDF viewer is rasterizing at the output resolution, it > isn't rasterizing at the intended resolution of the PDF file. The > basic Lilypond output is intended for output at print resolution (say, > 300dpi or higher). We know this is a factor because Lilypond already > uses multiple versions of the engraving fonts so that smaller and > larger scores are equally "beautiful music."
You are confusing "scale" and "resolution". > Lilypond knows what a stem is and what a staff line is and if it's > producing its own PNG output, it can make sure those elements get > rendered properly for the intended resolution. It might make some sense getting acquainted with the involved mechanisms before lecturing developers. LilyPond does not differentiate _at_ _all_ between producing PNG and producing PDF. In either case, it produces _identical_ PostScript and lets Ghostscript convert it into _either_ PNG _or_ PDF. Ghostscript does a pretty good job at producing viewable PNG, and the PDF preserves the original imprinting information in the PostScript file, so we actually know that PDF viewers _could_ do a reasonable job displaying LilyPond PDFs just fine. They don't, so it turns out that the rendering decisions of typical PDF viewers differ from that of Ghostscript when producing PNG. The question is how we can change the PostScript/PDF in a manner that works better with typical PDF viewers. Now the main problem is that typical PDF viewers don't bother much about graphics but are centered around font display. So one possibility would be to create ad-hoc fonts (including hinting) representing the graphical elements, like rounded rectangles etc, and use those instead of graphical elements. That's mind-numbingly stupid and complex, but it might be feasible. Another possibility would be to do thorough experimentation running through several previewers and implementations of graphic primitives and take a look just what combinations work out well, and what not. Yet another possibility is to see whether there are suitable options for Ghostscript's PS->PDF conversion in order to produce nicer working constructs in the PDF. Again, that's stupid, but at least the complexity would not be ours: we would only have to check whether somebody already did the work for us. But with regard to resolution dependency, one has to take a choice between things rendering with reasonable thickness and things lining up well. One such parameter expressing such a choice is "strokeadjust". > Vectors can be scaled up with out limit and preserve image quality, > but in a raster environment (like a computer screen), they cannot be > scaled down without limit with the same expectation. I might have heard about rasterization. If you are interested in being helpful, it might make sense to stop lecturing ex cathedra and get dirty with the actual code and implementation. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
