1343813 - FF 51 incorrectly prints cyrillic fonts with applied font-styles

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[work.alexkhv]

Attachment: bug_data.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

This bug can be reproduced in Windows Server 2008R2 (and some other Windows versions) with latest Firefox installed.

1) Open 'sample.htm' from attachement in Firefox;
2) Ensure that print preview looks fine (similar to 'win2008r2_ff51_print_preview.png' in attachement);
3) Proceed and print the page on a real printer. Print the same page to PDF.

Bug does not relate to printer drivers: this problem was faced multiple times by users with different environments.



Actual results:

On the printed page some lines with applied font style, such as boldness, etc, contain corrupted cyrillic symbols or question marks. All letters in lines with applied font style have incorrect symbol spacings (see  'win2008r2_ff51_print_result.pdf').

PDF-printed file has similar issues with cyrillic fonts, but font styles are gone: none of the lines are bold or italic (see 'print_to_pdf_win2008r2_ff51_result.pdf').


Expected results:

Printed page (either on a real printer or to pdf) should look the same as the html page or the print preview. See correct printed results in files:
1) 'win10x64_ff51_print_result.pdf' - html printed in Windows 10 Pro x64 in FF v51;
2) 'win2008r2_chrome49_print_result.pdf' - html printed in Windows Server 2008R2 in Chrome v49;
3) 'print_to_pdf_win2008r2_chrome49_result.pdf' - html file printed in Windows Server 2008R2 in Chrome v49 to  pdf;

Comment 1

[uskovm]

Ran into this problem too.

Comment 2

[Loic]

Attachment: sample.htm

Comment 3

[Loic]

I can't reproduce it with FF51 on Win 7, but it looks like a variant of bug 1108922.

Comment 4

[VaSGyuRo]

Have you a solution for this bug?
I have now 2 PCs (Windows 10 & Windows 7, both with FF52 but this is irrelevant) doing this issue.
Refresh Firefox temporally solve it...

Comment 5

[Loic]

Attachment: print_to_pdf_win2008r2_ff51_result.pdf

Comment 6

[Loic]

Attachment: win2008r2_ff51_print_result.pdf

Comment 7

[Loic]

I determined it happens only with e10s enabled and HWA disabled. That makes sense on Win 2008, because the server has probably outdated/old drivers not supported anymore by Firefox to enable HWA. But e10s is probably turned on by default.

Comment 8

[Loic]

Could you type about:support in the location bar and paste:
1) line "multiprocess windows"
2) the section "graphics"

Comment 9

[Loic]

In addition, as workaround, could you change in about:config:
browser.tabs.remote.autostart=false
browser.tabs.remote.autostart.2=false
(restart FF to apply)

Comment 10

[VaSGyuRo]

You solved it!

browser.tabs.remote.autostart was false, but browser.tabs.remote.autostart.2 was true!
After i modified it to FALSE, it works like a charm ! :)

Thank you!

Comment 11

[Loic]

That said, it means you have HWA disabled in your profile. Honestly, on Win 10, that should not be the case, because it's a recent OS and your machine is probably not very old with supported drivers. Did you check your drivers are up-to-date, especially after the Win 10 Anniversary update from August 2016?

Comment 12

[Loic]

Jonathan, any idea why the fonts are trashed with e10s on and HWA off when printing?

If e10s is disabled with HWA off, it works fine.

Comment 13

[Jonathan Kew [:jfkthame]]

With e10s enabled, printing involves sending everything from the content process over to the chrome process to be printed, AIUI. So maybe it's something like that the styled fonts are not being serialized and passed to the parent process properly when the GDI backend is in use, so then we end up rendering the glyph IDs from some other "random" fallback font.

ni'ing Lee, as I believe he's been involved in the e10s-print-via-parent stuff.

Comment 14

[Jonathan Kew [:jfkthame]]

Also, does this still occur with Firefox 52?

Comment 15

[work.alexkhv]

