1539074 - Transformed fonts display badly in PDF

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect, P1)

Description

[Mike Spivey]

Attachment: Sample PDF file -- all 'x' characters should have same height

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

View PDF file containing transformed font, prepared using ExtendFont in pdfTeX to condense the glyphs

Actual results:

The height as well as the width of characters is reduced

Expected results:

Reduction in width only, as seen when viewing the same file with Evince

Comment 1

[Brendan Dahl [:bdahl]]

Looks fine on MacOS, but I do see the issue on Linux.

Comment 2

[Vincent Lefevre]

FYI, I also see the issue on Linux with Debian's firefox 95.0.1-1 package.

Comment 3

[Bjoern Voigt]

The same issue applies to Thunderbird 102 and Firefox-109. Font display for transformed fonts in PDF is ugly.

Setting
browser.display.use_document_fonts = 0
fixes the problem, but other users report, that this caused font problems in HTML display.

Comment 5

[Paul Menzel]

Just for the record, this is still happening in Nightly 117.0a1, 20230725211415. The workaround with browser.display.use_document_fonts = 0 also works.

Comment 6

[Calixte Denizet (:calixte)]

It's a bit strange, it wfm on Windows and Mac, I can reproduce the issue on Fedora.
The font used for the second sequence of "x" is a type 1 font and it starts with:

%!PS-AdobeFont-1.1: LucidaTypewriter 1.002
%%CreationDate: 1994 Nov 12 10:47:10
% Bigelow & Holmes, Inc. Pat. Des. 289,422
% Lucida is a registered trademark of Bigelow & Holmes Inc.
11 dict begin
/FontInfo 9 dict dup begin
/version (1.002) readonly def
/Notice (Copyright (c) 1993, 1994 Bigelow & Holmes and Y&Y, Inc. http://www.YandY.com All Rights Reserved.) readonly def
/FullName (Lucida Typewriter) readonly def
/FamilyName (LucidaTypewriter) readonly def
/Weight (Medium) readonly def
/ItalicAngle 0 def
/isFixedPitch true def
/UnderlinePosition -100 def
/UnderlineThickness 50 def
end readonly def
/FontName /URXDVG+LucidaTypewriter-Extend_850 def
/PaintType 0 def
/FontType 1 def
/FontMatrix [0.00085 0 0 0.001 0 0 ] readonly def

In pdf.js, the font is wrapped in a CFF font and we correctly set the matrix transformation:
https://github.com/mozilla/pdf.js/blob/a2eca47ed1882c0c5c59b1943ca1e9333397a49e/src/core/type1_font.js#L340

Out of curiosity, I changed 0.00085 to 0.000085 and on Windows I can see a thin "x" but the same height the first ones, but on Fedora nothing I can see is displayed.
Maybe the min of the x-scale and y-scale factors is taken to adjust the font size... I don't know but it's very likely an issue in FreeType.

:jfkthame, maybe you'd know what be could wrong here.

Comment 7

[Calixte Denizet (:calixte)]

When converting the font, we compute the unitsPerEm value in using the first entry of the FontMatrix which should be ok in the vast majority of the cases because it's more or less expected to have [scale 0 0 scale 0 0] as a font matrix.
So if we consider that usually it's expected to have a square, it makes sense to take the max of the first four values.

Comment 8

[BMO Github Automation]

Attachment: [mozilla/pdf.js] Compute correctly the unitsPerEm value from the fontMatrix when converting a font (bug 1539074) (#18253)

Comment 9

[Mike Spivey]

Isotropic scaling may the most common case, but the non-uniform scaling in the example has the effect of maing a slightly condensed font. Adding a shear transformation can also generate a slanted version of a font. If done carefully and moderately, both these effects are useful, particularly with pdfTeX. The proposed fix will still make such documents display wrongly, so it does not really solve the problem.

Comment 10

[Calixte Denizet (:calixte)]

:Mike Spivey, could you share a pdf with a wrong display ? You can test it in:
https://mozilla.github.io/pdf.js/web/viewer.html
You seem to be a bit sure of you, maybe it means that you've a better fix, could you share it ?
From my pov, taking the max of the first four values should guarantee that the glyph will be contained in a square max * max.

That said, we should probably take the absolute value of those values before taking the max and I don't really know what to do about the translation part of the matrix, but if someone has an example of a pdf which is wrongly rendered, please feel free to share it.

Comment 11

[Calixte Denizet (:calixte)]

I just made a follow-up for fixing the unitsPerEm computation when the fontMatrix has some negative entries:
https://github.com/mozilla/pdf.js/pull/18324
That said this bug should be fixed now, but if you've any other wrong rendering please feel free to file a new bug and we'll find a way to compute correctly unitsPerEm.