On 3/28/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel