PDF file created with "Print to File" has bad FontBBox for Type-1 fonts

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
4 years ago
3 years ago

People

(Reporter: diff381, Unassigned)

Tracking

37 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

171 bytes, text/html
Details
56.60 KB, application/pdf
Details
(Reporter)

Description

4 years ago
Created attachment 8594493 [details]
test.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150403142340

Steps to reproduce:

Using a Linux version of Firefox, go to a URL which will have a Type-1 font when printed, like http://cairographics.org/ , press Ctrl-P, select "Print to File" and "Output Format:" "PDF". Grep the output file for FontBBox or open in Adobe Reader (Windows 7). 
I attached a simple test html file that will produce the same error, but with a different Type-1 font than the above URL uses. 


Actual results:

When you open the file in Adobe Reader, a message box with text similiar to this will be displayed:
"The font 'SJDGHA+NimbusSansL' contains a bad /BBox."


Expected results:

The file should open without a message box.
(Reporter)

Comment 1

4 years ago
More details:
A Type-1 font will produce a line like this in the output PDF file:
   /FontBBox [ 0 0 1 0 ]
but the line should look more like this:
   /FontBBox [ -769 -346 1679 1109 ]
(The "bad" line implies tha the font has no height, which is not reasonable.)
I verified that the FontBox lines in the Type-1 fonts on my system are "normal looking".

I have been aware of this problem for several years, but my current system consists of:
- Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.0
- Lubuntu 14.04.2 LTS (also tried Ubuntu 14.04.2 LTS and Xubuntu 14.04.2 LTS) - without forcing the font, Lubuntu is more likely to use a Type-1 font
- Adobe Reader 11.0.10 (Windows 7)

This bug report from Chrome indicates that Reader checks this value more than it should (per the standard), but it is still a bug with Firefox (or possible Cairo Graphics) becuase the FontBBox value is clearly incorrect.
https://code.google.com/p/chromium/issues/detail?id=124572
(Reporter)

Comment 2

4 years ago
Created attachment 8594494 [details]
test.pdf

This is a sample pdf output from the attached test.html file.

Output of: grep -a FontBBox test.pdf
   /FontBBox [ 0 0 1 0 ]
   /FontBBox [ -769 -346 1679 1109 ]

Output of pdffonts test.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
DDKBFF+URWPalladioL                  Type 1            Builtin          yes yes yes      5  0
DSNVVN+DejaVuSerif                   CID TrueType      Identity-H       yes yes yes      6  0

Updated

3 years ago
Component: Untriaged → Printing: Output
Product: Firefox → Core
(Reporter)

Comment 3

3 years ago
I sent an email to the Cairo Graphics mailing list asking if this was a known bug in Cairo and if it had been fixed. The answer was that the the BBox code had been rewritten since 1.9.5 and that the bug no longer exists. (Adrian suggested a test to verify that the bug doesn't exist in newer versions. I tested with version 1.13.1.) Is it possible to update the version of Cairo that Firefox uses?

http://lists.cairographics.org/archives/cairo/2015-June/026327.html
Thanks for digging into this! Bug 739096 tracks the cairo update.
You need to log in before you can comment on or make changes to this bug.