[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goal of current programming
From: |
Werner LEMBERG |
Subject: |
Re: goal of current programming |
Date: |
Wed, 14 Apr 2004 08:32:41 +0200 (CEST) |
> > A good thing would be to allow 32bit input character codes.
I mean *internally*, in case I was unclear.
> 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.
I'm not sure what you exactly mean, but I *strongly* suggest to follow
the Adobe model, that is, accessing glyphs with glyph names only. (I
forgot that in my last mail.) So you should do this:
external input representation (latin-1, utf-8, ebcdic, ...)
=>
internal input representation (UTF-32, using PUA where necessary)
[*] =>
AGL glyph names
=>
output font encoding
(AGL is the Adobe Glyph List). The place marked with [*] is the very
point where the formatting happens. It should also have an external
interface for complicated conversions, to be applied sequentially. I
can imagine
. Omega Translation Processes (OTP) for rearranging the input stream
(e.g. for Indic scripts), possibly handled by an external process.
Perhaps Pango oder ICU provide something similar?
. An interface to LaTeX for sophisticated text formatting. It
should accept DVI-like commands (together with PS or PDF
\specials) on return.
The above ideas and suggestions are for direct PS output, of course.
So what does `\encoding "latin1"' really do? The phrase `latin1 is
used to look up glyphs in the selected font' mangles input and output
terms...
For `traditional' (La)TeX output the interface is much simpler (which
I plan to implement); I've described that already in another mail.
> 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?
For Type 1 fonts, no. Each cm-super font, for example, has almost 700
glyphs. The alternative is to convert Type 1 fonts (TTF, CID-keyed PS
fonts, etc.) on the fly to CFF. Have a look at the CVS version of
dvipdfmx which does an excellent job:
cvs -d:pserver:address@hidden:/home/cvsroot login
cvs -d:pserver:address@hidden:/home/cvsroot co dvipdfmx
I haven't found time to let the PS front-end of groff do this -- it is
a non-trivial change and probably not worth the time for groff. You
might talk to the dvipdfmx people to provide the Type1/TTF/...->CFF
conversion as a library. Another guy (on the FreeType list) had a
similar need, so you are not alone...
> A way to access glyphs by name directly, so you can do
>
> (adieresis oumlaut leftarrow) show_by_name
This is not supported by PostScript, AFAIK.
> To top that, the demand for this seems relatively low, and it can
> also be catered for by LaTeX hacks.
I don't understand this sentence. Please rephrase.
Werner