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)
Tracking
()
NEW
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).
Updated•8 years ago
|
status-firefox50:
--- → unaffected
status-firefox51:
--- → affected
status-firefox52:
--- → affected
status-firefox53:
--- → affected
Updated•8 years ago
|
Reporter | ||
Comment 2•8 years ago
|
||
(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)
Updated•8 years ago
|
Comment 3•7 years ago
|
||
lsalzman - was this all covered in the fix for bug 1343813?
Flags: needinfo?(lsalzman)
Reporter | ||
Comment 4•7 years ago
|
||
(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)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•