TTF2TFM
gul791
I am looking for some documentation of ttf2tfm utility by Frederic
Loyer and Werner Lemberg. Do they write/publish any paper on it?
Thanks and regards,
Atif
Werner Lemberg
> 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.
Any volunteers for maintainance?
Werner
Michael Zedler
> Any volunteers for maintainance?
I never quite understood what's the advantage of ttf2tfm over
ttf2afm+fontinst.
Michael
gul791
why I am looking for techincal information for ttf2tfm utility.
gul791
Paul Vojta
Michael Zedler <Michael...@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.
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 can understand why ttf2afm is useful (i.e., for pdftex, since its
font model is based on PostScript), but not for dvi creation.
--Paul Vojta, vo...@math.berkeley.edu
Michael Zedler
> In article <dnu2op$ari$1...@wsc10.lrz-muenchen.de>,
> Michael Zedler <Michael...@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.
Michael
Paul Vojta
Michael Zedler <Michael...@tum.de> wrote:
>Paul Vojta schrieb:
>> In article <dnu2op$ari$1...@wsc10.lrz-muenchen.de>,
>> Michael Zedler <Michael...@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.
--Paul Vojta, vo...@math.berkeley.edu
Michael Zedler
> 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. ;-)
Best,
Michael
Michael Zedler
> 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.
Michael