Open Bug 1156083 Opened 10 years ago Updated 2 years ago

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

Categories

(Core :: Printing: Output, defect)

37 Branch
x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: diff381, Unassigned)

Details

Attachments

(2 files)

171 bytes, text/html
Details
56.60 KB, application/pdf
Details
Attached file 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.
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
Attached file 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
Component: Untriaged → Printing: Output
Product: Firefox → Core
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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: