[Top][All Lists]

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

Re: \bookpaper parameters ignored

From: Werner LEMBERG
Subject: Re: \bookpaper parameters ignored
Date: Wed, 11 Aug 2004 04:00:04 +0200 (CEST)

I wrote:

> You have to reencode the EC fonts.  If I understand your intentions
> correctly, you want to make the input encoding basically equal to
> the output encoding, this is, for latin1, the glyphs at font
> positions 0x20-0x8F and 0xA0-0xFF should be the same as the input
> encoding values.  Example: latin-1 0xFF (y dieresis) should map to
> output encoding 0xFF too.  For this, lilypond already comes with
> latin1.enc which does exactly this job.

IIRC, I've already suggested the `correct' way to avoid all of these

  . Provide an input encoding mapping which maps input codes to glyph
    entities.  It's easiest to use glyph names for that.

  . Internally, LilyPond only uses those glyph entities.

  . Provide an output encoding mapping which maps glyph entities to
    output entities (either glyph slots or glyph names).

Using this scheme, you can choose *any* input and output encoding,
being completely independent from the nasty details.


     0xDF (`ß')                           % in input file
        | latin-1-lilypond.inenc
   `germandbls'                           % in lilypond
        | lilypond-EC.outenc              % font-dependent
    /germandbls                           % in output file

My proposed lilypond-EC.outenc is not necessarily the same as the
PostScript vector in EC.enc -- the latter can hold only 256 glyphs,
while the former should be able to handle any number of entities.  At
a later stage, you can implement the usage of multiple PS vectors to
address more than 256 glyphs in a (single) Type 1 font.

Have a look at groff's grops driver for PS output (version 1.19 or


reply via email to

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