[pdftex] Type 1 font problem

[Allin Cottrell]

I'm having trouble displaying certain PDF files created by pdflatex
and incorporating proprietary Type 1 fonts. I have access to two
Linux systems, call them A and B, and the deal is that PDF files
created from the same sources on either system display correctly on
system A but not on B. The symptoms of incorrect display are: using
xpdf, text appears but is seriously wonky (missing glyphs and
curious blotches), while using evince no text is displayed and I see
"error occurred in libfreetype" on stderr.

The two systems have these characteristics:

A: Fedora fc26
pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex 2017.2.7)
LaTeX2e <2016/03/31>
libfreetype.so.6.13.0

B: Arch (fully updated 2018-01-20)
pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Arch Linux)
(preloaded format=pdflatex)
LaTeX2e <2017-04-15>
libfreetype.so.6.16.0

The Type 1 font families I'm trying are Adobe Caslon, Bulmer MT,
Bembo, Bodoni MT, Baskerville MT and Scotch Roman MT. In each case
I'm using the same, simple LaTeX document for testing. Of these
fonts the first two provoke the problem on System B while the other
four display correctly on both systems.

None of the files provoke any error when examined by pdinfo or qpdf
(though I know these are not rigorous tests). And to be clear, all
of the test files (all fonts, PDF produced on both A and B) display
perfectly correctly on System A in both xpdf and evince. Moreover,
I've been using all of these fonts in LaTeX for many years without
any problem and it's just recently I've noticed that they're not
working on System B.

I tried the experiment of replacing System B's libfreetype with that
from System A, but that didn't make any difference. Then I tried
running System A's xpdf binary on System B: again, no change in
outcome.

Clearly there's something in the PDF rendering stack on System B
that is choking on some of the files. I guess this could be because
(a) some of the PDFs are actually broken according to spec, but the
rendering stack on A is somehow more fault-tolerant and succeeds in
working around the brokenness, or (b) the PDFs are OK and there's a
subtle breakage somewhere in the rendering stack on B (but
apparently not in libfreetype).

Anyone have an idea on how I should proceed to get a more useful
diagnosis? Thanks in advance.

Further info: at http://users.wfu.edu/cottrell/t1problem/ I've put
screenshots of good and bad (xpdf) renditions of my test file, plus
the source fonttest.tex and sample output fonttest.pdf using Adobe
Caslon.

[Karl Berry]

First idea: check that all of the fonts are embedded. (pdffonts will
tell you.) I suspect so, but that's always one thing to check.

Looking at Loading Image..., that
is strange output, to me more indicative of a bug in the font rendering
on system B than anything else. I doubt it is a problem in the PDF,
because the PDF just says "display these characters from this font".

It might help to make a tiny document, just one character from one font
at a large size. Then you can inspect the actual PDFs being created
(including the font embedding) and have some hope of discerning what is
going on, and maybe the strange breakage will appear in some
recognizable way.
(Set \pdfcompresslevel=0 \pdfobjcompresslevel=0 and run with pdftex.)

Another possible test would be to use the fonts in a non-TeX system, if
you can find anything else that still uses Type 1 fonts. (I don't know
of anything.)

Good luck,
Karl

[Allin Cottrell]

Post by Karl Berry
First idea: check that all of the fonts are embedded. (pdffonts will
tell you.) I suspect so, but that's always one thing to check.
Looking at http://users.wfu.edu/cottrell/t1problem/caslon_bad.png, that
is strange output, to me more indicative of a bug in the font rendering
on system B than anything else. I doubt it is a problem in the PDF,
because the PDF just says "display these characters from this font".
It might help to make a tiny document, just one character from one font
at a large size. Then you can inspect the actual PDFs being created
(including the font embedding) and have some hope of discerning what is
going on, and maybe the strange breakage will appear in some
recognizable way.
(Set \pdfcompresslevel=0 \pdfobjcompresslevel=0 and run with pdftex.)
Another possible test would be to use the fonts in a non-TeX system, if
you can find anything else that still uses Type 1 fonts. (I don't know
of anything.)

Thanks, Karl (and also George White). I'll try to follow your advice
and will report back if I find anything definitive.

Allin Cottrell

[Allin Cottrell]

[...]

Post by Allin Cottrell

Post by Karl Berry
Looking at http://users.wfu.edu/cottrell/t1problem/caslon_bad.png, that
is strange output, to me more indicative of a bug in the font rendering
on system B than anything else. I doubt it is a problem in the PDF,
because the PDF just says "display these characters from this font".

[...]

Post by Allin Cottrell
Thanks, Karl (and also George White). I'll try to follow your advice
and will report back if I find anything definitive.

Karl's diagnosis is correct: the problem is in freetype2. The test I
reported earlier (which seemed to exonerate libfreetype) was flawed, I
guess due to caching of shared library code.

There was a substantial change in the Type 1 rendering code in
freetype2 between versions 2.8.1 (2017-09-16) and 2.9 (2018-01-08): a
new "adobe" hinting engine was introduced and is now favored over the
original "freetype" engine by default. However it's possible to build
the library with support for the old engine by defining

T1_CONFIG_OPTION_OLD_ENGINE

in ftoption.h. In that case the "freetype" engine becomes the default
but the "adobe" engine can be selected by exporting

FREETYPE_PROPERTIES="type1:hinting-engine=adobe"

Reliably, use of the adobe engine produces the bad results that I
mentioned, for Adobe Caslon and Monotype Bulmer, while the freetype
engine gives correct results.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[The Thanh Han]

Post by Allin Cottrell

Post by Karl Berry
[...]
Looking at http://users.wfu.edu/cottrell/t1problem/caslon_bad.png, that

