Re: various issues from the CVS

[Werner LEMBERG]

> > There is the following ChangeLog entry:
> >
> >   * tex/latin1.enc: Replace /minus with /hyphen.  WL says that's
> >     the latin1 name.
> >
> > This is not correct.
>
> Sorry.  Please fix, otherwise I will later.  No offence intended.

Since I don't really understand what you've done, I leave it to you...

> > I say that the EC fonts don't have a /minus glyph, and that
> > latin1.enc must be adapted accordingly if used as an font encoding
> > vector for EC fonts.  You should probably avoid `latin1.enc' as an
> > output encoding name.  What about renaming it to output-ec.enc or
> > something like that?
>
> It is not used as an output or font-encoding; latin1 is used as
> input-encoding.

What about this for input strings:

  . Map all input encodings to UTF-8.  This makes lilypond see only
    UTF-8 and nothing else.  It might be done with `iconv()' (either
    in glibc or in libiconv).

  . UTF-8 to lilypond internal glyph names.  This is what lilypond
    actually operates on and what lilypond outputs.  It should support
    *any* numbers of glyph names, not just 256.

  . Output drivers convert lilypond's glyph names to something the
    rest of the world understands.  The TeX case I'll discuss below.
    For Type 1 fonts in direct PS output, the AFM files have to be
    scanned for both encoded and unencoded glyphs, and proper encoding
    vectors must be built on the fly to address all glyphs.  In case
    the font uses unusual glyph names, or you want to remap some
    glyphs to other names, don't use an encoding vector but a simple
    many-to-one table like

      foo bar
      baz bar
      ...

    Such tables are *font specific*.

To have a real example, take latin-1 character 0x2D.  This is mapped
to U+002D, which is further mapped to the internal lilypond glyph name
`minus'.  Normally, this would be mapped to the PostScript glyph name
`/minus', but using EC fonts, we need a remapping file (called, say,
ec.map) having an entry

  minus hyphen

so the PS driver actually uses `/hyphen', which is finally added to an
ad-hoc encoding vector.

> That's why I do not understand how you can use TeX input encoding, I
> do not think it make any sense.  TeX input incodin would be 'ascii'
> + anything you select.  latin1 would be a sensible TeX input
> encoding.

I believe that I understand the question now.  The problem is that the
TeX input encoding is basically a special variant of lilypond's output
encoding since TeX receives lilypond's output.

Using the above model, you need a mapping table from lilypond's
internal glyph names to TeX input entities.  Two cases:

  . LilyPond reads TFM files to handle string lengths (getting
    approximate values only: no kerning, no interpretation of macros).
    The user has to specify a font encoding like `T1' (this should
    also be the default) which selects a mapping table from internal
    glyph names to font slots so that LaTeX's glyph handling is
    completely bypassed:

      grave 0x00
      acute 0x01
      ...
      minus 0x2D
      ...

    Example: `minus' -> \char"02D.

  . LilyPond doesn't read TFM files.  In this case, the user has to
    select a LaTeX input encoding like `utf8', and the input strings
    are not interpreted by LilyPond at all but directly sent to the
    TeX engine to get back the string dimensions.[1]  This is a
    two-pass operation which I've suggested earlier already:

      . LilyPond quickly emits all strings to a temporary file (or a
        pipe).

      . TeX reads the temporary file and returns string dimensions in
        another file.

      . LilyPond reads the string dimensions just computed by TeX and
        processes the whole input file.

      . TeX finally prints LilyPond's output.


    Werner


[1] The `correct' mapping is

      LilyPond input -> internal glyph -> TeX input
      encoding          names             encoding