(In reply to Loic from comment #9)
> In addition, as workaround, could you change in about:config:
> browser.tabs.remote.autostart=false
> browser.tabs.remote.autostart.2=false
> (restart FF to apply)
Setting 'browser.tabs.remote.autostart.2' to 'false' helps: printing to PDF and printing on a real device work as expected. Thank you!


(In reply to Jonathan Kew (:jfkthame) from comment #14)
> Also, does this still occur with Firefox 52?
Without setting this flag to false it still occurs with Firefox 52.0.1 ESR and Windows Server® 2008 Standard (6.0.6002) SP2 x64bit.


(In reply to Loic from comment #8)
> Could you type about:support in the location bar and paste:
> 1) line "multiprocess windows"
> 2) the section "graphics"
As for information from 'about:support' section - my case may be irrelevant as I'm reproducing this on a virtual machine. I will provide more actual information if more users call our tech support about this problem.
This is my 'about:support' from a virtual machine:

1) Multiprocess Windows: 1/1 (Enabled by default)
2) Graphics:

Features:
+------------------------+---------------------------------------------------------------------+
| Compositing            | Basic                                                               |
+------------------------+---------------------------------------------------------------------+
| Asynchronous Pan/Zoom  | wheel input enabled; touch input enabled                            |
+------------------------+---------------------------------------------------------------------+
| WebGL Renderer         | Google Inc. -- ANGLE (Software Adapter Direct3D11 vs_4_1 ps_4_1)    |
+------------------------+---------------------------------------------------------------------+
| WebGL2 Renderer        | Google Inc. -- ANGLE (Software Adapter Direct3D11 vs_4_1 ps_4_1)    |
+------------------------+---------------------------------------------------------------------+
| Hardware H264 Decoding | No; Failed to create H264 decoder                                   |
+------------------------+---------------------------------------------------------------------+
| Audio Backend          | unknown                                                             |
+------------------------+---------------------------------------------------------------------+
| Direct2D               | Blocked for your graphics card because of unresolved driver issues. |
+------------------------+---------------------------------------------------------------------+
| DirectWrite            | false (7.0.6002.18392)                                              |
+------------------------+---------------------------------------------------------------------+


GPU #1 
+----------------+-----------------------------+
| Active         | Yes                         |
+----------------+-----------------------------+
| Description    | VirtualBox Graphics Adapter |
+----------------+-----------------------------+
| Vendor ID      | 0x80ee                      |
+----------------+-----------------------------+
| Device ID      | 0xbeef                      |
+----------------+-----------------------------+
| Driver Version | 4.1.2.0                     |
+----------------+-----------------------------+
| Drivers        | VBoxDisp                    |
+----------------+-----------------------------+
| Subsys ID      | 00000000                    |
+----------------+-----------------------------+
| RAM            | Unknown                     |
+----------------+-----------------------------+


Diagnostics:
+----------------------------+-------+
| AzureCanvasAccelerated     | 0     |
+----------------------------+-------+
| AzureCanvasBackend         | skia  |
+----------------------------+-------+
| AzureContentBackend        | skia  |
+----------------------------+-------+
| AzureFallbackCanvasBackend | cairo |
+----------------------------+-------+


Decision Log:
+-------------------+---------------------------------------------------------------------------+
| D3D11_COMPOSITING | Blocklisted; failure code BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR |
+-------------------+---------------------------------------------------------------------------+
|  D3D9_COMPOSITING | disabled by default: Disabled by default                                  |
+                   +---------------------------------------------------------------------------+
|                   | Blocklisted;failure code BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR  |
+-------------------+---------------------------------------------------------------------------+
|      DIRECT2D     | unavailable by default: Direct2D requires Direct3D 11 compositing         |
+-------------------+---------------------------------------------------------------------------+
|   D3D11_HW_ANGLE  | unavailable by default: D3D11 compositing is disabled                     |
+                   +---------------------------------------------------------------------------+
|                   | disabled by env: D3D11 compositing is disabled                            |
+-------------------+---------------------------------------------------------------------------+

Comment 16

[work.alexkhv]

Got a feedback from a user: the workaround comment #9 also worked for him.
Here's his graphics section's screenshot (if you have troubles understanding/translating Russian on this image, I can translate it for you):
1) https://yadi.sk/d/bR9kTO1d3GPN6d
2) https://yadi.sk/i/QN43Yv0V3GPPGD

His 'Multiprocess Windows' is '1/1 (Enabled by default)'.

Here's some info about user's environment:
OS: Windows 7 Pro (6.1.7601) SP1 64bit
Video adapter: Intel(R) HD Graphics 4600, driver version: 10.18.10.4338
He's got ESET Smart Security 9.0.408.1 installed.

The system looks pretty up-to-date:
1) last Windows updates installation was at 16.03.2017 09:27:21;
2) last search for Windows updates was at 24.03.2017 07:17:05.

Comment 17

[George Wright (:gw280) (needinfo me!)]

Potentially a dupe of bug 1318845

Comment 18

[Lee Salzman [:lsalzman]]

Does the problem still happen when using the nightly builds?

Comment 19

[Lee Salzman [:lsalzman]]

Not sure this is a dup of bug 1318845, since this is before the timeline of that and the user in question is bypassing all manner of HWA/compositing/etc.

The main theme here is GDI fonts in combination with print-via-parent. It looks like NativeFontResourceGDI does nothing to pass along the actual LOGFONT information, and NativeFontResourceGDI::CreateScaledFont just makes up a generic LOGFONT with only default styling information filled in. I don't know enough about how the serialization affects this, i.e. if the font file data is actually serializing multiple versions of the font or the styling was being handled instead by synthetic bold/italics which might be somehow not getting transmitted.

A comment in gfxGDIFontList.cpp (https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxGDIFontList.cpp#373) would seem to indicate that Windows may be doing fake italics based on information in the LOGFONT if there is no italic version of the font, therefor losing this information could contribute to the experienced symptoms. I would wonder the same with weight as well. So if this is the case, the InstanceData mechanism I added for ScaledFontFontconfig would need to be used similarly for ScaledFontWin to pass that information along and properly reconstruct it.

Comment 20

[work.alexkhv]

(In reply to Lee Salzman [:lsalzman] from comment #18)
> Does the problem still happen when using the nightly builds?

Well, I'm having troubles installing a nightly build on a virtual machine with Win 2008 as Mozilla dropped support for Win XP and Vista. (I also made a mistake in the initial message when I said "This bug can be reproduced in Windows Server 2008R2": I'm reproducing this on Windows Server 2008 Standard (6.0.6002) SP2, not R2).
Nevertheless, a considerable number of our users still use Win XP and Win 2008 - they won't be able to install FF > 52esr.

Searching for users who faced this problem with Win 7 (or greater) and temporary installing an unstable nightly build over VNC on their computers seems a bit overkill: very few users will agree to that due to different reasons. Instead:
1) I could gather more information about environments so you could reproduce this problem;
2) we could wait for the release of Firefox with a possible fix and then wait for feedback and see if the problem persists.

Comment 21

[Bob Owen (:bobowen)]