Post by Karl Berry
is strange output, to me more indicative of a bug in the font rendering
on system B than anything else. I doubt it is a problem in the PDF,
because the PDF just says "display these characters from this font".

[...]
Thanks, Karl (and also George White). I'll try to follow your advice and
will report back if I find anything definitive.

Karl's diagnosis is correct: the problem is in freetype2. The test I
reported earlier (which seemed to exonerate libfreetype) was flawed, I
guess due to caching of shared library code.
There was a substantial change in the Type 1 rendering code in freetype2
between versions 2.8.1 (2017-09-16) and 2.9 (2018-01-08): a new "adobe"
hinting engine was introduced and is now favored over the original
"freetype" engine by default. However it's possible to build the library
with support for the old engine by defining
T1_CONFIG_OPTION_OLD_ENGINE
in ftoption.h. In that case the "freetype" engine becomes the default but
the "adobe" engine can be selected by exporting
FREETYPE_PROPERTIES="type1:hinting-engine=adobe"
Reliably, use of the adobe engine produces the bad results that I
mentioned, for Adobe Caslon and Monotype Bulmer, while the freetype engine
gives correct results.

It could also be a problem/bug of pdftex.​

Can you please try to turn off font subsetting, so that the fonts are
embedded entirely? If the output is ok, perhaps pdftex is doing something
that makes adobe hinting engine unhappy.

FWIW, I did a preflight check of the pdf in Adobe Acrobat Pro, and did not
find any issue.

Regards,
Thanh

[Allin Cottrell]

Post by The Thanh Han

Post by Allin Cottrell

Post by Karl Berry
[...]
Looking at http://users.wfu.edu/cottrell/t1problem/caslon_bad.png, that

Post by Karl Berry
is strange output, to me more indicative of a bug in the font rendering
on system B than anything else. I doubt it is a problem in the PDF,
because the PDF just says "display these characters from this font".

[...]
Thanks, Karl (and also George White). I'll try to follow your advice and
will report back if I find anything definitive.

Karl's diagnosis is correct: the problem is in freetype2. The test I
reported earlier (which seemed to exonerate libfreetype) was flawed, I
guess due to caching of shared library code.
There was a substantial change in the Type 1 rendering code in freetype2
between versions 2.8.1 (2017-09-16) and 2.9 (2018-01-08): a new "adobe"
hinting engine was introduced and is now favored over the original
"freetype" engine by default. However it's possible to build the library
with support for the old engine by defining
T1_CONFIG_OPTION_OLD_ENGINE
in ftoption.h. In that case the "freetype" engine becomes the default but
the "adobe" engine can be selected by exporting
FREETYPE_PROPERTIES="type1:hinting-engine=adobe"
Reliably, use of the adobe engine produces the bad results that I
mentioned, for Adobe Caslon and Monotype Bulmer, while the freetype engine
gives correct results.

It could also be a problem/bug of pdftex.​
Can you please try to turn off font subsetting, so that the fonts are
embedded entirely? If the output is ok, perhaps pdftex is doing something
that makes adobe hinting engine unhappy.

I did think of that point: I reset pdftex.map to turn off subsetting,
but it didn't help with the PDF display via freetype2 2.9 and the
"adobe" engine.

Post by The Thanh Han
FWIW, I did a preflight check of the pdf in Adobe Acrobat Pro, and did not
find any issue.

That's good to know!

Allin Cottrell

[Allin Cottrell]

Post by Allin Cottrell

Post by The Thanh Han
It could also be a problem/bug of pdftex.​
Can you please try to turn off font subsetting, so that the fonts are
embedded entirely?

I did think of that point: I reset pdftex.map to turn off
subsetting, but it didn't help with the PDF display via freetype2
2.9 and the "adobe" engine.

Another finding that suggests pdftex is blameless. If I compile the
TeX source with latex and view the DVI using xdvik I see the same
thing:

FREETYPE_PROPERTIES="type1:hinting-engine=adobe" xdvi test.dvi

gives corrupted results while

FREETYPE_PROPERTIES="type1:hinting-engine=freetype" xdvi test.dvi

works fine.

I've submitted a freetype2 bug at savannah.

Allin Cottrell

[Werner LEMBERG]

Post by Allin Cottrell
There was a substantial change in the Type 1 rendering code in
a new "adobe" hinting engine was introduced and is now favored over
the original "freetype" engine by default.

A flex handling bug was found in FreeType after release 2.9; this is
already fixed in git. Please try!

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=cc2f3cdecff5a351e7e8961b9f2e389ab740231a

I will do a new FreeType release within a few weeks.


Werner

[Karl Berry]

Hi Werner,

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=cc2f3cdecff5a351e7e8961b9f2e389ab740231a

Thanks. I committed it to TL, just in case the full freetype release
isn't in time for the TL builds this year. (Allin, you'll most easily be
able to try it out when we start pretests for TL.)

P.S. Is it possible to get the diff as simple text from the cgit
interface above? I failed to see it. It did at least let me save the
whole new file as raw text. Oh well, whatever.

[Werner LEMBERG]

Thanks. I committed it to TL, just in case the full freetype release
isn't in time for the TL builds this year. (Allin, you'll most
easily be able to try it out when we start pretests for TL.)

Thanks.

P.S. Is it possible to get the diff as simple text from the cgit
interface above? I failed to see it. It did at least let me save
the whole new file as raw text. Oh well, whatever.

It is possible. Look at the `commit' line (after `committer'); at the
end there is a link `patch' in parentheses.

http://git.savannah.gnu.org/cgit/freetype/freetype2.git/patch/?id=cc2f3cdecff5a351e7e8961b9f2e389ab740231a

Werner