Hi Khaled - it seems like it would be nice if
\font\foo = foo.otf
actually tried to look for an otf font, or at least
gave an error message. Right now, it silently ignores the .otf and looks for foo.tfm.
For example, this one-line plain tex file:
\nopagenumbers \font\x = lmroman10-regular.otf \x hello. \end
The current code sort of does this, but it only checks for font names, so
\font\x = LMRoman10-Regular \x hello. \end
works. It should be easy to extend it to try to find fonts by file names as well, but it will still try to invokemktextfm
first so would still be as confusing.May be we can make
mktextfm
a better smarter to just skip fonts without an associated.mf
file to avoid the scary looking metafont error?i was thinking that if the .otf extension is explicitly specified, then mktextfm should never be called; it should just do the opentype lookup. does that make sense?
doing filename lookup as well fontname lookup: yes please!!
thanks.
What we do now is that we just do the regular TFM search (which in turn triggers
mktextfm
in kpathsea) and if it failed, we try to locate it through the “native” fonts path. This seems the least disruptive way to me (any font definition that worked with TeX82 should continue to work unchanged), but I’ll see if it is not too hard to try to use file name extension (we would then need to also support.ttf
,.ttc
,.pfb
etc.).not pfb; they don't have the right metrics. does .ttf have enough metrics?
that is what makes otf different - a tfm is not needed. that is, i was imagining that the change would be making
\font\foo = x.otf
the same as
\font\foo = [x.otf]
It seems pointless to make people have to give the square brackets in this case. the code is already there.
tx.
XeTeX already allows contructs like
\font\foo="[foo.pfb"]
(or even loading a Type1 font by font name if it is system installed), so I asume FreeType can find all the metrics XeTeX needs. TTF fonts has all what we need of course.fine, but this doesn't answer the original point: if a user explicitly asks for .otf, it is just confusing to look for tfm/pfb instead.
if "[foo.pfb]" doesn't also look for foo.tfm, the typesetting results will be terribly inferior -- just for example, there could be no interword stretch/shrink. i hope that doesn't happen.
system fonts are a different case altogether, naturally.