(In reply to Lee Salzman [:lsalzman] from comment #19)
> Not sure this is a dup of bug 1318845, since this is before the timeline of
> that and the user in question is bypassing all manner of HWA/compositing/etc.
> 
> The main theme here is GDI fonts in combination with print-via-parent. It
> looks like NativeFontResourceGDI does nothing to pass along the actual
> LOGFONT information, and NativeFontResourceGDI::CreateScaledFont just makes
> up a generic LOGFONT with only default styling information filled in. I
> don't know enough about how the serialization affects this, i.e. if the font
> file data is actually serializing multiple versions of the font or the
> styling was being handled instead by synthetic bold/italics which might be
> somehow not getting transmitted.
> 
> A comment in gfxGDIFontList.cpp
> (https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxGDIFontList.
> cpp#373) would seem to indicate that Windows may be doing fake italics based
> on information in the LOGFONT if there is no italic version of the font,
> therefor losing this information could contribute to the experienced
> symptoms. I would wonder the same with weight as well. So if this is the
> case, the InstanceData mechanism I added for ScaledFontFontconfig would need
> to be used similarly for ScaledFontWin to pass that information along and
> properly reconstruct it.

I suspect that this is because we are losing information in the same way that you discovered for Linux fonts and we'd need to serialise this extra information as well. I don't have time to look into this now, but if it hasn't been picked up by the time I do, then I will.

Comment 22

[Lee Salzman [:lsalzman]]

Attachment: make NativeFontResourceGDI send the LOGFONT as scaled font instance data

This just sends over the entire LOGFONT structure from the originating ScaledFont, since there are several fields of it that Windows may interpret to modify the resulting font. Also, I suspect that something may be going wrong with the font name/index matching, so that I just replaced all that junk with the name already embedded in the LOGFONT as a side-effect of this change.

An incidental finding I noticed while reviewing what I did for ScaledFontFontconfig was that it's implementation of GetFontDescriptor had a memory leak, so I did a tiny drive-by fix for that in here too.

When I get some try builds up, or if people are able to apply and build with this patch, it would be nice if we could get some people who are able to reproduce the issue to test it and verify if this fixes the problem.

Comment 23

[Lee Salzman [:lsalzman]]

Here is a try build with the fix included:

https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-d1bbf56dc023b375024717a10feb03b30ea06f15/try-win32/

Can anyone who can reproduce the issue:

1) verify that the issue is still present in nightly builds
2) verify that the try build I linked above fixes the issue

Comment 24

[Loic]

In fact, I should haved tested in Nightly because it appears the bug is already fixed in 53+. 
Fix range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a5e107a84c1832bcdb2bf91645454befb77c591b&tochange=dfbfb5347dbc42b632ff0681d292af12f9722e99

It has been fixed by:
George Wright — Bug 1318845 - Ensure we support DWrite fonts in the parent process when the GPU process is enabled r=Bas

So I don't know if your patch is still necessary but it's out of my scope. :)

Comment 25

[Jonathan Kew [:jfkthame]]

(In reply to Loic from comment #24)
> In fact, I should haved tested in Nightly because it appears the bug is
> already fixed in 53+. 
> Fix range:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=a5e107a84c1832bcdb2bf91645454befb77c591b&tochange=dfbf
> b5347dbc42b632ff0681d292af12f9722e99
> 
> It has been fixed by:
> George Wright — Bug 1318845 - Ensure we support DWrite fonts in the parent
> process when the GPU process is enabled r=Bas

This is a different fix, because your Nightly is using DWrite rather than GDI fonts; to test _this_ issue, you need a configuration that still uses GDI fonts. (Compare the config shown in comment 15, where DirectWrite=false.)

Comment 26

[Loic]

Is there a way to force the use of GDI instead of DW in about:config?
I tried gfx.font_rendering.cleartype_params.rendering_mode=2, the line DW is still at true after restart.

Comment 27

[Bob Owen (:bobowen)]

Comment on attachment 8852128 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data

Review of attachment 8852128 [details] [diff] [review]:
-----------------------------------------------------------------

This certainly simplifies things and should be much more reliable, thanks.

I now understand your fix for Linux better as well which is a bonus.
Do you think we're likely to need a similar one for Mac?

::: gfx/2d/NativeFontResourceGDI.cpp
@@ +41,5 @@
>  NativeFontResourceGDI::CreateScaledFont(uint32_t aIndex, Float aGlyphSize,
>                                          const uint8_t* aInstanceData, uint32_t aInstanceDataLength)
>  {
> +  if (aInstanceDataLength < sizeof(LOGFONT)) {
> +    gfxWarning() << "GDI scaled font instance data is truncated.":

nit: ; not : ... I assume you've already fixed this given the try push build.

@@ +46,5 @@
>      return nullptr;
>    }
>  
>    LOGFONT logFont;
> +  memcpy(&logFont, aInstanceData, sizeof(LOGFONT));

nit: given the comment below, do we need to copy this LOGFONT, could we not just cast?
I guess we'd have to cast away the const as well, although it looks like the constructor could probably take a const LOGFONT*.

::: gfx/2d/ScaledFontWin.cpp
@@ +53,5 @@
>    if (sizeGot != tableSize) {
>      return false;
>    }
>  
> +  aDataCallback(fontData.get(), tableSize, 0, mSize, 0, nullptr, aBaton);

I think this means that the index is now only used by DWrite.
I suppose in a follow-up, it could be removed from the data callback and thought of as the instance data for DWrite and returned by GetFontInstanceData on ScaledFontDWrite.

Comment 28

[Bob Owen (:bobowen)]

(In reply to Loic from comment #26)
> Is there a way to force the use of GDI instead of DW in about:config?
> I tried gfx.font_rendering.cleartype_params.rendering_mode=2, the line DW is
> still at true after restart.

"Use hardware acceleration when available" on the Advanced/General tab in about:preferences used to work for me.

This time I had to set the prefs gfx.content.azure.backends and gfx.canvas.azure.backends to just "cairo" as well.

Comment 29

[Loic]

Thanks, it did the trick.

I tested the build from comment #23 with these settings:
* e10s enabled
* HWA disabled in advanced options
* gfx.content.azure.backends=cairo
* gfx.canvas.azure.backends=cairo

Print output is fine, same as:
* e10s enabled + HWA disabled (but still using DWrite)
* e10s enabled + HWA enabled

Comment 30

[Lee Salzman [:lsalzman]]

(In reply to Loic from comment #29)
> Thanks, it did the trick.
> 
> I tested the build from comment #23 with these settings:
> * e10s enabled
> * HWA disabled in advanced options
> * gfx.content.azure.backends=cairo
> * gfx.canvas.azure.backends=cairo
> 
> Print output is fine, same as:
> * e10s enabled + HWA disabled (but still using DWrite)
> * e10s enabled + HWA enabled

Using just a normal nightly build, does the problem still occur without the patch? Just so we can verify the patch is actually the reason it is now fixed.

Comment 31

[Lee Salzman [:lsalzman]]

Attachment: make NativeFontResourceGDI send the LOGFONT as scaled font instance data. r=bobowen

Fixed nits.

Comment 32

[Lee Salzman [:lsalzman]]

Attachment: make NativeFontResourceGDI send the LOGFONT as scaled font instance data (52)

The instance data mechanism was introduced in 53. So to backport to 52, we need to introduce this mechanism as well. Thus, this patch combines a small portion of the original instance data patch with the LOGFONT patch here so that they can be then applied to 52 ESR.

Comment 33

[Loic]

Attachment: https_bug1343813.bmoattachments.org_attachment.cgi_id=8843595.pdf

(In reply to Lee Salzman [:lsalzman] from comment #30)
> (In reply to Loic from comment #29)
> > Thanks, it did the trick.
> > 
> > I tested the build from comment #23 with these settings:
> > * e10s enabled
> > * HWA disabled in advanced options
> > * gfx.content.azure.backends=cairo
> > * gfx.canvas.azure.backends=cairo
> > 
> > Print output is fine, same as:
> > * e10s enabled + HWA disabled (but still using DWrite)
> > * e10s enabled + HWA enabled
> 
> Using just a normal nightly build, does the problem still occur without the
> patch? Just so we can verify the patch is actually the reason it is now
> fixed.

Yes, with the current Nightly, e10s enabled, HWA disabled, and Cairo selected (to force GDI instead of DWrite), I get a broken print output (see the PDF attached).

Comment 34

[Lee Salzman [:lsalzman]]

(In reply to Loic from comment #33)
> Created attachment 8852685 [details]
> https_bug1343813.bmoattachments.org_attachment.cgi_id=8843595.pdf
> 
> (In reply to Lee Salzman [:lsalzman] from comment #30)
> > (In reply to Loic from comment #29)
> > > Thanks, it did the trick.
> > > 
> > > I tested the build from comment #23 with these settings:
> > > * e10s enabled
> > > * HWA disabled in advanced options
> > > * gfx.content.azure.backends=cairo
> > > * gfx.canvas.azure.backends=cairo
> > > 
> > > Print output is fine, same as:
> > > * e10s enabled + HWA disabled (but still using DWrite)
> > > * e10s enabled + HWA enabled
> > 
> > Using just a normal nightly build, does the problem still occur without the
> > patch? Just so we can verify the patch is actually the reason it is now
> > fixed.
> 
> Yes, with the current Nightly, e10s enabled, HWA disabled, and Cairo
> selected (to force GDI instead of DWrite), I get a broken print output (see
> the PDF attached).

Awesome, thanks!

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/09daa6aeb0a2
make NativeFontResourceGDI send the LOGFONT as scaled font instance data. r=bobowen

Comment 36

[Bob Owen (:bobowen)]

Comment on attachment 8852604 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data (52)

Review of attachment 8852604 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good to me.

I've also compared this with the landed patch, and the differences from that with the original instance data patch from bug 1309205 (ignoring the Fontconfig parts).

In addition I've built the latest Fx52 tree with this patch and printed the example from the bug, wikipedia.org (which has lots of fonts) and bostonglobe.com (which uses webfonts) with DWrite and GDI.

Comment 37

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/09daa6aeb0a2

Comment 38

[Lee Salzman [:lsalzman]]

Comment on attachment 8852561 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data. r=bobowen

Approval Request Comment
[Feature/Bug causing the regression]: bug 1156742
[User impact if declined]: Prints with incorrect fonts when using E10s with no HWA on Windows.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no 
[List of other uplifts needed for the feature/fix]: 
[Is the change risky?]: no
[Why is the change risky/not risky?]: Fix verified by user.
[String changes made/needed]: None

Comment 39

[Lee Salzman [:lsalzman]]

Comment on attachment 8852604 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data (52)

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Printing uses incorrect fonts when using E10s with HWA disabled on Windows.
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): Should not be risky as printing has been verified to work with this patch.  
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 40

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8852561 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data. r=bobowen

Too late for beta uplift, but let's try it on aurora 54.

Comment 41

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/443b578c9cba

Comment 42

[Lee Salzman [:lsalzman]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #40)
> Comment on attachment 8852561 [details] [diff] [review]
> make NativeFontResourceGDI send the LOGFONT as scaled font instance data.
> r=bobowen
> 
> Too late for beta uplift, but let's try it on aurora 54.

This definitely at least needs to get into 52 ESR, as this will impact a lot of legacy Windows users.

Comment 43

[Julien Cristau [:jcristau]]

(In reply to Lee Salzman [:lsalzman] from comment #42)
> (In reply to Liz Henry (:lizzard) (needinfo? me) from comment #40)
> > Comment on attachment 8852561 [details] [diff] [review]
> > make NativeFontResourceGDI send the LOGFONT as scaled font instance data.
> > r=bobowen
> > 
> > Too late for beta uplift, but let's try it on aurora 54.
> 
> This definitely at least needs to get into 52 ESR, as this will impact a lot
> of legacy Windows users.

We can probably take this for 52.2esr after it has been on beta54 for a bit.

Comment 44

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8852604 [details] [diff] [review]
make NativeFontResourceGDI send the LOGFONT as scaled font instance data (52)

Fixes a regression with printing on windows when HWA is off + e10s. Fix has stabilized on Nightly55 and Aurora/Beta54 for ~4 weeks. Let's uplift to ESR52.2

Comment 45

[Ryan VanderMeulen [:RyanVM]]

The attached patch for 52 doesn't apply to esr52 at all. Can you please post a revised patch?

Comment 46

[Lee Salzman [:lsalzman]]

This was successfully uplifted to the esr52 tree, just accidentally under the wrong bug number:

https://hg.mozilla.org/releases/mozilla-esr52/rev/90f870bbec29