Re: goal of current programming

[Werner LEMBERG]

> If we want to replace [La]TeX titling kludges (in lilypond.py), we
> must at the very least offer something that is capable of printing
> our own examples (Les N'er'eides, S"angers Morgenlied) without
> relying on the TeX backend.  That implies minimal font encoding
> handling.

Be careful to made a distinction between font and input encoding!  Use
the LaTeX model (inputenc vs. fontenc) as the right solution.  Even if
you mean the right thing you should also take care to use the right
wording.

> Problem is, Han-Wen and I know near to nothing about font encoding,
> except that running `info iconv' or `iconv -l' is scary (we found
> out this week).

iconv can only handle input encodings...

> We have not yet found the trick to let someone else implement it,
> and besides, we like to learn by doing.

A good thing would be to allow 32bit input character codes.  This is a
near-time goal IMHO.  Then use iconv (using Bruno Haible's libinconv
if GNU libc isn't used) to transform an external representation as
given in a .ly file (UTF-8, latin1, JIS, whatever) to the internal
32bit entities.  The default should be latin1 to be backwards
compatible.  Perhaps you can scan Emacs-like file variables (-*-
coding: ... -*-) and Local Variables: ...) to get the file's encoding.

Finally, map the internal codes to font encodings (T1, OT1,
AdobeISOLatin, various CID encodings, etc.).

With other words, two commands are needed, e.g.

  \inputencoding = "utf-8"
  \fontencoding  = "LaTeX-T1"

I don't know how much you want to hide \fontencoding, but something
must be there...  Additionally, many PS fonts need an encoding vector
to access more than the first 256 glyphs in it...  Perhaps you want to
provide \fontencoding="AGL" (for Adobe Glyph List), building PS
encoding vectors on the fly in case the default vector isn't
sufficient.  I've implemented something like this in grops (the PS
device of groff) recently, so you might take a look.  Unfortunately, I
haven't found time (since years!) to make groff digest 32bit input
characters :-(

> Yes, that would be nice.  I have been looking at pango a bit (last
> time I looked was in somewhere in 1998/1999), but it seems they
> still not render to PostScript/PDF.  In fact, I was sure that pango
> had a broken postscript render option[1], but I cannot seem to find
> it anymore.

Well, I can't comment here.  You should definitely contact Owen
Taylor...

> > There is still the question how to support non-Latin scripts in
> > general...
> 
> Yes, good question.  I'm not even sure if/how Pango could help.  I'm
> sure that a latex klugde (or even nicely documented workaround) can
> be devised using GUILE, but that would be unrelated to our encoding
> efforts, afaics.

To even think of Pango you need 32bit entities to handle Unicode.


    Werner