Re: Improvements to Postscript backend (patches included)

[David Feuer]

On 3/28/06, Han-Wen Nienhuys <address@hidden> wrote:
> David Feuer wrote:

> thanks for you patch.  CAn you have a second look; there are some style
> issues

Sure.  I can't deal with them right now, but I'll try to fix them up
this evening.

> > I'd like
> > to know if it might be possible to make the backend work at a slightly 
> > higher
> > level, which should allow much smaller files (e.g., Postscript could easily
> > understand the concept of "filled dotted quarter note in current note font 
> > with
> > upward stem 3 staff spaces long").

> That's very unlikely. The internal representation is not strictly
> hierarchical, so it's difficult to group different objects (eg. note and
> stem) so they will be output together, and still be sure that all of
> them are processed.

I've searched and searched, but I can't seem to figure out where notes
and text turn into primitive objects sent to the backends.  Could you
point me in the right direction?  Is there an explanation somewhere of
the general process through which parsed Lilypond becomes printed
music?  You say the internal representation is not strictly
hierarchical.  What _is_ the internal representation?  When objects
get broken up for separate processing, might it be reasonable for the
component pieces to point back to their parents?  In any case,
whatever structure the internal representation actually has would most
likely be useful in the backend code.  The image in my mind is an
intermediate program of sorts that is compiled to create Postscript or
TeX output and interpreted to create SVG output.

> can you add some comment explaining in more detail that this is for
> kerning?

Actually, I was rather curious where those numbers were coming from. 
It might be a good idea to use separate routines for placing text, for
placing noteheads, and for whatever else, rather than using just one
glyph placer for all, as they really are rather different.  Text tends
to have a lot of letters on horizontal lines.  Notes tend to be on
lines or spaces in staves.

> Also, can you follow the naming convention, which is
> word_word iso. wordword for PS files.

Sure.

> > +(define (str4 num)
> > +  (format #f "~f" (round4 num)))
>
> can you rename this to something more comprehensible?

num->str4prec?  I couldn't think of anything really good.

> > +;;  s/\.\([0-9]\{-}\)0* /\1 /g
> > +
>
> ?

Sorry.  That's junk.

> >    (format #f "gsave
> > -  /~a ~a ~a output-scale div scalefont setfont\n~a grestore"
> > +  /~a ~a output-scale div selectfont\n~a grestore"
> >           postscript-font-name
> > -         (if cid?
> > -             " /CIDFont findresource "
> > -             " findfont")
>
> I don't understand this? How are CID resources supposed to be loaded now?

According to the Postscript reference, selectfont can be used with CID
resources as well as regular fonts.  Unfortunately, I can't make the
utf-8 regression test work either with or without my changes, so I
can't be sure I got this right.

> >  (define (named-glyph font glyph)
> >    (string-append
> > -   (ps-font-command font) " setfont "
> > +   (ps-font-command font) " "
> >     "/" glyph " glyphshow "))
>
> While you're at it, I think it would improve readability of the SCM file
> when you try to replace string-append in cases like these.

Sure.

David Feuer