On Thu, Jun 16, 2011 at 12:49:12PM -0400, Russ Cox wrote:
> Virtual fonts tricks can't be the correct solution.
Virtual fonts are not the whole solution. To accept, naturally, utf as
input, TeX will have to be adapted (and it is perhaps not as deep as
one could think).
But virtual fonts can use fonts where "glyphes" are not organised
conforming to unicode, leaving the fonts untouched.
That's where the present situation seems not optimal, since afm2tfm(1)
is used to even reencode the PostScript fonts.
> The correct solution is to use a font format that
> can handle >256 glyphs, such as OTF.
> This is what heirloom troff does.
>
> Failing that, it is not clear how much you want to
> hack up tex versus just going along to get along.
> For Latin alphabets, the Plan 9 tex iso has an extra
> style file called 'unicode.sty' that does some serious
> latex heroics to trick latex into interpreting UTF-8
> byte sequences as their corresponding Latex
> equivalents.
See above. But as always, the first step is to simplify things so that
the bottlenecks are clear.
That's what I'm presently doing, and that's why the Bourne shell
conf/KERTEX_T.post-install generates everything (while compiled fonts
are portable for example, and I could simply provide the result for
download): so that a user can see "how it is done"---even if nobody
cares.
Tracking the current acrobatics done between PostScript fonts (or
others), encoding, tex macro. and so on is puzzling to say things
charitably. And trying to understand how it is supposed to work
by scrutinizing the current state is definitively not the best
path (and I suspect that this is really the "wizardry": deceiving by
complexity to hide a simple reality).
I seem to recall reading (by a cursory look) about subfonts in Plan9,
precisely for fonts not describing the whole unicode range.
Modifying TeX to accept utf as input (I mean the compiler/interpreter by
itself; not macros), converting to rune and then using 16 bits à la math
mode to switch inside a font family to the "correct" 256 vector is
something that, for a first step, seems to me both reasonable and
simple.
I think I have even a solution to handle right to left, top to bottom,
bottom to top (??), and mixing these inside a page... but this is not on
the top of the stack (and TeX by itself would be lightly touched; the
core will be put in the font format and the dvi drivers).
One of the best "feature" of the TeX package is... METAFONT. For a
mathematician; for a philologist etc. the ability to create signs is, to
my never humble opinion, a must.
And for example, D.E. Knuth math fonts have both +/- and -/+ glyphes.
This is where you can see the mathematician touch. I have old (19th
century) main math textbooks where these are used to explain vertical
alternatives in a "linear" equation, and the order matters.
troff(1) combined with eqn(1) etc. gives already a superb formatting
medium. But it does not provide the designing of fonts... So the TeX
system has to be adapted.
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
