Closed Bug 1896915 Opened 9 months ago Closed 9 months ago

Character "S" not rendering properly on printed statements from firstcomcu.org

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Version:
Firefox 125
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
127 Branch
Tracking Flags:
Tracking Status
firefox127 --- verified

People

(Reporter: whs1993, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Firefox Bug.png
30.63 KB, image/png
Details
example of the pdf-viewer tools menu
57.60 KB, image/png
Details
Attached image Firefox Bug.png —

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

Logged into my bank website to look at statement. Everything appears normal. If I print the file or save it to a PDF, the "S" character does not print.

Actual results:

The "S" character does not print or display properly in the PDF.

Expected results:

If I use Safari or Google browsers, the problem does not occur.

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Printing: Output
Product: Firefox → Core

Does print preview show the issue?

Flags: needinfo?(whs1993)

Thanks for the bug report!

A few more questions on top of Emilio's question:

  • What's the website for the bank, if you don't mind sharing that?
  • Do you know if this worked in earlier versions of Firefox?
  • Is there a publicly-available page on the bank's website that reproduces the same issue? (If so that's awesome, but I'm guessing probably not.)
  • On an affected page, could you check what font Firefox is using to render the text? See bug 1850830 comment 2 for steps to do that using Firefox's developer tools (labeled (1)-(4) in that bug comment)
  • Could you try saving a local copy of an affected page (File | Safe As, and choose "Web Page, complete" at the bottom), and then open the resulting saved HTML file, and see if that reproduces the issue for you? (If the saved copy does reproduce the issue for you, then that's potentially a starting point to getting a standalone testcase that you could then privately share with us, so that we can try to reproduce and investigate the problem. )

Thanks!

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Does print preview show the issue?

No.

Flags: needinfo?(whs1993)

(In reply to Bill Stephens from comment #4)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Does print preview show the issue?

No.

(In reply to Daniel Holbert [:dholbert] from comment #3)

Thanks for the bug report!

A few more questions on top of Emilio's question:

  • What's the website for the bank, if you don't mind sharing that?
    https://www.firstcomcu.org/
  • Do you know if this worked in earlier versions of Firefox?
    No, because I've been using Firefox for years, but changed banks at the beginning of this year, and that's when I noticed the problem.
  • Is there a publicly-available page on the bank's website that reproduces the same issue? (If so that's awesome, but I'm guessing probably not.)
    Not that I can see.
  • On an affected page, could you check what font Firefox is using to render the text? See bug 1850830 comment 2 for steps to do that using Firefox's developer tools (labeled (1)-(4) in that bug comment)
    Under "All fonts on page", it lists two: ".SF NS System Font" and "Times Roman". I believe the font where the issue is occurring is probably in ".SF NS", because it is a serifless font, unlike Times Roman.
  • Could you try saving a local copy of an affected page (File | Safe As, and choose "Web Page, complete" at the bottom), and then open the resulting saved HTML file, and see if that reproduces the issue for you? (If the saved copy does reproduce the issue for you, then that's potentially a starting point to getting a standalone testcase that you could then privately share with us, so that we can try to reproduce and investigate the problem. )
    Unfortunately, no. I'm running macOS Catalina, and there is no option (such as you describe) to save the page in any format except PDF. I tried changing the extension to "html" and changing the "file format" from "PDF" to "All files", and this produced a raw dump of the PDF file. Not sure if that would be useful

Thanks!
No problem - glad for the responses. Remember that the saved PDF page from Firefox exhibits the problem, while the saved PDF page from Google does not.

The funny thing is, the fonts don't appear to be using Times Roman. The font looks to me a lot like Arial. Maybe that's the ".SF NS" font. I can't attach the page to show you because it contains personal financial information.

(In reply to Bill Stephens from comment #5)

there is no option (such as you describe) to save the page in any format except PDF. I tried changing the extension to "html" and changing the "file format" from "PDF" to "All files", and this produced a raw dump of the PDF file. Not sure if that would be useful

Ah, gotcha -- so the statement itself is a PDF file, and Firefox is failing to print that PDF. (I was initially misunderstanding this as being an HTML page that was having trouble when printed to PDF.)

Remember that the saved PDF page from Firefox exhibits the problem, while the saved PDF page from Google does not.

Just to be extra clear: if you directly save the PDF using File|Save, then I'll bet that saved PDF renders just fine, right? I would imagine it's only when you print from Firefox to the Save-to-PDF print-target, that's what produces broken output. Is that right?

(These might seem like the same operation, but they're meaningfully different; one is just saving the exact file that the bank gave you, and the other is sort of resynthesizing the PDF from scratch. The latter process does have various opportunities for issues to creep in.)

URL: https://www.firstcomcu.org/
Summary: Character "S" not rendering properly on website or printouts from website. → Character "S" not rendering properly on printed statements from firstcomcu.org

(In reply to Daniel Holbert [:dholbert] from comment #7)

(In reply to Bill Stephens from comment #5)

there is no option (such as you describe) to save the page in any format except PDF. I tried changing the extension to "html" and changing the "file format" from "PDF" to "All files", and this produced a raw dump of the PDF file. Not sure if that would be useful

Ah, gotcha -- so the statement itself is a PDF file, and Firefox is failing to print that PDF. (I was initially misunderstanding this as being an HTML page that was having trouble when printed to PDF.)
Uh, no. The statement when viewed in Firefox is in shtml format. The appearance of the statement on the screen is correct. When printing the statement ewither to a printer or to a PDF file, the problem occurs.

Remember that the saved PDF page from Firefox exhibits the problem, while the saved PDF page from Google does not.

Just to be extra clear: if you directly save the PDF using File|Save, then I'll bet that saved PDF renders just fine, right? I would imagine it's only when you print from Firefox to the Save-to-PDF print-target, that's what produces broken output. Is that right?
No, as mentioned above, the saved PDF file contains the same error. The assumption that the statement is presented initially in PDF format is incorrect. Remember, we inspected the document, and when I did, I saw HTML.
(These might seem like the same operation, but they're meaningfully different; one is just saving the exact file that the bank gave you, and the other is sort of resynthesizing the PDF from scratch. The latter process does have various opportunities for issues to creep in.)
OK, so let's review the problem:

  1. I view the statement using Firefox browser, and everything looks fine.
  2. I print the statement using the Firefox "print" functionality, and the problem occurs.
  3. If, from the Firefox "Print" menu, I select "Print using system dialog", the problem still occurs.
  4. If I "print" to a PDF file, the PDF file contains the error.
  5. These problems do not occur when using Safari or Google.

And with respect to point number 1 above, the file is presented in HTML format, not PDF.

I'm just wondering if there might be a character preceding the S that Firefox is interpreting as some kind of escape character, preventing the proper rendering of the S.

Gotcha, sorry for misunderstanding.

I view the statement using Firefox browser, and everything looks fine.

So, this is the part where I'm hoping you might be able to do "File | Save As", and choose "Web Page, Complete" -- would you mind trying that? (and then seeing if the resulting saved HTML still reproduces the bug; hopefully it does)

I'm guessing that when you tried File|Save before, it was when you were viewing the broken PDF, which is why the save dialog only offered you PDF options.

Same request for the font devtools -- I'm not sure if your previous response about the fonts were when you were viewing the website vs. the broken PDF, but I'm wanting to know the fonts that the website uses for the elements in question (in the interests of perhaps being able to recreate the problem locally.)

Thanks!

(In reply to Bill Stephens from comment #10)

I'm just wondering if there might be a character preceding the S that Firefox is interpreting as some kind of escape character, preventing the proper rendering of the S.

(This is a good idea, but I doubt it's exactly that, given that it happens for literally every "S" in your screenshot, and it's unlikely that the site is putting an unrendered escape-like character before every single "S". I'm betting it's something to do with the specific font that's used, and our printing backend is simply having trouble drawing or incorporating this font's "S" character for some obscure reason. It's probably not exactly this, but an example: sometimes sites split up a single font on a character-by-character level, for example -- they host their own font, and one font file has certain characters, and another font file certain other characters -- and it could be that one of the web font files is failing to get incorporated into the PDF for some reason.)

I think there may still be a misunderstanding here. I suspect the statement is in fact being served as a PDF by the bank's site, and that's why there is no option to save it in HTML form. When you "inspect" it in Firefox, what you're inspecting is the built-in pdf.js-managed page that Firefox is using to render the PDF onto an HTML <canvas> so that it displays on screen.

That makes sense of the font inspector showing Times Roman and .SF NS, which are just the defaults in the browser window that's displaying the PDF as a graphic drawn to a canvas. The PDF probably contains embedded font resources that are used for the actual rendering, but the Firefox inspector can't "see" those as they aren't used to render any HTML text.

This also helps explain the rather "rough" text rendering we see in "Previous Balance" at the bottom of the image. HTML text wouldn't be likely to come out so irregular, but depending how the PDF is constructed, the glyphs may be painted individually rather than as a line of text, and rounding errors or other issues could be resulting in the wonky appearance.

As for the missing S glyphs: my guess is that the bank's process that generates the PDF statement is embedding a subset, re-encoded version of the font containing only the glyphs that are actually used; and that process is re-encoding it in such a way that "S" ends up at a character position (possibly character code zero) that subsequently fails to render because some layer of the code thinks it's invalid. (But this is getting a bit speculative on my part.)

cc'ing Calixte, as I think this may actually be a pdf.js-related issue at some level -- to do with font encoding mappings.

One way to confirm what kind of document we're dealing with: when you are viewing the statement in Firefox, is there a >> button at the right-hand side of the toolbar across the top of the window, which when clicked reveals a "tools" menu? If so, this is the pdf.js viewer displaying a document that was provided as a PDF file. The "Document Properties" option at the end of the menu may even reveal something about how it was generated.

You can also check Page Info in the browser's Tools menu, and see what it shows for "Type". I suspect it will be application/pdf, and not text/html, meaning that the bank is serving the statement as a PDF.

Flags: needinfo?(whs1993)

(In reply to Jonathan Kew [:jfkthame] from comment #13)

This also helps explain the rather "rough" text rendering we see in "Previous Balance" at the bottom of the image. HTML text wouldn't be likely to come out so irregular, but depending how the PDF is constructed, the glyphs may be painted individually rather than as a line of text, and rounding errors or other issues could be resulting in the wonky appearance.

So the screenshot is definitely a screenshot of a PDF -- the broken PDF that Firefox produced when printing to the save-to-PDF print target.

But I think it's still an open question as to whether the statement (the thing-that-Bill-is-printing is HTML vs. a PDF). If it's HTML, that's nice because it's easier to minimize and potentially reconstruct on our end. (I'm currently guessing we may've had a mixup where Bill's earlier File|Save & font-devtools responses were from when he was viewing the broken PDF, rather than viewing the original statement-that-renders-just-fine -- totally understandable since I wasn't clear on that -- but I'm not entirely sure.)

(In reply to Daniel Holbert [:dholbert] from comment #11)

Gotcha, sorry for misunderstanding.

I view the statement using Firefox browser, and everything looks fine.

So, this is the part where I'm hoping you might be able to do "File | Save As", and choose "Web Page, Complete" -- would you mind trying that? (and then seeing if the resulting saved HTML still reproduces the bug; hopefully it does)

You are correct, sir! The initial screen displayed by the bank exhibits the ">>" menu item. I was able to save that as an HTML file, doing so created a "First Commonwealth Federal Credit Union.html" file ANDnd a "First Commonwealth Federal Credit Union _files" directory with a bunch of supporting files. Oddly, when I double-click on "First Commonwealth Federal Credit Union.html", all that shows is a blank screen, but when I view the html file using TextEdit, it looks like 10 miles of bad road. I would attach a screen shot but I don't see any way of doing that here.
I'm guessing that when you tried File|Save before, it was when you were viewing the broken PDF, which is why the save dialog only offered you PDF options.
That is correct as well. When I tried your suggestion on a local HTML file, it did offer the HTML options you mentioned.

Same request for the font devtools -- I'm not sure if your previous response about the fonts were when you were viewing the website vs. the broken PDF, but I'm wanting to know the fonts that the website uses for the elements in question (in the interests of perhaps being able to recreate the problem locally.)

I'm not sure what you want me to do here.

The initial display is that of the PDF file. It includes a link to open the page in a new browser window, which is what I've been doing, so I had never tried to print from the initial PDF statement rendering. So, I tried printing from there, but the problem persists.

Thanks!

Flags: needinfo?(whs1993)

(In reply to Daniel Holbert [:dholbert] from comment #12)

(In reply to Bill Stephens from comment #10)

I'm just wondering if there might be a character preceding the S that Firefox is interpreting as some kind of escape character, preventing the proper rendering of the S.

(This is a good idea, but I doubt it's exactly that, given that it happens for literally every "S" in your screenshot, and it's unlikely that the site is putting an unrendered escape-like character before every single "S". I'm betting it's something to do with the specific font that's used, and our printing backend is simply having trouble drawing or incorporating this font's "S" character for some obscure reason. It's probably not exactly this, but an example: sometimes sites split up a single font on a character-by-character level, for example -- they host their own font, and one font file has certain characters, and another font file certain other characters -- and it could be that one of the web font files is failing to get incorporated into the PDF for some reason.)

(In reply to Jonathan Kew [:jfkthame] from comment #13)

I think there may still be a misunderstanding here. I suspect the statement is in fact being served as a PDF by the bank's site, and that's why there is no option to save it in HTML form. When you "inspect" it in Firefox, what you're inspecting is the built-in pdf.js-managed page that Firefox is using to render the PDF onto an HTML <canvas> so that it displays on screen.

That makes sense of the font inspector showing Times Roman and .SF NS, which are just the defaults in the browser window that's displaying the PDF as a graphic drawn to a canvas. The PDF probably contains embedded font resources that are used for the actual rendering, but the Firefox inspector can't "see" those as they aren't used to render any HTML text.

This also helps explain the rather "rough" text rendering we see in "Previous Balance" at the bottom of the image. HTML text wouldn't be likely to come out so irregular, but depending how the PDF is constructed, the glyphs may be painted individually rather than as a line of text, and rounding errors or other issues could be resulting in the wonky appearance.

As for the missing S glyphs: my guess is that the bank's process that generates the PDF statement is embedding a subset, re-encoded version of the font containing only the glyphs that are actually used; and that process is re-encoding it in such a way that "S" ends up at a character position (possibly character code zero) that subsequently fails to render because some layer of the code thinks it's invalid. (But this is getting a bit speculative on my part.)

Makes sense.

(In reply to Jonathan Kew [:jfkthame] from comment #15)

Created attachment 9402085 [details]
example of the pdf-viewer tools menu

One way to confirm what kind of document we're dealing with: when you are viewing the statement in Firefox, is there a >> button at the right-hand side of the toolbar across the top of the window, which when clicked reveals a "tools" menu? If so, this is the pdf.js viewer displaying a document that was provided as a PDF file. The "Document Properties" option at the end of the menu may even reveal something about how it was generated.

Of possible interest in the "Document Properties" display is this line: Creator: GMC Software AGInspire11.0.169.0

You can also check Page Info in the browser's Tools menu, and see what it shows for "Type". I suspect it will be application/pdf, and not text/html, meaning that the bank is serving the statement as a PDF.

Nope - it says "text/html". It would really be helpful if I could upload some screenshots here, but that doesn't seem to be possible. I can email you screen-shots if you prefer; I think it would eliminate some of the ambiguity we're dealing with.

Sure - anything you're not comfortable sharing publicly but comfortable emailing, please feel free to email! (dholbert at mozilla.com, jkew at mozilla.com). We'll take care to keep personal details confidential.

So based on comment 18 - 19, it sounds like the initial "working" presentation from the bank is just an HTML page that has an embedded PDF, and that embedded PDF is the relevant thing that looks good but prints poorly in Firefox, perhaps due to Jonathan's theory at the end of comment 13.

I would bet you can directly save a local copy of the working-just-fine PDF when you're viewing the statement on the bank's website, by using the ">>" menu and looking for a "Save" item near the top (or possibly a folder icon with a downarrow just to the left of the ">>" menu). Then, I would bet you can open that saved PDF directly in Firefox, and it will probably look fine good, but it'll reproduce the issue when you attempt to print it.

(Assuming that all checks out: if it's possible to find or generate a statement PDF that reproduces the problem when printed & that you'd be comfortable sharing confidentially over email, feel free to send it to us using contact info in comment 20, and we might be able to confirm/refute Jonathan's theory from comment 13 and find what edge case the PDF is triggering that needs fixing. Though also, no worries if you're not comfortable doing that; I appreciate that financial details are sensitive.)

I’ve sent 3 files via email to the interested parties on this bug.

The first one is a screen shot of how the statement initially appears when I bring it up, after I click on the “>>” and selecting “Document Properties”.

The second file shows the appearance when using the “Print” icon. Everything appears correct.

The third is the redacted printout that was scanned back in so I could attach it to this email. You can see where the uppercase “S” is missing. One thing I notice now that I didn’t before is that only the boldface uppercase “S” seems to be affected. Notice how in my last name the first and last “S”s are missing, but the “s”s in the remainder of the address appear correctly.

:Bill, please send me the files too, thank you.

Thanks Bill! I'll forward the files along to Calixte (who works on Firefox's PDF viewer).

There's a decent chance that this is a version of bug 1854094, particularly given that Bill is on macOS...

I'm also noticing that bug 1854094 seems to have been fixed by a recent Cairo update (bug 1892913).

Bill: would you mind testing this bug in Firefox Nightly ( https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly ) and see if you can reproduce there? I'm hopeful that it might be working, if this was the same underlying cairo bug as we were hitting in bug 1854094.

Flags: needinfo?(whs1993)
See Also: → 1854094

Re: Comment 25
Just tested with Nightly, statement printed properly. :-D

Flags: needinfo?(whs1993)

Oh, that's great news -- thanks!

I'll close this as FIXED by bug 1892913, then (pretty high likelihood that that's what fixed it). That fix made it in time for the Firefox 127 cycle which is currently on beta and going to release in 4 weeks, tentatively on June 11 or 12.

If you wouldn't mind re-testing Firefox release on-or-after that release day (and being sure you've been updated to Firefox 127 via checking "About Firefox" in the macOS Firefox menu at the top left), that would be awesome.

Thanks again for filing the bug and for your help in getting to the bottom of it! Happy to know that it's already been fixed. :D

Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Depends on: 1892913
status-firefox127: --- → fixed
Target Milestone: --- → 127 Branch

Just installed 127.0, verified problem no longer occurs. Good work!

Thanks - I appreciate the verification!

Status: RESOLVED → VERIFIED
status-firefox127: fixed → verified
See Also: → 1908587
See Also: → 1916444

This regressed in Firefox 130, and the new occurrence is tracked in bug 1916444. (It regressed because we had to revert part of the patch that fixed this, to avoid other breakage.)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: