Discussion:
urw35 base fonts on CTAN and TL
(too old to reply)
Staszek Wawrykiewicz
2016-09-18 01:04:41 UTC
Permalink
Our "font commission" encountered the following:
on CTAN (and consequently on TeXLive 2016) we have URW base35 fonts
from 2003!:
https://www.ctan.org/tex-archive/fonts/urw/base35

In the meantime those fonts were corrected many times (the version from 2003
had many bugs and "badnesses" :-) )

E.g. on January 2015 there was much better release, and from July 2016 it
seems that fonts are finally proper. Moreover the whole stuff contains also
fonts in the opentype format.

The whole history of changes can be found on:
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=summary

The most recent release:
http://git.ghostscript.com/?p=urw-core35-fonts.git;a=snapshot;h=79bcdfb34fbc
e12b592cce389fa7a19da6b5b018;sf=tgz

The license on CTAN and for GhostScript are exactly the same -- GPL,
so we have full accordance for including the corrected fonts also in TeXLive,
after the whole work of renaming the fonts to the TeX convenions, as it
was done before, and refreshing the new stuff on CTAN.
--
Staszek Wawrykiewicz
***@gust.org.pl
Norbert Preining
2016-09-18 15:10:08 UTC
Permalink
Hi Staszek,
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
aren't.

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 ...

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Reinhard Kotucha
2016-09-19 00:14:07 UTC
Permalink
Post by Norbert Preining
Hi Staszek,
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
aren't.
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
fonts.

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.

Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:***@web.de
------------------------------------------------------------------
t***@schoepfer.info
2017-12-12 16:09:45 UTC
Permalink
Post by Reinhard Kotucha
Post by Norbert Preining
Hi Staszek,
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
aren't.
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.
If this works on Windows...
Is it correct, that if a linux distribution provides another/newest
version of urw-core35 type1 fonts and ghostscript, there is no Problem
with metrics or "same sets of glyphs" when texlive/psnfss uses the same
fonts by changing the corresponding map-files?
I assume generating font description(fd) files and virtual fonts(vf)
would also be necessary, or would there be much more to be done from a
linux distribution point of view?

Johannes
Reinhard Kotucha
2017-12-15 23:28:05 UTC
Permalink
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
Hi Staszek,
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
aren't.
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.
If this works on Windows...
Is it correct, that if a linux distribution provides another/newest
version of urw-core35 type1 fonts and ghostscript, there is no Problem
with metrics or "same sets of glyphs" when texlive/psnfss uses the same
fonts by changing the corresponding map-files?
I assume generating font description(fd) files and virtual fonts(vf)
would also be necessary, or would there be much more to be done from a
linux distribution point of view?
Hi Johannes,
I fear that there is no satisfying solution. We currently have three
different fonts with the same internal variable /FontName. Each
supports a different set of glyphs.

1. TeX Live provides and supports the fonts gratefully donated by
URW. None of the fonts were modified except NimbusSanL-ReguItal
(uhvro8a.pfb) due to a severe bug in /germandbls, see

http://tug.org/~kotucha/germandbls.pdf

The original font is still available (uhvro8a-105.pfb).

2. Ghostscript has subsets of these URW fonts built into the binary.
These fonts are used if there is no file called "Fontmap" in
Ghostscript's search path (GS_LIB). Many glyphs were removed from
the URW fonts but an additional glyph was added to the symbol
font.

According to Chris Liddell, a Ghostscript developer, the sole
reason to provide any fonts at all is to have a replacement for
the Adobe fonts built into PostScript printers. Thus glyphs not
supported by Adobe were removed from the URW fonts.

3. Ghostscript offers an external font package. It comes with its
own Fontmap file and thus overrides the built-in fonts. These
fonts come with additional (Cyrillic) glyphs.

The problem is that all three fonts are incompatible but have the same
/FontName. According to Adobe's Type 1 specification there should
never exist two fonts with the same /FontName.

Many programs do not embed fonts into generated PostScript files but
only mention their name, for instance

/Palatino-Roman findfont

If such a file contains Cyrillic characters, the corresponding glyphs
will only be shown in programs based on Ghostscript (gv, ghostview)
and only if the extended fonts are installed. If you are using the
built-in fonts, even Ghostcript will not display them.

If such a file is used in the TeX world, only the psnfss fonts are
available and the Cyrillic glyphs are lost. It's nasty because users
usually don't get an appropriate error message and often don't notice
that some glyphs don't appear in the final PDF file. And even if they
notice that some glyphs are missing, debugging is extremely painful.

