Open Bug 1329274 Opened 8 years ago Updated 2 years ago

print_via_parent doesn't send all necessary information to reconstruct a Cairo font on the parent process

Categories

(Core :: Printing: Output, defect)

51 Branch
defect

Tracking

()

Tracking Status
firefox50 --- unaffected
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- fix-optional
firefox54 --- fix-optional

People

(Reporter: lsalzman, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

As a follow-up to bug 1309205, it was discovered that when NativeFontResource::CreateScaledFont internally uses ScaledFontBase::PopulateCairoScaledFont (https://dxr.mozilla.org/mozilla-central/source/gfx/2d/ScaledFontBase.cpp?q=ScaledFontBase%3A%3APopulateCairoScaledFont&redirect_type=single#50) to create the associated cairo_scaled_font_t, it assumes that the NativeFontResource contains necessary and sufficient data to do that. This situation arises as a result of the print_via_parent mechanisms introduced in bug 1156742. However, NativeFontResource as it stands only transfers along the TTF, without passing along external/user settings that the cairo_scaled_font_t might require such as things from gfxFontStyle like adjusted size, the font matrix for synthetic italics, and anti-aliasing overrides. Aside from those 3 settings which could probably be factored out and done generically for all platforms, there are some other potential platform specific settings that can be seen here for example: https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxDWriteFonts.cpp?q=gfxDWriteFont%3A%3AGetCairoScaledFont&redirect_type=single#507 Bug 13095205 introduced the notion of instance data for the scaled font recording that could be used to transport this data for platforms other than Linux (whereas Linux was already fixed via that in that bug).
Depends on: 1330643
What's the severity of this for Fx52?
Flags: needinfo?(lsalzman)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #1) > What's the severity of this for Fx52? It would require some further investigation, but I think some of the issues that I initially suspected are mitigated by some trickery in the font code. Namely, the recovery of the Cairo font matrix gets taken care of when the font code, for non-Cairo fonts, sets the Cairo font matrix onto the DrawTarget's transform, which gets recordedly separately. Liekwise, font adjustments in most cases should also get rolled into the ScaledFont's actual size. There may still be some holes where stuff gets lost, but again, I don't think they are as bad as I initially suspected. If we can find a case in the wild of bugs from this, it might warrant someone to go through and audit it eventually to make sure. So let's just say this isn't very critical at the moment...
Flags: needinfo?(lsalzman)
lsalzman - was this all covered in the fix for bug 1343813?
Flags: needinfo?(lsalzman)
(In reply to Bob Owen (:bobowen) from comment #3) > lsalzman - was this all covered in the fix for bug 1343813? Nope, that fix only addressed a GDI font issue on Windows. This still requires an audit.
Flags: needinfo?(lsalzman)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.