Re: Cropped output (à la -dpreview) possible in Finale and Sibelius

[David Kastrup]

Carl Peterson <address@hidden> writes:

> On Tue, Apr 9, 2013 at 4:45 PM, David Kastrup <address@hidden> wrote:
>
>     Carl Peterson <address@hidden> 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