Nothing can be done in TeX Live in order to solve this problem. Every
font can be supported if the necessary files are available but there
is absolutely no way to support different fonts with the same name.

The only reasonable thing you can do as a Linux distributor is to
offer an additional font package as an alternative to Ghostscript's
"urw-base35" fonts. The fonts are here:

http://tug.org/svn/texlive/trunk/Master/tlpkg/tlgs/fonts/

Users cannot install both font packages at the same time because fonts
with the same name are indistinguishable. If you want to provide both
packages though, one of the actual Fontmaps has to be commented out.

This means that lib/Fontmap should either contain the lines

% (Fontmap.GS) .runlibfile
(Fontmap.TeXLive) .runlibfile

or

(Fontmap.GS) .runlibfile
% (Fontmap.TeXLive) .runlibfile

IMO it was a big mistake to modify the original fonts donated by URW
but not to change /FontName. Thus I'm convinced that an alternative
font package based on the original URW fonts as shipped with TeX Live
is by far the best solution. I even recommend to install these fonts
by default because this is the only way to make PostScript files
halfways portable.

Let me know if you are interested in a font package providing the
original URW fonts for use with Ghostscript. During the next three
weeks I'm on leave and thus have more time as usual.

Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:***@web.de
------------------------------------------------------------------
t***@schoepfer.info
2017-12-17 11:06:30 UTC
Permalink
Post by Norbert Preining
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
Hi Staszek,
Post by Staszek Wawrykiewicz
E.g. on January 2015 there was much better release, and from
July
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
Post by Staszek Wawrykiewicz
2016 it seems that fonts are finally proper. Moreover the
whole
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
AFAIR these "new" fonts changed the metrics compared to
previous
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
versions of some glyphs. Since these fonts are used as
replacement
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
for the Base35 fonts, they need to be metric wise equal. But
they
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
aren't.
Then there is the addition of completely insufficient and
broken
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
cyrillic... but I see that they have at least added the
cyrillic
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
glyphs now for all fonts.
I am really not sure what is the best way to proceed, and
maybe the
Post by t***@schoepfer.info
Post by Reinhard Kotucha
Post by Norbert Preining
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
Post by t***@schoepfer.info
Post by Reinhard Kotucha
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
Post by t***@schoepfer.info
Post by Reinhard Kotucha
files for exactly these fonts. This is why I maintain these fonts
in
Post by t***@schoepfer.info
Post by Reinhard Kotucha
TeX Live at all.
The main problem is that the fonts were extended but their
internal
Post by t***@schoepfer.info
Post by Reinhard Kotucha
names (the /FontName variable) were not changed. The Type 1 font
specification (Adobe) clearly says that there shall never exist
two
Post by t***@schoepfer.info
Post by Reinhard Kotucha
different fonts with the same /FontName. For a good reason!
Some time ago someone told me that he created a PostScript graphic
but
Post by t***@schoepfer.info
Post by Reinhard Kotucha
a particular glyph didn't appear in the document created with
LaTeX
Post by t***@schoepfer.info
Post by Reinhard Kotucha
though he could see this glyph in a PS viewer. It took me some
time
Post by t***@schoepfer.info
Post by Reinhard Kotucha
to find out what happened. It turned out that he used a glyph
which
Post by t***@schoepfer.info
Post by Reinhard Kotucha
wasn't supported by psnfss, pdftex assumed that the font provided
by
Post by t***@schoepfer.info
Post by Reinhard Kotucha
ghostscript and that in the texmf tree are identical and
substituted
Post by t***@schoepfer.info
Post by Reinhard Kotucha
the font. Such kind of problems are quite difficult to track
down.
Post by t***@schoepfer.info
Post by Reinhard Kotucha
I'll look into the new fonts anyway. But I don't think that we
can
Post by t***@schoepfer.info
Post by Reinhard Kotucha
use them because they are not compatible with what we have in TeX
now.
Post by t***@schoepfer.info
Post by Reinhard Kotucha
If they turn out to be useful, the only way to make them available
to
Post by t***@schoepfer.info
Post by Reinhard Kotucha
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
Post by t***@schoepfer.info
Post by Reinhard Kotucha
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
Post by t***@schoepfer.info
Post by Reinhard Kotucha
using exactly the same fonts. On Unix there is currently no way
to
Post by t***@schoepfer.info
Post by Reinhard Kotucha
avoid such problems because TeX Live can't provide an adapted
ghostscript installation for all supported platforms.
If this works on Windows...
Is it correct, that if a linux distribution provides another/newest
version of urw-core35 type1 fonts and ghostscript, there is no
Problem
Post by t***@schoepfer.info
with metrics or "same sets of glyphs" when texlive/psnfss uses the
same
Post by t***@schoepfer.info
fonts by changing the corresponding map-files?
I assume generating font description(fd) files and virtual fonts(vf)
would also be necessary, or would there be much more to be done from
a
Post by t***@schoepfer.info
linux distribution point of view?
Hi Johannes,
I fear that there is no satisfying solution.
Thank you very much for the detailed explanation!
Post by Norbert Preining
We currently have three
different fonts with the same internal variable /FontName. Each
supports a different set of glyphs.
1. TeX Live provides and supports the fonts gratefully donated by
URW. None of the fonts were modified except NimbusSanL-ReguItal
(uhvro8a.pfb) due to a severe bug in /germandbls, see
http://tug.org/~kotucha/germandbls.pdf
The original font is still available (uhvro8a-105.pfb).
2. Ghostscript has subsets of these URW fonts built into the binary.
These fonts are used if there is no file called "Fontmap" in
Ghostscript's search path (GS_LIB). Many glyphs were removed from
the URW fonts but an additional glyph was added to the symbol
font.
According to Chris Liddell, a Ghostscript developer, the sole
reason to provide any fonts at all is to have a replacement for
the Adobe fonts built into PostScript printers. Thus glyphs not
supported by Adobe were removed from the URW fonts.
With fontforge, i did a short compare of base35 font Times-Roman from
ctan with the newest fonts-core35 release from
https://github.com/ArtifexSoftware/urw-base35-fonts, which seem to be
the fonts builtin in the newest ghostscript 9.22, by
sfddiff base35/pfb/utmr8a.pfb fonts/NimbusRoman-Regular.t1
There are a lot of differences and new glyphs in the newer font, but it
seems the only glyph missing in the newer font is "commaaccent".
Post by Norbert Preining
3. Ghostscript offers an external font package. It comes with its
own Fontmap file and thus overrides the built-in fonts. These
fonts come with additional (Cyrillic) glyphs.
I'm confused, you mean e.g this
https://packages.debian.org/stretch/gsfonts ?
Post by Norbert Preining
The problem is that all three fonts are incompatible but have the same
/FontName.
[...]
Post by Norbert Preining
Nothing can be done in TeX Live in order to solve this problem. Every
font can be supported if the necessary files are available but there
is absolutely no way to support different fonts with the same name.
If it's true that the github-artifex base35 fonts only misses one glyph
per font,
Would it be possible to make the texlive psnfss package work with this
fonts?
Just to know if i got it right: If it can be done in texlive, would this
base35 problem be solved, if all distributions would "reset", and start
over to only use the newest base35 realease?
Post by Norbert Preining
Let me know if you are interested in a font package providing the
original URW fonts for use with Ghostscript. During the next three
weeks I'm on leave and thus have more time as usual.
Thank you very much for the offer, but i think i can do this on my own
in case.

