Closed Bug 446290 Opened 12 years ago Closed 11 years ago

printing to pdf corrupt in FF3.01


(Core Graveyard :: Widget: OS/2, defect)

Not set


(Not tracked)



(Reporter: joop.nijenhuis, Assigned: mozilla)




(Keywords: verified1.9.0.2)


(3 files)

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; nl-NL; rv: Gecko/2008071518 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; nl-NL; rv: Gecko/2008071518 Firefox/3.0.1

The file uploadpolicy.html from Hobbes just prints nicely to pdf with FF3.0. The same file printed with FF3.01 is corrupted. Adobe won't load it due to an error. Lucide, a pre version, loads the page and its shows lots of carbage or "pdf-code". So something broke in the engine to make a pdf from it. 

Reproducible: Always

Steps to Reproduce:
1. Go to and load upload policy, a link somewhere in the text, but any other html page will do, just happened that I used this one because it was in the directory at that moment.
2. Choose properties, after that choose print example (don't know exactly how its called, do have Dutch)
3. Printing example looks good, top left you can choose for printing. Do so, choose for print to file, you have to pick a directory/file and give it a go. After a short time you have the pdf. Start it with Lucide or Adobe.
Actual Results:  
Just a small part, actual result will differ sometimes
<start example from Lucide>
what someone means, chances are a mere program wouldn't be able to either.
PmDlwo.lfsccl2slOxsnslfolitDpl  -completprwpinf G
Yes, it's right here.
A custom-written hard-coded database and indexing system written in C++, with all flexibility sacrificed for the purpose of speedily
indexing a large FTP site.
<end example from Lucide>

Expected Results:  
What missng here is the layout of larger fonts, bold and so on.
<Start original part html file>
chances are a mere program wouldn't be able to either.
Can you tell me where to find [insert program]?

Yes, it's right here.
What are you using to maintain your database?

A custom-written hard-coded database and indexing system written in C++, with all flexibility sacrificed for the purpose of speedily indexing a large FTP site.
Can I have the sourcecode?
<End part original html file>

Its not possible to copy from the print preview, in that case you could see that the preview is okay, but that the result in pdf is corrupted.
Summary: printing to pdf corrupt → printing to pdf corrupt in FF3.01
Version: unspecified → 3.0 Branch
Attached image screenshot
Interesting. For me, the whole file is OK at first -- except the two last lines which are garbled, as can be seen in this screenshot.

If I continue to use SeaMonkey after printing, without even trying to print to that file again, it gets garbled somehow. If I open it again in Lucide after a while, the first pages display blank or Lucide gives an error message.
This could have to do with a problem that someone mentioned (to me?) earlier, that the file printed to (sometimes?) remains open, until Firefox is closed.
Assignee: nobody → mozilla
Component: General → Widget: OS/2
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → os2
Hardware: Other → PC
Version: 3.0 Branch → Trunk
(In reply to comment #2)
> This could have to do with a problem that someone mentioned (to me?) earlier,
> that the file printed to (sometimes?) remains open, until Firefox is closed.
The old file is erased in favor for the new one. That's indeed an other problem or bug. This time the contents of the file are affected, while my method for getting the pdf-file didn't change from FF3.0 to FF3.01. I think somewhere something is broken, but its odd because almost nothing changed for the OS/2  version of FF. Correct me if I'm wrong.
OK, I debugged the code to make sure that the PDF file is indeed closed after the print. So that's not the problem. When loading a page in AcroRead after printing from Firefox I sometimes get a message that some font cannot be found. So maybe that's where the problem with the Hobbes prints lies, but I have no clue where to start debugging that.
OK, so this should at least fix the problem that we overwrite a printed PDF the second time we print. Instead, we clear the filename that was saved to the preferences and so print to <AppName>_<date>_<time>.pdf on the Desktop unless the user checked the "Print to file" checkbox so that a filename is set otherwise.
Assignee: mozilla → mozilla
Attachment #331523 - Flags: review?(mozilla)
Comment on attachment 331523 [details] [diff] [review]
don't overwrite print PDFs [checked in, mozilla-central and CVS trunk]

Attachment #331523 - Flags: review?(mozilla) → review+
Comment on attachment 331523 [details] [diff] [review]
don't overwrite print PDFs [checked in, mozilla-central and CVS trunk]

OK, so I checked this patch into CVS trunk and mozilla-central (

Will leave this bug open until I manage to find a way to investigate the main problem.
Attachment #331523 - Attachment description: don't overwrite print PDFs → don't overwrite print PDFs [checked in, mozilla-central and CVS trunk]
When printing the upload policy I see a message on the console that says

   could not load glyph 499

This is from cairo-type1-subset.c so this may well be a problem with cairo or even our FontConfig "clone". The resulting PDF crashes Lucide and displays weird in GSview.
I haven't been able to do any more debugging of this but I notice bug 454532 which is about similar problems, although on Windows. Maybe we should watch what solution they come up with and then duplicate it in the OS/2 code if it's not fixed afterwards.
Depends on: 454532
As I was bothered by this again recently, I looked into the "could not load glyph 499" message and its origin. I found that the font that arrives in cairo_type1_font_subset_get_glyph_names_and_widths() is "Helvetica Italic" and the FT_Load_Glyph() call returns error 0xA0 (In FreeType docs it says Syntax_Error, "opcode syntax error" about that) when loading the glyph with the name "afii10108" from that font.

This possibly means that the font is broken, but I have to confirm this and find out if this should be fixed in FreeType or in Cairo.
Attached patch workaroundSplinter Review
Just for reference, this is the patch that I used to work around the problem in cairo.

Instead of bailing out at that failing glyph I just continue processing and set the width to 0. With this I get a fully functional printout of the Hobbes upload policy page.
OK, so the problem seems to have been that the Helvetica Italic font that is shipped with OS/2 (the HELVI.PFB) uses some non-standard tables which confused FreeType. The FT developer was so nice to work around this and the fix is now available to me (see for the code changes), so a change in the Mozilla codebase was not necessary. --> marking FIXED

The next nightly that I will create will have the fix, I hope I will be able to create one this coming weekend.
Closed: 11 years ago
Resolution: --- → FIXED
Also removing the dependency, the other bug with printing to PDF on windows seems to be unrelated. (They don't use FreeType or the cairo-ft font backend.)
No longer depends on: 454532
OK, the (external FreeType) fix for the PDF corruption problem is in Firefox 3.0.4.

The original fix went into CVS in time for the 3.0.2 release, so I mark this as such in hindsight.
Keywords: verified1.9.0.2
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.