lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improvements to Postscript backend (patches included)


From: Han-Wen Nienhuys
Subject: Re: Improvements to Postscript backend (patches included)
Date: Wed, 29 Mar 2006 01:43:30 +0200
User-agent: Thunderbird 1.5 (X11/20060313)

David Feuer wrote:
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

Have a look at Erik's thesis (he posted it to the list) recently. It has some pointers to more information. In particular, the internals doc by Carl Sorensen.

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.

look at

  void
  Paper_book::output (SCM output_channel)

and

  SCM
  System::get_paper_system ()

(I take it you have seen the SVG backend already?)

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

there already are separate glyph placers, if memory serves.


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

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

num->string-with-4-decimals

hmm, still a little verbose.

   (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.

This should be fixed in CVS.

Werner, do we still need /CIDFont findresource ?

 (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.

ops, I mean "replace with format"

--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com





reply via email to

[Prev in Thread] Current Thread [Next in Thread]