1105807 - Some parts of text are not rendered on various websites

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Loic]

Someone reported on the French board an issue about text (not all the text, only some parts) not rendered on various websites.
http://forums.mozfr.org/viewtopic.php?f=5&t=121343

STR:
1) Open http://www.journal-officiel.gouv.fr/frameset.html
2) Click on the "OK" button under the line "Aujourd'hui" to see the daily Official Journal (laws, decrees, etc).

Result: some text is missing.

He used mozregression:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=48eee276b1ee&tochange=86aa28ce309e

I guess bug 985220 is suspected.

Comment 1

[Loic]

Attachment: JOavecExplorer.JPG

Comment 2

[Loic]

Attachment: JOavecFirefox.JPG

Comment 3

[Loic]

Jonathan, do you need more info like graphics from about:support?

Comment 4

[Jonathan Kew [:jfkthame]]

It looks like the sans-serif text is fine, but the serif content is failing. My guess is that the user has an unusual version of Times New Roman installed, perhaps a non-TrueType font (legacy .pfb fonts, maybe), and that's failing to render for some reason. John, do you have the resources to try and reproduce this and confirm whether it's something like that?

Loic, can you get the user to try choosing a different default serif font in Options/Content (e.g. Cambria)? If that makes the missing text appear, it will support the theory that they may have a weird Times font installed.

Comment 5

[John Daggett (:jtd)]

(In reply to Loic from comment #0)
> Someone reported on the French board an issue about text (not all the text,
> only some parts) not rendered on various websites.
> http://forums.mozfr.org/viewtopic.php?f=5&t=121343
> 
> STR:
> 1) Open http://www.journal-officiel.gouv.fr/frameset.html
> 2) Click on the "OK" button under the line "Aujourd'hui" to see the daily
> Official Journal (laws, decrees, etc).
> 
> Result: some text is missing.
> 
> He used mozregression:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=48eee276b1ee&tochange=86aa28ce309e
> 
> I guess bug 985220 is suspected.

So you can reproduce this? It would be helpful to know which platform this is on and to get a copy of the about:support page.

Comment 6

[Bertrand]

Hello

I'm the aforementionned user.

Here is the content of the "accélération graphique" part of about:support.

Date du pilote	2-20-2010
Description de la carte	Intel(R) HD Graphics
Direct2D activé	Bloqué pour la version de votre pilote graphique.
DirectWrite activé	false (6.2.9200.16492)
Fenêtres avec accélération graphique	2/2 Direct3D 9
GPU #2 active	false
ID du périphérique	0x0046
ID du vendeur	0x8086
Pilotes de la carte	igdumd64 igd10umd64 igdumdx32 igd10umd32
RAM de la carte	Unknown
Rendu WebGL	Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote	8.15.10.2086
windowLayerManagerRemote	false
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Thanks!

Comment 7

[Loic]

Attachment: times_new_roman.zip

Fonts used by the OP.

Comment 8

[Loic]

Changing font to Cambria works.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Loic from comment #7)
> Created attachment 8530466 [details]
> times_new_roman.zip
> 
> Fonts used by the OP.

My suspicion is that it's the presence of the (ancient) PS Type 1 copy of Times:
  TNRB___.PFB
  TNRB___.PFM
that is causing the problem.

I thought we had code that could handle these legacy fonts, but perhaps it's broken. We should investigate this, but meanwhile the simple "fix" is to remove those fonts (and while you're there, might as well remove the duplicate (2) copies of the .ttf files, too). I'm fairly confident that will solve the problem.

Comment 10

[Loic]

The reporter fixed the issue by removing the unusual fonts, and now, Times New Roman works as expected.
Could we close this bug?

Comment 11

[Jonathan Kew [:jfkthame]]

I don't think we should simply close this; it's a real bug, as the presence of legacy PS Type 1 fonts on the user's system should not be able to make text simply disappear. We should fix or work around this in the Windows font backend, if possible.

Comment 12

[Loic]

The user has now the same issue with another website:
https://www.macsf.fr/vous-informer/vie-professionnelle-carriere-sante/sortie-de-la-vie-professionnelle-sante/medecin-liberal-cumul-emploi-retraite.html
Text titles is visible but not the text for the message.

Comment 13

[Jonathan Kew [:jfkthame]]

The CSS on that site includes things like

  font-family:"Lucida Grande",Lucida,sans-serif;

so if the user has a legacy Type 1 version of Lucida installed, for example, I'd imagine this could happen.

Comment 14

[Jonathan Kew [:jfkthame]]

Does it make any difference to disable hardware acceleration (in Options/Advanced/General) and restart the browser?

