Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Font substituting while printing doesn't work on Windows Server 2016 #41847

Open
3 tasks done
dahaged opened this issue Apr 12, 2024 · 2 comments
Open
3 tasks done
Labels
29-x-y 30-x-y bug 🪲 has-repro-gist Issue can be reproduced with code at https://gist.github.com/ platform/windows

Comments

@dahaged
Copy link

dahaged commented Apr 12, 2024

Preflight Checklist

Electron Version

29.1.5

What operating system are you using?

Windows

Operating System Version

Windows Server 2016 Standard 1607

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

A PDF that uses fonts that aren't downloaded/installed should have its fonts substituted and print correctly.

Actual Behavior

The exact behavior seems to vary with the Electron version, ranging from text disappearing to creating a 0KB file that can't be opened (If printing to PDF), but every version I've tested has resulted in an unreadable or unusable PDF. Currently, in Electron 29.1.5, it is creating a broken 0KB file.

Testcase Gist URL

No response

Additional Information

PDF used to test: FontSubTest.pdf
URL where PDF was taken from: https://www.adobe.com/support/products/enterprise/knowledgecenter/media/c4611_sample_explain.pdf
You can just load the PDF into a window and use the PDF viewer's print button.

This seems to only happen on Windows Server 2016 as I have been able to print correctly on Windows Server 2019 and 2022 and on Windows 10. Printing the same PDF in another browser (Edge, Chrome, and even Internet Explorer) prints correctly and will cause printing through Electron to work afterwards (logging out and back in causes the issue to happen again).

It seems to be related to FontSub.dll since Edge/Chrome have that DLL loaded and are using it multiple times while Electron only loads it once while printing before unloading it. I think Edge/Chrome is creating a font package if one doesn't exist while Electron is only using the font package if it already exists.

@mlaurencin mlaurencin added the blocked/need-repro Needs a test case to reproduce the bug label Apr 12, 2024
@electron-issue-triage
Copy link

Hello @dahaged. Thanks for reporting this and helping to make Electron better!

Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? For example, Electron Fiddle is a great tool for making small test cases and makes it easy to publish your test case to a gist that Electron maintainers can use.

Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

Now adding the blocked/need-repro Needs a test case to reproduce the bug label for this reason. After you make a test case, please link to it in a followup comment. This issue will be closed in 10 days if the above is not addressed.

@dahaged
Copy link
Author

dahaged commented Apr 12, 2024

@electron-issue-triage electron-issue-triage bot removed the blocked/need-repro Needs a test case to reproduce the bug label Apr 12, 2024
@mlaurencin mlaurencin added platform/windows has-repro-gist Issue can be reproduced with code at https://gist.github.com/ 29-x-y 30-x-y labels Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
29-x-y 30-x-y bug 🪲 has-repro-gist Issue can be reproduced with code at https://gist.github.com/ platform/windows
Projects
Status: 👍 Does Not Block Stable
Status: 👀 Unsorted Items
Development

No branches or pull requests

2 participants