Johannes
Reinhard Kotucha
2017-12-18 00:14:44 UTC
Permalink
Post by t***@schoepfer.info
I'm confused, you mean e.g this
https://packages.debian.org/stretch/gsfonts ?
Sorry for the confusion. It's confusing indeed. I actually meant the
font package offered by Artifex and formerly by Aladdin. But when I
tried to download the package again, I found a statement on their
website

"The latest font set is included with the Ghostscript package."

I also see now that the built-in fonts have Cyrillic glyphs too. It
seems that current versions provide the same set of fonts regardless
of whether they are compiled into the binary or not. Sounds good at a
first glance but unfortunately the .afm files are missing. They are
not used by Ghostscript itself but are needed by programs which create
PostScript files. Kerning information is only available in .afm files
and not in the actual fonts (.pfa or .pfb). TeX's .tfm files are also
derived from .afm files.

Admittedly I wasn't aware of the Debian package. It seems that it's
derived from the font-package formerly provided by Artifex/Aladdin.
It contains the .afm files at least but I didn't investigate any
further.

The fonts shipped with Ghostscript now are lacking /commaaccent. I'm
quite sure that it's not intended and should be reported.
Post by t***@schoepfer.info
Post by Reinhard Kotucha
The problem is that all three fonts are incompatible but have the same
/FontName.
[...]
Post by Reinhard Kotucha
Nothing can be done in TeX Live in order to solve this problem.
Every font can be supported if the necessary files are available
but there is absolutely no way to support different fonts with
the same name.
If it's true that the github-artifex base35 fonts only misses one
glyph per font, Would it be possible to make the texlive psnfss
package work with this fonts?
Adapting psnfss means to break *all* existing documents using
/commaaccent. At the moment documents are only broken when the
modified fonts are used.
Post by t***@schoepfer.info
Just to know if i got it right: If it can be done in texlive, would
this base35 problem be solved, if all distributions would "reset",
and start over to only use the newest base35 realease?
No, they have to use the original, unmodified URW fonts. It's not
only sufficient that all glyphs supported by psnfss exist in a font,
the opposite is also problematic: If you create a PostScript file with
an external tool and use glyphs which are not supported by nfss, these
files look ok with a Ghostscript viewer but cannot be included in TeX
documents.

