Closed Bug 791466 Opened 8 years ago Closed 7 years ago

mozPrintCallback does not print the text if private use area chars are used


(Core :: Layout, defect)

Windows 7
Not set





(Reporter: yury, Assigned: bdahl)




(2 files, 3 obsolete files)

If private use area unicode chars are used on the mozPrintCallback-canvas (and hardware acceleration is on) the subsequent text is not printed (even page header/footer).

Steps to replicate:
1. Open attachment
2 [review]. Click "Print Fail" button
3. Select "Microsoft XPS Document Writer" and type the xps-file name
4. Inspect the xps-file

Actual results:
Text "PASS" and page header/footer are not printed

mozPrintCallback and page header/footer are printed

Sometimes invalid functionality persist for normal subsequent chars printing, e.g. when "Print OK", "Print Fail", "Print OK" are performed, the last one will fail as well and page refreshing is not helping.

Switching off the hardware acceleration helps to illuminate the issue.
Blocks: 745025
This case was reduced case of the printing from Looks like the tracemonkey document printing was solved by bug 468568. However the attached test case is still printing wrong. (Due to standard/non-downloadable fonts?)
/ccing Robert and Jonathan to see if they have any ideas.
We're probably hitting _cairo_error/moz_cairo_error for some reason. A breakpoint there should help you figure out the problem.

Both Jonathan and I are swamped with higher-priority bugs.
I think the issue is that we don't handle missing-glyph records in the textrun during canvas DrawText, so we end up sending an invalid glyph ID to the font backend. Brendan, could you try this patch and see if it resolves the problem you're seeing? If this isn't sufficient, please post a backtrace from where the cairo error first arises.
See for a tryserver build with this patch.
Attached patch hack to load scaled font (obsolete) — Splinter Review
Your patch fixes the test case from Yury, but it doesn't fix the case when the font actually has the private use glyph.  It still fails at the same point complaining about a null scaled font.  My hacky patch seems to fix the issue, but I'm sure this should be done some other way.  Bas also mentioned he had a fix for the scaled font and that we should clean up the somewhat duplicate GetCairoScaledFont and CairoScaledFont functions.  Do you have a better way to setup the scaled font?
OK, so there are actually two distinct issues here. One is the failure of canvas text to handle missing-glyph records in any sensible way. I've filed bug 808288 to handle that in its own right.

The second issue is the failure of gfxDWriteFont to set up its mScaledFont in certain cases, while other code is assuming that it will be valid. That's what your patch will fix, but I'd like to know what Bas has in mind, too. Maybe there'd be a tidier way to address this; it looks rather messy and confusing at the moment (across the various platform font classes).
/ccing Bas
Waiting on the try run (, but tested locally and this seems to fix our issue.
Attachment #677843 - Attachment is obsolete: true
Attachment #678809 - Flags: review?(bas)
Comment on attachment 678809 [details] [diff] [review]
fix direct write cairo scaled font

Review of attachment 678809 [details] [diff] [review]:

::: gfx/thebes/gfxDWriteFonts.h
@@ +70,5 @@
>      virtual FontType GetType() const { return FONT_TYPE_DWRITE; }
>      virtual mozilla::TemporaryRef<mozilla::gfx::ScaledFont> GetScaledFont(mozilla::gfx::DrawTarget *aTarget);
> +    cairo_scaled_font_t *GetCairoScaledFont();

nit: virtual here too for consistency
Attachment #678809 - Flags: review?(bas) → review+
Forwarding r+ after nit fix.
Attachment #678809 - Attachment is obsolete: true
Attachment #680724 - Flags: review+
Keywords: checkin-needed
Blocks: 748923
Attachment #677710 - Attachment is obsolete: true
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.