How about running in Safe Mode?

Comment 15

[Bertrand]

I just tried both, doesn't change anything.

I checked, my "Lucida" font is Type 1.

Comment 16

[Jonathan Kew [:jfkthame]]

Attachment: Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts

The problem here seems to be that ScriptGetCMap fails with legacy Type1 (.pfb) fonts. So in that case, let's fall back to the old GetGlyphIndicesW approach. This makes such fonts work again in my (limited) testing. Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=348516fe8243.

Comment 17

[John Daggett (:jtd)]

Comment on attachment 8645376 [details] [diff] [review]
Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts

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

Looks good.

Comment 18

[Jonathan Kew [:jfkthame]]

url:        https://hg.mozilla.org/integration/mozilla-inbound/rev/97c817a6f1ae725fd2216e0fed0e556dd04c2e34
changeset:  97c817a6f1ae725fd2216e0fed0e556dd04c2e34
user:       Jonathan Kew <[e-mail]>
date:       Mon Aug 10 09:39:49 2015 +0100
description:
Bug 1105807 - Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts. r=jdaggett

Comment 19

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/97c817a6f1ae

Comment 20

[Kent James (:rkent)]

This bug has more impact in emails, as people may have years-old emails stored that use these fonts. I'm tempted to land it for the next Thunderbird esr38 release (in our mozilla-esr38 branch). Any words of wisdom from graphics folks about possible risks of that?

Comment 21

[Jonathan Kew [:jfkthame]]

Pretty minimal, IMO. It's a very localized patch just using a fallback API in the case where we currently fail to render the text at all; no other platform, and no case that currently works, should be affected at all.

Comment 22

[Jonathan Kew [:jfkthame]]

Comment on attachment 8645376 [details] [diff] [review]
Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts

Approval Request Comment
[Feature/regressing bug #]: Regressed by bug 985220 (in mozilla-33). I suspect the number of users affected is quite small, but given that the impact for those users is severe and that the patch looks extremely localized/safe, I think we should consider uplifting to get this out to the affected users ASAP.

[User impact if declined]: Possibility of text being invisible for users with old Type 1 fonts installed, and with Windows systems using GDI (primarily WinXP, also newer systems with blocked h/w acc).

[Describe test coverage new/current, TreeHerder]: Tested manually; no TH coverage because this only affects users with legacy fonts (in Adobe Type1 format) that are not shipped as standard or present on unit-test systems. (Existing tests running on WinXP and unaccelerated Win7 serve to confirm the patch doesn't break current behavior for unaffected users.)

[Risks and why]: Minimal risk: local to the GDI fonts backend, only changes behavior in the case where we're currently failing to render text. No other platform and no currently-working system/font should be affected.

[String/UUID change made/needed]: n/a

Comment 23

[Kent James (:rkent)]

I'll land this for TB 38.2.0 in our branch if it does not get uplifted to mozilla-esr38 before then.

Comment 24

[Kent James (:rkent)]

https://hg.mozilla.org/releases/mozilla-esr38/rev/5f77862a6e66 THUNDERBIRD_38_VERBRANCH

Comment 25

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

Hello folks, can someone please verify that this issue is fixed on the latest Nightly? That would give me lot more confidence when approving for uplift to Beta. Thanks!

Comment 26

[Loic]

I just reported this bug, the affected user has aready the NI flag.

Comment 27

[Jonathan Kew [:jfkthame]]

(In reply to Ritu Kothari (:ritu) from comment #25)
> Hello folks, can someone please verify that this issue is fixed on the
> latest Nightly? That would give me lot more confidence when approving for
> uplift to Beta. Thanks!

AFAICT this is fixed. I installed a Type 1 (.pfb) font in a Windows VM, and confirmed that content styled with that font failed to render in Nightly prior to this patch; and with latest Nightly, it displays fine.

Comment 28

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

Since this was verified on latest Nightly, setting status-firefox43 to "verified".

Comment 29

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

Comment on attachment 8645376 [details] [diff] [review]
Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts

Given that the fix was verified on the latest Nightly, let's uplift to Aurora and Beta.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/22ca2af337eb

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/8bd25ca5e358

Comment 32

[Jerry]

Thank you all!!

Comment 33

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

Comment on attachment 8645376 [details] [diff] [review]
Fall back to GetGlyphIndicesW in gfxGDIFont::GetGlyph if ScriptGetCMap fails, for legacy Type1 fonts

OK. Approved for uplift to ESR38 so that we are nice to ESR users who want to see the laws of France.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/c7d1e15360a4