The psnfss package is maintained by Walter Schmidt. He deliberately
based it on the original URW fonts because the Type 1 specification
doesn't allow modifications without changing /FontName. And as you
can see now, anything except the original fonts is a moving target.
The psnfss package is immutable for a good reason.

Please note that in the TeX world we need absolute reliability and
stability. I was able to compile my diploma thesis after a quarter
century with LaTeX2e though there was only LaTeX-2.09 at that time and
there was no need to touch any file. This is what TeX users expect.
We cannot adapt TeX packages to moving targets. That would break
zillions of existing documents.

Thus I recommend that Linux distributors provide a separate font
package containing the original URW fonts. I'm not aware of any other
reasonable solution.

Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:***@web.de
------------------------------------------------------------------
Karl Berry
2016-09-18 21:32:22 UTC
Permalink
Staszek - you are reviving this repeated-many-times-over-many-years
discussion as if something has changed? As far as I can see, nothing
has changed. The existing base35 fonts should not be
metric-incompatibly changed, in my opinion, and the experience so far is
that URW does not attempt to retain any compatibility. Which is fine
for them, but not fine for the TeX world.

The new fonts could be released under new names, if it is worthwhile.

And, in fact, Michael Sharpe has already done that for the
times/helv/courier that were the previous release -- the result is his
nimbus15 package on CTAN and TL. He invested a lot of effort in making
the previous "new" release actually usable. I'll send you a proof of
his article about it, and I'll tell him about the new versions.

As for licensing, what could conceivably be useful is if URW released
the new versions under the LPPL so you could use them (ie, add Greek and
Cyrillic) in TeX Gyre. I can't undertake that effort, but it would be
nice. --best, karl.
Reinhard Kotucha
2016-09-19 01:37:19 UTC
Permalink
and the experience so far is that URW does not attempt to retain
any compatibility.
Karl, please don't make URW resposible for all this mess.

Ghostscript developers are the culprits, not URW. Though ghostscript
developers are aware for years that they break everything, they didn't
make the slightest attempt so far to fix the bugs they introduced.

There shall never exist two different fonts with the same /FontName,
according to the Adobe Type 1 Font Format specs. Ghostscript still
ships modified fonts with the original URW font names. *This* is the
cause of all the trouble.

There is no reason to blame URW for anything. There is absolutely
nothing URW did wrong. They gratefully donated the fonts, no more, no
less. They provided an update in 2002 in order to add the Euro symbol
and nothing had been changed since then. The culprits are others.
Definitely!

Therefore TeX Live provides the original URW fonts. Whatever is
shipped with ghostscript is a moving target and thus absolutely
unusable in the TeX world. Everything can change at any time. Only
the original fonts donated by URW are reliable.

Regards,
Reinhard
--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:***@web.de
------------------------------------------------------------------
Karl Berry
2017-12-17 23:12:00 UTC
Permalink
seems the only glyph missing in the newer font is "commaaccent".

My recollection from looking at a previous update from URW is that there
were changes in the metrics and kerning tables too.

Just to know if i got it right: If it can be done in texlive, would this
base35 problem be solved, if all distributions would "reset", and start
over to only use the newest base35 realease?

No. If we overtly changed the base35 fonts in TL, old documents will
typeset differently. That's not acceptable.

What can be done is to make a new font package with the new fonts, and
then people who want them can have them. Michael Sharpe did this for a
previous update from URW with just the "core 3",
Times/Helvetica/Courier, fonts: https://ctan.org/pkg/nimbus15
Michael's article about the work might be of interest:
http://tug.org/TUGboat/tb37-2/tb116sharpe.pdf
(and his articles about his many other font projects might be of related
interest: http://tug.org/TUGboat/Contents/listauthor.html#Sharpe,Michael )

With enough work by the interested and willing parties, options could be
given to existing psnfss and other packages to switch to the new fonts,
once they are available. But we can't (or rather, I won't) just change
the fonts out from under the TeX world. --best, karl.
Loading...