lilypond-devel
[Top][All Lists]
Advanced

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

Re: goal of current programming


From: Werner LEMBERG
Subject: Re: goal of current programming
Date: Wed, 14 Apr 2004 08:32:41 +0200 (CEST)

> > A good thing would be to allow 32bit input character codes.

I mean *internally*, in case I was unclear.

> I don't see so much problems on the input side. ATM, you switch
> encodings on the fly with
>
>   \encoding "latin1"
>
> (only affects \markup though) which means that latin1 is used to
> look up glyphs in the selected font.

I'm not sure what you exactly mean, but I *strongly* suggest to follow
the Adobe model, that is, accessing glyphs with glyph names only.  (I
forgot that in my last mail.)  So you should do this:

    external input representation (latin-1, utf-8, ebcdic, ...)
  =>
    internal input representation (UTF-32, using PUA where necessary)
  [*] =>
    AGL glyph names
  =>
    output font encoding

(AGL is the Adobe Glyph List).  The place marked with [*] is the very
point where the formatting happens.  It should also have an external
interface for complicated conversions, to be applied sequentially.  I
can imagine

  . Omega Translation Processes (OTP) for rearranging the input stream
    (e.g. for Indic scripts), possibly handled by an external process.
    Perhaps Pango oder ICU provide something similar?

  . An interface to LaTeX for sophisticated text formatting.  It
    should accept DVI-like commands (together with PS or PDF
    \specials) on return.  

The above ideas and suggestions are for direct PS output, of course.
So what does `\encoding "latin1"' really do?  The phrase `latin1 is
used to look up glyphs in the selected font' mangles input and output
terms...

For `traditional' (La)TeX output the interface is much simpler (which
I plan to implement); I've described that already in another mail.

> However, I am a little disappointed that you have to kludge around
> with on-the-fly encoding vectors.  Isn't there a neater approach to
> this?

For Type 1 fonts, no.  Each cm-super font, for example, has almost 700
glyphs.  The alternative is to convert Type 1 fonts (TTF, CID-keyed PS
fonts, etc.) on the fly to CFF.  Have a look at the CVS version of
dvipdfmx which does an excellent job:

  cvs -d:pserver:address@hidden:/home/cvsroot login
  cvs -d:pserver:address@hidden:/home/cvsroot co dvipdfmx

I haven't found time to let the PS front-end of groff do this -- it is
a non-trivial change and probably not worth the time for groff.  You
might talk to the dvipdfmx people to provide the Type1/TTF/...->CFF
conversion as a library.  Another guy (on the FreeType list) had a
similar need, so you are not alone...

> A way to access glyphs by name directly, so you can do
>
>       (adieresis oumlaut leftarrow) show_by_name

This is not supported by PostScript, AFAIK.

> To top that, the demand for this seems relatively low, and it can
> also be catered for by LaTeX hacks.

I don't understand this sentence.  Please rephrase.


    Werner




reply via email to

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