In PDFs: characters are wrongly mapped when document uses a non-embedded font not present in the system
Categories
(Firefox :: PDF Viewer, defect, P3)
Tracking
()
People
(Reporter: seb, Assigned: jfkthame)
References
(Regression)
Details
(Keywords: regression)
Attachments
(11 files, 1 obsolete file)
23.85 KB,
application/pdf
|
Details | |
18.60 KB,
application/pdf
|
Details | |
199.10 KB,
image/png
|
Details | |
66.47 KB,
application/json
|
Details | |
168.29 KB,
text/plain
|
Details | |
625.20 KB,
image/png
|
Details | |
45.47 KB,
image/png
|
Details | |
44.07 KB,
application/octet-stream
|
Details | |
29.90 KB,
image/png
|
Details | |
81.18 KB,
image/png
|
Details | |
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
diannaS
:
approval-mozilla-esr115+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0
Steps to reproduce:
Drag the attached PDF into 117.0.1 Firefox to display with the internal PDF view.
Actual results:
All the text is completely garbled showing all non-ASCII characters.
If I set config browser.display.use_document_fonts=0 then it renders the text ok.
The same is seen with all PDFs from this same source.
The problem wasn't noticed with older versions of Firefox (it's only recently started).
Expected results:
Other PDF readers including Chrome browser all render the attached PDF just fine.
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 years ago
|
||
I tried to reproduce this issue on Firefox 117.0.1 (20230912013654) using Win 10, but with no success. The attached PDF file is displayed correctly with its content eligible. Are there any additional steps (settings) or something that I'm missing?
Thank you!
Comment 4•2 years ago
|
||
Since a "See Also" has been added, note that bug 1563678 is an opposite bug: rendering fails when browser.display.use_document_fonts=0.
BTW, under Linux, I cannot see any issue with the attached PDF file, whether browser.display.use_document_fonts is 1 or 0.
I have attached another PDF which also has the same problem, plus a screenshot of how it looks.
The 2 PDFs have different Application & PDF Product tags (i.e. they were produced by different software).
They also have different PDF Versions "1.4 (Acrobat 5.x)" vs "1.5 (Acrobat 6.x)"
What they have in common is they both use Helvetica font (with Ansi encoding) which is not present on my system. When I view in Acrobat, it substitutes "ArialMT" as the actual font and displays fine. In Firefox whatever the substitute font is, clearing the character codes are not mapped correctly.
Comment 8•2 years ago
|
||
Could you open the devtools (ctrl+shift+K) and copy-paste what you've in the console ?
Could you copy-paste your config from about:support
?
In the console:
Partitioned cookie or storage access was provided to “file:///C:/Users/seb/Desktop/DL/Proof%20of%20Delivery%20782253704390.pdf” because it is loaded in the third-party context and dynamic state partitioning is enabled.
Warning: Invalid absolute docBaseUrl: "file:///C:/Users/seb/Desktop/DL/Proof%20of%20Delivery%20782253704390.pdf". pdf.worker.js:973:13
PDF 55bc93cebc3f3f9306afdb503f711856 [1.5 iText 2.1.2 (by lowagie.com) / -] (PDF.js: 3.9.146 [48cc67f17]) viewer.js:1530:13
Reporter | ||
Comment 10•2 years ago
|
||
Reporter | ||
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
There is nothing strange here except font.internaluseonly.changed: true
but there's nothing on searchfox about this pref.
We're probably fallbacking on a font which is not what we expected.
Reporter | ||
Comment 13•2 years ago
|
||
Just to be sure, I tried it with font.internaluseonly.changed: false and with font.internaluseonly.changed deleted, and still the same.
browser.display.use_document_fonts=0 fixes the PDF, but then every web page has the wrong fonts.
If I use the Inspector to view the corrupt PDF, the texts are correct within the DOM HTML itself. Computed font-family shows as sans-serif. From the Fonts tab, the actual fonts used are Arial and Segoe UI (not sure how to tell where each one is used, but I guess for sans-serif family it will be Arial).
Reporter | ||
Comment 14•2 years ago
|
||
Actually, forget that last bit about the DOM HTML - I see now that the visibly document text is rendered in a canvas element.
Comment 15•2 years ago
|
||
The severity field is not set for this bug.
:calixte, could you have a look please?
For more information, please visit BugBot documentation.
Updated•2 years ago
|
Reporter | ||
Comment 16•2 years ago
|
||
I'm not very familiar with how the Severity levels are decided, but going by the descriptions here I would personally suggest it may be S2, since the workaround is not very satisfactory - setting config browser.display.use_document_fonts=0 changes the fonts on every website viewed, not just within PDF docs.
One further piece of information which may be helpful:
The problem has only started recently - I work with these PDFs all the time and didn't notice the problem before Firefox 117.
The problem also shows up in a web-app which uses pdf.js, and again only started with Firefox 117, even though the pdf.js version hadn't been updated recently.
So the problem seems to be related to something deeper in the Firefox architecture rather than being within pdf.js which I believe is used as the rendering engine.
Comment 17•2 years ago
•
|
||
I agree that the workaround isn't crazy but you just picked up a part of the full sentence:
(Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist
That said, S3 doesn't mean that we don't care about it but just that it isn't a priority for now.
And to be clear, maybe the bug is because of some changes in pdf.js/Firefox or some changes in pdf.js/Firefox highlight a problem with your own setup.
In considering, that I can't reproduce it myself and QA neither, I'm inclined to think that we're in the second case.
I'll try to figure out a way to know what's the font you're really using when the text is drawn on the canvas.
Could you try to use mozregression to figure out which patch has introduced this issue ?
Reporter | ||
Comment 18•2 years ago
|
||
Thanks for your reply and the clarification.
mozregression is a useful tool :)
I've also now discovered something else about the bug: it only occurs once Firefox has been launched for at least a minute or so. At first I ran through all builds in mozregression without seeing the problem. Then I tried a fresh profile of my installed Firefox and couldn't get the problem either. Then I went back to my normal profile and again couldn't see the problem.
It turns out that you have to wait approx 1 minute and a few seconds after launching firefox for the PDF to show corrupted. For the first minute it loads fine. It's not to do with the number of times the document is reloaded, or related to anything else running. It just needs approx 1 minute on my system before the bug appears. Is there some process where Firefox preloads and caches common system fonts perhaps?
Anyway now I know to wait 1min+ before testing, I was able to pinpoint the regression using mozregression ...
2023-10-04T20:13:20.892000: DEBUG : Found commit message:
Bug 1832514 - Update PDF.js to new version d520754bcf32990259503682956bc24399c6bc76 r=pdfjs-reviewers,marco
Differential Revision: https://phabricator.services.mozilla.com/D177736
Full log attached below.
Reporter | ||
Comment 19•2 years ago
|
||
Updated•2 years ago
|
Comment 20•2 years ago
|
||
I have the same issue, it started a few days ago.
I work with PDFs in Firefox almost daily, never seen this before.
My impression was that it started with one of the latest Firefox updates.
Current version: 118.0.2 (64-bit) on Windows 11.
See PDF test file and result in Firefox PDF viewer here: https://github.com/mozilla/pdf.js/issues/17109#issue-1937156297
Reporter | ||
Comment 21•2 years ago
|
||
Added a reference to Bug 1857015 which seems to be a duplicate of this one.
Comment 23•2 years ago
|
||
I added some code to help to debug this issue so in order to get some info, please follow this:
- download the very last firefox nightly (120 with buildid 20231011092203)
- in
about:config
, set the prefpdfjs.pdfBugEnabled
totrue
, - append
#pdfBug=all&textLayer=visible
to the pdf url and reload
Now you should see in green the text as it is on the canvas and in black the text as it is in the text layer.
Could you screenshot some green garbled text ?
Then right click on the green garbled text you chose previously, right click and Inspect
, devtools should open.
Then click on garbled text and in the pdf debugger (panel on the right) you should see a check mark close to the internal font name and the font we're trying to substitute (likely something like g_d0_sf6
for the internal name and Arial for the font name as it is in the pdf), click on log and then copy/paste the what you have in the console.
In the devtools you should have a panel called Fonts
(on the right on my screenshot) , and under g_d0_sf6
you should have the name of the font which is really used to render: could you share it here ?
Comment 24•2 years ago
|
||
OK, I can do that but will need some help:
- Where do I find "last firefox nightly (120 with buildid 20231011092203)", and install instructions?
- How do I insert screenshots from clipboard here? (First time I'm on Bugzilla)
Comment 25•2 years ago
|
||
OK, I found and installed last Firefox nightly.
No idea about build ID, this is what I find under Help / About Nightly:
120.0a1 (2023-10-11) (64-bit)
This file still renders incorrectly: https://s1.q4cdn.com/806093406/files/doc_downloads/test.pdf
- In about:config, I have set set the pref pdfjs.pdfBugEnabled to true
- Added #pdfBug=all&textLayer=visible to URL and reloaded. Text got green shadow.
- I have no idea how to paste a screenshot or a jpg/png file here, but it renders identical to what I showed here: https://github.com/mozilla/pdf.js/issues/17109
- I have opened devtools, but am unfamiliar with this tool.
- When I click on the first line (correctly rendered), the font inspector indicates : " g_d0_sf4 baseFontName Arial"
- When I click on the second line (incorrectly rendered), the font inspector indicates : " g_d0_sf6 baseFontName Arial"
- I clicked "Log" next to "g_d0_sf6", and get this in Console:
Object { css: "g_d0_sf6,sans-serif", guessFallback: false, loadedName: "g_d0_sf6", baseFontName: "Arial", src: "local(Arial),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)", style: {…} } - In the Fonts panel I opened "All fonts on page" and find g_d0_sf6 at the bottom. The other fonts have a font name (e.g. g_d0_sf4: Arial Bold), and they are fine in the preview. On g_d0_sf6 it says instead: Z@RD450.tmp and the preview is garbled.
Hope this helps!
Reporter | ||
Comment 26•2 years ago
|
||
Sadly (or happily for me personally), I'm no longer able to reproduce the bug. Not with my current install (118.0.2) nor with the debug nightly build.
PDFs were broken yesterday but today no more. The only thing which changed on my system were some Windows updates.
Comment 27•2 years ago
|
||
This Z@RD450.tmp
doesn't look nice.
Since the font isn't in the pdf we're trying to fallback on one of the font in this list:
local(Arial),local(Helvetica),local(Helvetica Neue),local(Arial),local(Arial Nova),local(Liberation Sans),local(Arimo),local(Nimbus Sans),local(Nimbus Sans L),local(A030),local(TeX Gyre Heros),local(FreeSans),local(DejaVu Sans),local(Albany),local(Bitstream Vera Sans),local(Arial Unicode MS),local(Microsoft Sans Serif),local(Apple Symbols),local(Cantarell),url(resource://pdf.js/web/standard_fonts/LiberationSans-Regular.ttf)
According to:
https://community.adobe.com/t5/acrobat-reader-discussions/z-xxx-tmp-files-in-user-temp-folder-causes-gibberish-font-in-printout/td-p/9883829?profile.language=de
this font could be a leftover from Acrobat (the thread is a bit old so I don't know if it's still relevant).
:jfkthame, do you know if it's possible to avoid to load such a font ?
Comment 28•2 years ago
|
||
Maybe relevant or of some help:
https://community.adobe.com/t5/acrobat-discussions/z-r-tmp-font-is-displaying-when-opening-a-pdf-from-outlook/td-p/9007400
Comment 29•2 years ago
|
||
I forgot to needinfo Jonathan (https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c27).
Assignee | ||
Comment 30•2 years ago
|
||
I'm not sure what we can do about this...
As far as I can tell from reading the Adobe-community discussions, what I think is happening is that in some cases, Acrobat creates a "temporary" font file (as part of its printing process?) containing a font that is presumably a (subset, re-encoded) version of Helvetica or Arial, and makes it known to Windows (presumably so that the printer driver etc can use it). But they're doing this in such a way that it also appears in the system font collection that we get from the Windows (DirectWrite) APIs. So then, when we ask for Helvetica (or Arial, or whatever), we get this garbled font.
That's bad enough, because it would mean there's a risk of getting a garbled font if an application tries to use it while an Acrobat print job is happening; but worse, it also sounds like they sometimes fail to delete it when they're done. In which case the problem would be persistent.
Seb or egil.opsahl, can either of you check if there's a file named Z@RD450.tmp
(or some similar naming -- it's probably a "unique" name generated on the fly, so the exact characters may vary) in your temp folder (probably at C:\Users\<user>\AppData\Local\Temp, I guess)? If so, I would be interested to see a copy. Maybe there's some way we can identify and block such fonts, even though Acrobat has made them "available".
Reporter | ||
Comment 31•2 years ago
|
||
I can't find any file named like this, but then the problem has now stopped on my system (seemingly since some Windows Updates installed today).
What I did notice before when I opened this test pdf in Adobe Acrobat Pro was that the font of the 2nd line (the one showing garbled in Firefox) was showing up in the font drop-down as something like Z@.... (when I went to edit the text).
Now that the problem has stopped on my system, when I go to edit this text in Adobe Acrobat Pro the font just shows as Arial.
Assignee | ||
Comment 32•2 years ago
|
||
I'm guessing that the Windows update process (or the reboot that it presumably forced) may have cleared out lingering temporary files. If the problem ever comes back for you, let's take another look.
Maybe egil.opsahl will have something we can examine....
Comment 33•2 years ago
|
||
- I find a large number of Z@Rxxxx.tmp files in my c:\Users\<myself>\AppData\Local\Temp folder.
- All files are timestamped in quite narrow time windows, on dates ranging from 18th Sep to 11th Oct (yesterday morning)
- I generate PDF files from Office 365 applications, that has lately been Word and Powerpoint. I then generate PDFs using "File / Save as"
- It very seldomly generate PDF files using Acrobat, I am 100% sure I did not do so yesterday.
- So if Acrobat generated those files, it must have done so while opening PDF files.
- I have opened PDF files in Acrobat today, and there are no Z@Rxxxx.tmp files timestamped today.
- So maybe it is not Acrobat that generates the files.
- There are ten (10) files with identical timestamp yesterday morning, the time coincides with the time period where I raised the issue first on Github.
- I did not generate any PDF file yesterday morning.
- This is one of those files timestamped yesterday morning (Z@RF2FE.tmp) : https://drive.google.com/file/d/1WqEBLoICOwiyB1AGvuuNUr8YxDHlkK_s/view?usp=drive_link
- This is Z@RD450.tmp, which is in the same folder (timestamped 22nd Sep): https://drive.google.com/file/d/17mSlKbWFUCYDxCQIubWyGnypN911koYm/view?usp=drive_link
Comment 34•2 years ago
|
||
:egil.opshal, could you attach a font to this bug (there is a button Attach New File
in the Attachments
section on the top of this page) ?
Comment 36•2 years ago
|
||
Did anyone get a chance to consider my input here?
Assignee | ||
Comment 37•2 years ago
|
||
I looked at the attached file, and confirmed that it is a TrueType font resource; looking into the name
table (which provides the font's identification -- filenames are arbitrary, and renaming a file does not by itself affect the name of the font within it), we find:
<name>
<namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
Z@RD450.tmp
</namerecord>
<namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
Regular
</namerecord>
<namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
This is a unique ID
</namerecord>
<namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
Z@RD450.tmp
</namerecord>
<namerecord nameID="5" platformID="1" platEncID="0" langID="0x0" unicode="True">
1.0
</namerecord>
<namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
Arial
</namerecord>
<namerecord nameID="1" platformID="3" platEncID="0" langID="0x409">
Z@RD450.tmp
</namerecord>
<namerecord nameID="2" platformID="3" platEncID="0" langID="0x409">
Regular
</namerecord>
<namerecord nameID="3" platformID="3" platEncID="0" langID="0x409">
This is a unique ID
</namerecord>
<namerecord nameID="4" platformID="3" platEncID="0" langID="0x409">
Z@RD450.tmp
</namerecord>
<namerecord nameID="5" platformID="3" platEncID="0" langID="0x409">
1.0
</namerecord>
<namerecord nameID="6" platformID="3" platEncID="0" langID="0x409">
Arial
</namerecord>
</name>
Notice the name ID 6 here, which is the font's "PostScript name". It's "Arial". But this is not in fact a standard Arial font; it has been subsetted (probably) and re-encoded (certainly) such that the "character" repertoire it supports is completely non-standard.
What I am assuming has happened is that as part of Acrobat's printing process -- maybe related to a particular printer driver, even -- any embedded font resources in the PDF file are extracted into "temporary" files like this, and added to the current system font collection. I expect it does this so that the printer driver software -- as opposed to the Acrobat application itself which opened the PDF -- can use the font when printing.
But because the font's PostScript name -- which is supposed to be unique to the font resource -- is "Arial", when pdf.js uses a FontFace with src: local("Arial")
to try and access the system's Arial font, it may get this re-encoded version instead of the standard one, because it has the same PS name. And that results in totally garbled display, because the encoding of this font doesn't match what the document assumes.
Given that Acrobat has given this font a random family name that ends with ".tmp" (and presumably that's the pattern it always uses), maybe we can use this as a clue to ignore any such fonts when looking up what's available on the system. It'd be a rather arbitrary heuristic, but perhaps usable as a workaround.
Comment 38•2 years ago
|
||
When several fonts have the same unique name, is it possible to set a precedence based on the directory they're found ?
For example, an Arial in \Windows\Fonts
could have the precedence on one in \Users\Foo\AppData\Local\Temp
folder.
Or maybe a .ttf
, .otf
, ... could have the precedence on a .tmp
, wdyt ?
Comment 39•2 years ago
|
||
Maybe I misunderstand the explanations, but I fail to understand how Acrobat can be blamed.
Example:
My online accounting system generates PDF previews of invoices, where the word "DRAFT" (in Norwegian) is added as a large "watermark". When I preview this in Firefox, that word is garbled (and this started last week, I never had the issue before). I preview it with the Firefox built-in PDF viewer.
If I open the accounting system in Chrome, and do the same preview (with Chrome built-in PDF viewer), it renders correctly.
So for me the issue seems to be in the Firefox built-in PDF viewer, which (as far as I understand) has nothing to do with Acrobat?
Comment 40•2 years ago
|
||
:egil.opsahl, the Arial font in your pdf is not embedded hence we try to fallback on a font you've on your system. Every pdf render has a different strategy to choose the fallback font, it's why the rendering can be different from Chrome.
So a software (very likely Acrobat but it can be another one) has generated for whatever reason this font called Z@...
and your system recognizes it like a "true" Arial because of what Jonathan mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c37.
So the problem isn't because of Firefox here (even if we can maybe try to workaround it) but because of an other software which is generating these fake Arial fonts and for any reasons isn't able to remove them after they've been used and because your pdf doesn't embed all its fonts.
Comment 41•2 years ago
|
||
Comment 42•2 years ago
|
||
:calixte
Thank you for your additional information and explanation.
So I did the following:
- Closed all instances of Adobe Acrobat
- Deleted all Z@Rxxxx.tmp files in my c:\Users\<myself>\AppData\Local\Temp folder
Result:
- The test file https://s1.q4cdn.com/806093406/files/doc_downloads/test.pdf now renders correctly
- Invoices from FedEx (like the one :Seb posted earlier in this thread) now shows no text in the sections that were previously garbled. Just blank spaces.
Comment 43•2 years ago
|
||
This it how it should look.
Comment 44•2 years ago
|
||
Could you follow the steps described in https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c23 and tell us what you have ?
Comment 45•2 years ago
|
||
I believe I already did that, see https://bugzilla.mozilla.org/show_bug.cgi?id=1854090#c25
Comment 46•2 years ago
|
||
Yes I know, but you said
Invoices from FedEx (like the one :Seb posted earlier in this thread) now shows no text in the sections that were previously garbled. Just blank spaces.
and consequently, I'd like to understand why you have no text when you should have one, or maybe I misunderstood something.
Comment 47•2 years ago
|
||
OK - sorry. I understand you want me to repeat that process with one of the documents that are rendered with blanked-out text.
So...
- I opened the document in Firefox Nightly: It rendered correctly (!)
- I checked again the preview in Firefox: Still blank spaces on that one out of of 3 such documents.
- I opened a new instance of Firefox and opened the problematic document: It rendered correctly (!)
So it seems like deletion of the *.tmp files fixed the issue for me - but I was unable to see it because I kept trying in an instance of Firefox that has been open for a week or two. Starting a new instance of Firefox apparently did the trick.
-> Case closed maybe?
Reporter | ||
Comment 48•2 years ago
|
||
Note that on my system I found that Firefox had to be running for at least a minute or so before the problem would happen. Seems it takes this long to scan the fonts and cache them. The exact time probably varies from system to system, so try leaving Firefox running for a while to give it a change to scan and cache the 'bad' font.
Comment 49•2 years ago
|
||
And maybe run Acrobat in the mean time - if it is to blame for generating those *.tmp files?
Still looks OK here now, after i deleted the files last week - and Firefox has been running since then.
Assignee | ||
Comment 50•2 years ago
|
||
(In reply to Calixte Denizet (:calixte) from comment #38)
When several fonts have the same unique name, is it possible to set a precedence based on the directory they're found ?
For example, an Arial in\Windows\Fonts
could have the precedence on one in\Users\Foo\AppData\Local\Temp
folder.
Or maybe a.ttf
,.otf
, ... could have the precedence on a.tmp
, wdyt ?
I'm not sure offhand whether we can do this.... note that we don't locate fonts by searching the filesystem for them, so we don't necessarily know where the file was located or what its filename is. We query Windows using the DirectWrite GetSystemFontCollection
API, and use whatever it gives us.
As far as I can tell, the only way a font from Users\...\AppData\Local\Temp
with a *.tmp
filename could end up being used by Firefox -- as we'll never go looking in that directory ourselves -- is that it must have been registed "globally" as part of the system font collection, by whatever software created that "temporary" file. (Which I'm assuming was Acrobat, probably during a printing operation -- not necessarily when the file is simply opened/viewed -- but perhaps it's not Acrobat but some other PDF-related software that's doing this.)
So I think the "culprit" here is whatever software -- Acrobat or other -- is creating those temporary fonts and registering them with the system, and then failing to clean up. That's "polluting" the system font collection, and because the FontFace src: local(...)
lookup method looks at the font's PostScript name (as required by the CSS Fonts spec), not at the family name (ID 1, which they did at least have the sense to change to a "temporary" name), it results in the wrong resource being used.
I'll see if I can come up with a mitigation we can use in Firefox, but I do think the real flaw is whatever software is inserting these mangled fonts into the system. It's essentially corrupting the system's installed font collection.
Comment 51•2 years ago
|
||
:jfkthame
Thank you for your thorough explanation, which sounds very reasonable.
However, I still note that the native PDF readers used in Chrome and Edge gets around the issue - so I assume it should be in the interest of Firefox to also get around it.
Anyway - I now know what to do if the issue arises again: Delete the *.tmp files in Users...\AppData\Local\Temp.
So I know how to live with this issue.
Assignee | ||
Comment 52•2 years ago
|
||
This is a sad hack, but aims to work around the issue that some
PDF-related software (Acrobat is suspected but not currently confirmed)
is potentially polluting the global font collection with re-encoded
subsets of standard fonts like Arial, but does not munge the psname;
these can then be returned by src:local(...) lookups, which results in
garbled or missing text.
In principle, if such fonts are "installed", Firefox is not wrong to use
them; it's just a badly-configured system. But given that it seems to be
caused by some PDF-handling software, without the user's knowledge, it
seems worth trying to avoid the problem. Simply skipping the psname of
any font with family-name *.tmp is highly unlikely to adversely affect
any real-world content.
Updated•2 years ago
|
Comment 53•2 years ago
|
||
Would it be possible to use them only if there is no alternative in the system?
Assignee | ||
Comment 54•2 years ago
|
||
Not easily, as things stand. If I'm reading the pdf.js code correctly, the "problematic" name ends up as just one of a list of things it'll try, via the standard CSS font-matching code. To then go back and reconsider a particular src:local(...) face if nothing else works out would be a pretty disruptive intervention there.
In any case, the pdf.js code looks like it would end up trying a generic like sans-serif
as a last resort, which is a better bet than some random temporary subset of a standard font. At least the default fallback will have reasonable character encoding, unlike extracted subsets like this.
Assignee | ||
Comment 55•2 years ago
|
||
Note that in the reporter's case, it looks like the bad font(s) don't even necessarily have any connection with the PDF we're trying to render; they're random resources that some other software has left lying around, and probably came from other, unrelated PDFs. The only reasonable use-case for such resources is to render the exact PDF in which they were embedded. Arbitrarily accessing them as "Arial" or "Times-Roman" or whatever and using them to render other documents is never going to end well.
Comment 56•2 years ago
|
||
Comment 57•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Comment 58•2 years ago
|
||
The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox120
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 59•2 years ago
|
||
Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout
Beta/Release Uplift Approval Request
- User impact if declined: Possibly-broken text display in some PDFs on Windows, due to bad fonts installed by 3rd-party software
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce: (Unclear exactly what 3rd-party software/steps are involved in triggering the issue on a given system.)
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Narrowly targeted fix to just skip font names matching a known "temporary-file" pattern
- String changes made/needed:
- Is Android affected?: No
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Low-risk workaround for a failure mode that could make some PDFs unusable
- User impact if declined: Possibly-broken text display in some PDFs on Windows, due to bad fonts installed by 3rd-party software
- Fix Landed on Version: 121
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
Comment 60•2 years ago
|
||
Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout
Approved for 120.0b5
Comment 61•2 years ago
|
||
uplift |
Updated•2 years ago
|
Comment 62•2 years ago
|
||
Comment on attachment 9359789 [details]
Bug 1854090 - Omit psnames of fonts with family-name *.tmp from src:local() lookups on Windows. r=#layout
Approved for 115.5esr
Comment 63•2 years ago
|
||
uplift |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 64•2 years ago
|
||
Unfortunately I couldn't manage to reproduce the issue on my end, It's hard to find which 3rd-party software or steps are involved since we didn't have any lead from where to start.
Seb, Could you please verify if the issue is fixed on your end?
Thanks.
Reporter | ||
Comment 65•2 years ago
|
||
I am not seeing the problem at the moment, although it is intermittent so hard to be 100% sure. I will report back if I come across the problem again.
Reporter | ||
Comment 67•2 years ago
|
||
I'm working with release 119 at the moment, which I see from the tracking flags doesn't have the fix.
But I'm not seeing the problem since I ran a Windows update and restarted, which presumably cleaned out the temp font files which had been causing the problem.
Unfortunately I've been unable to repeat whatever created the bad font files. If I do manage to see the problem again in release 119, I'll try release 120 or 121 to check if the fix has worked.
Sorry not to be able to verify properly!
Comment 68•2 years ago
|
||
Could you please help us with another verification on Firefox Beta in order to change the status of this bug if it's not reproducible anymore?
You can download the latest version of Firefox Beta from here: https://www.mozilla.org/en-US/firefox/channel/desktop/
Thanks.
Reporter | ||
Comment 69•2 years ago
|
||
I'm not sure how I can help with this. As I said, I can't currently reproduce the bug even with the versions of Firefox which have not been fixed. Presumably because the problematic temp font files have now been automatically removed from my system.
And since I don't know how (or by which 3rd part app) the bad font files were created in the first place, I'm unable to recreate the circumstances where the bug appears.
As per your request,. I have now tried release 120 and the bug is also not showing up with this. But it doesn't really confirm the fix, since I couldn't reproduce the bug any more with 119 either.
Comment 70•2 years ago
|
||
Adding the Qa-not-actionable tag since this issue can't be reproduced on our side in order to be verified and the reporter can't confirm the fix also.
Updated•2 years ago
|
Description
•