From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 16 Jun 2011 19:37:59 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110616173759.GA5598@polynum.com> References: <20110616121700.GA9131@polynum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] [RFC] fonts and unicode/utf [TeX] Topicbox-Message-UUID: f0077ff4-ead6-11e9-9d60-3106f5b1d025 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. >=20 > 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 =E0 la mat= h 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. --=20 Thierry Laronde http://www.kergis.com/ Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C