Post by Norbert Preining
Post by Staszek Wawrykiewicz
E.g. on January 2015 there was much better release, and from July
2016 it seems that fonts are finally proper. Moreover the whole
AFAIR these "new" fonts changed the metrics compared to previous
versions of some glyphs. Since these fonts are used as replacement
for the Base35 fonts, they need to be metric wise equal. But they
Then there is the addition of completely insufficient and broken
cyrillic... but I see that they have at least added the cyrillic
glyphs now for all fonts.
I am really not sure what is the best way to proceed, and maybe the
new fonts are again metric wise compatible ...
Hi Staszek and Norbert,
the fonts do not only have to be metric compatible, they have to
provide exactly the same sets of glyphs as the original fonts released
by URW and maintained by Walter Schmidt.
The ghostscript fonts shipped with TeX Live are the same as those
which are part of the psnfss LaTeX package. And psnfss provides .tfm
files for exactly these fonts. This is why I maintain these fonts in
TeX Live at all.
The main problem is that the fonts were extended but their internal
names (the /FontName variable) were not changed. The Type 1 font
specification (Adobe) clearly says that there shall never exist two
different fonts with the same /FontName. For a good reason!
Some time ago someone told me that he created a PostScript graphic but
a particular glyph didn't appear in the document created with LaTeX
though he could see this glyph in a PS viewer. It took me some time
to find out what happened. It turned out that he used a glyph which
wasn't supported by psnfss, pdftex assumed that the font provided by
ghostscript and that in the texmf tree are identical and substituted
the font. Such kind of problems are quite difficult to track down.
I'll look into the new fonts anyway. But I don't think that we can
use them because they are not compatible with what we have in TeX now.
If they turn out to be useful, the only way to make them available to
the TeX world is to rename all these fonts (/FontName), create TeX
support files for them, and create two packages, one for TeX and one
for ghostscript. I currently have no idea how to make such fonts
accessible to ghostscript on all platforms.
Please note that the problem I described above occured on Unix.
Windows users are in advantage because both, TeX and ghostscript are
using exactly the same fonts. On Unix there is currently no way to
avoid such problems because TeX Live can't provide an adapted
ghostscript installation for all supported platforms.
BTW, ghostscript developers are aware of the problem. I described the
problem in detail on a TeX related mailing list and noticed later that
someone forwarded this mail to them.
Chris Lidell said that the whole purpose of providing the URW fonts at
all is to support Adobe fonts embedded in printers (for previewing).
The Adobe fonts have much less glyphs than the respective URW fonts.
Thus, ghostscript offers two solutions now:
1. If there is no Fontmap in $GS_LIB, the fonts compiled into the
binary are used. These fonts support only a subset of the URW
2. If you install the gsfonts package, the extended fonts are used
and come with their own Fontmap file. These fonts have much more
glyphs than their counterparts we are using in the TeX world.
Unfortunately neither of these approches is appropriate when TeX is
involved. We need exactly the [sub]sets of fonts which are supported
by TeX (psnfss). No more, no less.
Staszek, you said that the new fonts are also available in OTF format.
I don't see any reason to add them to our ghostscript package because
ghostscript certainly doesn't know what to do with them. In TeX Live,
XeTeX and LuaTeX are the only programs which are aware of OTF.
After all, I'm convinced that the new gsfonts are considerably
improved and I'll look into them soon.
Staszek, you said
Post by Norbert Preining
the version from 2003 had many bugs and "badnesses" :-)
I'm aware of some bugs. Some of them are quite famous: The "T" and
"D" in Palladio (aka Palatino) are completely broken. If you
encountered any other bugs, please let me know.
Reinhard Kotucha Phone: +49-511-3373112
D-30167 Hannover mailto:***@web.de