Re: \bookpaper parameters ignored

[Han-Wen Nienhuys]

address@hidden writes:
> 
> 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
> problems:
> 
>   . 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.
> 
> Example:
> 
> 
>      0xDF (`ß')                           % in input file
>         |
>         | latin-1-lilypond.inenc
>         |
>         V
>    `germandbls'                           % in lilypond
>         |
>         | lilypond-EC.outenc              % font-dependent
>         |
>         V
>     /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
> newer).

I concur that LilyPond handling of encoding is (too) limited, but it
is sufficient for my needs, and my todo list is already more than
swamped anyway.

I know that you are very busy as well, nevertheless: you have
implemented stuff like this before, you are the primary (only?) one
requesting this feature, and you know a lot more about encoding and
fonts than Jan and I put together. I think that you should consider
contributing this code yourself - in exchange, I can take another long
and hard look at all your other music layout gripes.

The relevant code is actually fairly contained:

* \markup translates strings into

  (encoded-simple ENCODING STRING)

where ENCODING is the current setting of \encoding

* These strings are interpreted by Text_item::interpret_string(),
  which determines the width.

  Currently, it dumps the string as

   (text RECODED-FONT STRING)

  to the output.

  Some changes need to be done here to interact with font selection.

* The output backend (output-ps.scm) sets font and shows the string.

  The changes for on the fly font encoding should go here. 

 

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen