User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce: We have a web based application that displays a Crystal Report. The rendering of the reports are done with the Crystal Reports Library and we have no programmatic control over the rendering. Since the newer update (54) the font no longer displays in the report within Firefox, however it displays within every other browser. We can simulate this in other browsers by removing the font from our computer. The theory is that Firefox is not "seeing" that font on the operating system to render it within the report. I have tried turning on safe mode, resetting firefox and turning off directdraw. Other users within our environment is seeing this issue. We have another machine running FF v 20 that is working fine. Copperplate Gothic Light is a TrueType font and we are using the latest version 1.5.1 Actual results: Firefox is replacing the Copperplate Gothic Light within the report with Calibri font Expected results: Firefox should display Copperplate Gothic light.
To clarify when I meant "other browsers" I meant Internet Explorer, Chrome, Edge. To further clarify, this issue is happening with everyone who has the newest version of FireFox.
Presumably the report is using CSS of the form font-family: Copperplate Gothic Light; which works with the GDI font back-end but fails with DirectWrite, where the Light face will be considered part of the "Copperplate Gothic" family. So changing the CSS to something like font-family: Copperplate Gothic; font-weight: 300; would probably fix this. Or for a version that works in both legacy (GDI) and modern (DirectWrite) environments, specify font-family: Copperplate Gothic Light, Copperplate Gothic; font-weight: 300; (See further discussion in bug 835204; this is almost certainly an example of the same issue.)
Is this a recent regression? How was Firefox 53? If so, I'll post a site compatibility note for this.
(In reply to Kohei Yoshino [:kohei] from comment #3) > Is this a recent regression? How was Firefox 53? If so, I'll post a site > compatibility note for this. We are unsure about when this started however we know for sure it's not in FF v20 as we can't see this appearing in that older machine I mentioned. Is there a way I can "revert back" to older versions of FF until I see the problem "go away". We believe that the problem didn't exist in version 48 because our "tester" here didn't see the problem until he updated his machine to 54....
I think the patch recently landed in bug 835204 may have fixed this. Can you try the latest Nightly version (https://nightly.mozilla.org/) and see whether this solves your issue?
Better still, try the 2017-09-11 Nightly once it is available (in a few hours), as it will include the fix for some crashiness introduced by that earlier patch (sorry!).