Re: goal of current programming

[Han-Wen Nienhuys]

address@hidden writes:
> > relying on the TeX backend.  That implies minimal font encoding
> > handling.
> 
> Be careful to made a distinction between font and input encoding!  Use

Now that we've dived into this matter, we understand the
distinction. 

> > We have not yet found the trick to let someone else implement it,
> > and besides, we like to learn by doing.
> 
> A good thing would be to allow 32bit input character codes.  This is a

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. The only part which really looks at
encoding is Modified_font_metric::text_dimension (), for it must
lookup the width of a set of glyphs.

Texts are now plain Scheme strings, but I expect that it would be
fairly easy to hack up the lexer to accept UTF (or similar for 32
bit), and translate that internally to a vector of 32bit
numbers. Those could be used in
Modified_font_metric::text_dimension().

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? A way to access glyphs by name directly, so you can do

      (adieresis oumlaut leftarrow) show_by_name

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

-- 

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