[EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen _______________________________________________ bug-lilypond mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-lilypond
