gul791 <atif.gul...@gmail.com> wrote: > I am looking for some documentation of ttf2tfm utility by Frederic > Loyer and Werner Lemberg. Do they write/publish any paper on it?
What do you need? Currently, ttf2tfm is a kind of orphan since I don't have time to maintain it. For example, it should be updated to use FreeType 2... There are patches for this floating around in the internet to do that, but it doesn't have priority for me.
> In article <dnu2op$ar...@wsc10.lrz-muenchen.de>, > Michael Zedler <Michael.Zed...@tum.de> wrote: >> I never quite understood what's the advantage of ttf2tfm over >> ttf2afm+fontinst.
> Well, TeX uses numbers and not names to refer to glyphs. > Ttf also uses numbers and not names to refer to glyphs.
Please have a look at what role encodings play, for TTF t1-wgl4.enc is of particular interest.
> If you use ttf2afm, you have to assign names to your glyphs so that they > can be removed by afm2tfm. Sounds kind of pointless to me.
I referred to fontinst, not afm2tfm. The former is quite useful to generate T1/TS1 encoded fonts as well as to correct kerning flaws. For the user who is mainly interested in a quick installation the most obvious advantage is the automatic generation of fd+map files.
> I can understand why ttf2afm is useful (i.e., for pdftex, since its > font model is based on PostScript), but not for dvi creation.
This is not correct, please have a look at how your dvi viewer/dvips/pdftex treat fonts. Neither is it related to the question ttf2tfm vs. ttf2afm+fontinst.
In article <dnvalm$1b...@wsc10.lrz-muenchen.de>, Michael Zedler <Michael.Zed...@tum.de> wrote:
>Paul Vojta schrieb: >> In article <dnu2op$ar...@wsc10.lrz-muenchen.de>, >> Michael Zedler <Michael.Zed...@tum.de> wrote: >>> I never quite understood what's the advantage of ttf2tfm over >>> ttf2afm+fontinst.
>> Well, TeX uses numbers and not names to refer to glyphs. >> Ttf also uses numbers and not names to refer to glyphs.
>Please have a look at what role encodings play, for TTF t1-wgl4.enc is >of particular interest.
OK, let's look at t1-wgl4.enc. First of all, there's the line:
/T1Encoding [ % now 256 chars follow
Now ttf fonts are 16-bit (at least), and Omega is 16-bit (at least), so I don't see why one would want to thread font access in Omega through an 8-bit needle.
Next there's the line:
/grave /acute /circumflex /tilde
In a PostScript font, the strings "grave", "acute", etc. are the procedure names for the glyph-drawing routines in the font. They are the primary means for addressing the glyph routines.
In TrueType, however, glyph names (as I understand it) are optional.
>> If you use ttf2afm, you have to assign names to your glyphs so that they >> can be removed by afm2tfm. Sounds kind of pointless to me.
>I referred to fontinst, not afm2tfm. The former is quite useful to >generate T1/TS1 encoded fonts as well as to correct kerning flaws. >For the user who is mainly interested in a quick installation the most >obvious advantage is the automatic generation of fd+map files.
OK, so the names are removed by fontinst instead of by afm2tfm.
>> I can understand why ttf2afm is useful (i.e., for pdftex, since its >> font model is based on PostScript), but not for dvi creation.
>This is not correct, please have a look at how your dvi >viewer/dvips/pdftex treat fonts. Neither is it related to the question >ttf2tfm vs. ttf2afm+fontinst.
What exactly is not correct?
My dvi viewer (which is "mine" perhaps in a greater sense than you anticipated) is xdvi (non-k). It is set up to treat ttf fonts via mktexpk, which calls ttf2pk (a program related to ttf2tfm). It does not use tfm files directly.
dvips (at our site) handles ttf fonts in exactly the same way. Look at another thread currently running on comp.text.tex to see how dvips handles (or doesn't handle) ttf fonts.
Yes, pdftex does use PostScript-style encoding files for ttf fonts, but I don't know any reasons for doing so other than for uniformity with handling of PostScript fonts.
The OP (in a subsequent message) mentioned that s/he wanted to add OpenType (hence ttf) support natively in Omega. Therefore, my answer above is framed in terms of what a good design would be, rather than what is in place right now.
I have no objections to encoding files per se, but enc files in the style of t1-wgl4.enc were designed for PostScript fonts, and are not well suited for use with ttf fonts. If one uses encoding files with ttf fonts at all, they should be in a ttf-specific format. However, I don't see a need for them, since TrueType fonts already contain an encoding. If you don't like the encoding, then use a virtual font. Of course, the encoding is 16-32 bits wide, but Omega can handle that.
> Now ttf fonts are 16-bit (at least), and Omega is 16-bit (at least), so > I don't see why one would want to thread font access in Omega through > an 8-bit needle.
To my knowledge, tfm are restricted to 8bit, thus ttf->tfm->ofm has an 8bit bottleneck.
> In a PostScript font, the strings "grave", "acute", etc. are the procedure > names for the glyph-drawing routines in the font. They are the primary > means for addressing the glyph routines.
> In TrueType, however, glyph names (as I understand it) are optional.
Both correct. But. The glyph numbers in the tfm don't refer to the ttf glyph index, but to an encoding vector, just like for PS fonts. (For mf fonts the "encoding vector" is implicit to the mf sources) If one of a) "tfm is 8bit" and b) "tfm point to positions in an encoding vector" don't hold, then yes, I see a need for ttf2tfm.
>>> I can understand why ttf2afm is useful (i.e., for pdftex, since its >>> font model is based on PostScript), but not for dvi creation. >> This is not correct, please have a look at how your dvi >> viewer/dvips/pdftex treat fonts. Neither is it related to the question >> ttf2tfm vs. ttf2afm+fontinst.
> What exactly is not correct?
> My dvi viewer (which is "mine" perhaps in a greater sense than you > anticipated) is xdvi (non-k). It is set up to treat ttf fonts via > mktexpk, which calls ttf2pk (a program related to ttf2tfm). It does not > use tfm files directly.
ttf2pk is run to get the bitmap representation of the requested glyph. But the tfm is never read by the dvi viewer??? I don't see in what aspect a dvi viewer behaves differently from dvips (that is set up to use pk fonts).
> dvips (at our site) handles ttf fonts in exactly the same way. > Look at another thread currently running on comp.text.tex to see how > dvips handles (or doesn't handle) ttf fonts.
Do you refer to my posting? There for sure a PS style encoding vector is needed. BTW, is there hope that dvips will rather soon be extended to read ttf and otf, PLEASE? And to extend dvips that it can generate autoexpanded versions of tfm on the fly, just like pdftex? (I'm running pdftex in dvi mode with font expansion, this requires a massive number of tfm/vf in localtexmf)...
> Yes, pdftex does use PostScript-style encoding files for ttf fonts, > but I don't know any reasons for doing so other than for uniformity > with handling of PostScript fonts.
What else would you recommend? CID? Even if one used CID I don't see how to avoid encoding vectors, though (then its contents aren't glyph names but CID positions).
> The OP (in a subsequent message) mentioned that s/he wanted to add > OpenType (hence ttf) support natively in Omega. Therefore, my answer > above is framed in terms of what a good design would be, rather than > what is in place right now.
see above, I'm curious to see 16bit tfm pointing directly to ttf glyph indices. ;-)
> If one of a) "tfm is 8bit" and b) "tfm point to positions in an encoding > vector" don't hold, then yes, I see a need for ttf2tfm.
Addendum: For CJK and the like, ttf2tfm's subfont definition feature is excellent and really needed, I refer to latin/greek/cyrillic scripts only.
> BTW, is there hope that dvips will rather soon be extended to > read ttf and otf, PLEASE?
Concerning otf, isn't there only a dvips-internal routine to convert the otf into pfb/pfa needed? The code of http://www.lcdf.org/type/cfftot1.1.html should be useful.
