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

Add full support for UTF-8 characters #112

Open
HughxDev opened this issue Jan 31, 2021 · 5 comments
Open

Add full support for UTF-8 characters #112

HughxDev opened this issue Jan 31, 2021 · 5 comments
Labels
bug Something isn't working pdfkit bug A bug that results from an issue in pdfkit

Comments

@HughxDev
Copy link

I can’t export Japanese text to PDF, even though it shows up fine in the preview.

While editing:
Screenplay preview: Japanese text and subtitles in dual dialog format

After exporting:
Screenplay export: Dual dialog with missing text on the right side

@piersdeseilligny
Copy link
Owner

I believe that's a font issue, because Courier Prime doesn't include those characters - definitely something that I'm going to look at fixing though.

In the meantime though, the good news is that it should hopefully work if you change the font (with the Font: title page key)

@piersdeseilligny piersdeseilligny added the bug Something isn't working label Jan 31, 2021
@HughxDev
Copy link
Author

@piersdeseilligny Thanks. My suggestion for the full fix would be to implement something similar to CSS’s font-family, where fallback fonts can be specified in a comma-separated list in the Font: key. I.e. use the first font for everything if possible, but for any glyph that is missing, try rendering it in the next font in the stack, and repeat that process if necessary.

@geueds
Copy link
Contributor

geueds commented Mar 8, 2021

@hguiney What font are you using for editing (I mean, the vscode font itself)?

@piersdeseilligny
Copy link
Owner

@piersdeseilligny Thanks. My suggestion for the full fix would be to implement something similar to CSS’s font-family, where fallback fonts can be specified in a comma-separated list in the Font: key. I.e. use the first font for everything if possible, but for any glyph that is missing, try rendering it in the next font in the stack, and repeat that process if necessary.

So unfortunately pdfkit doesn't support that (see foliojs/pdfkit#201) even though it really should. However @at-guedesnt is working on merging a bunch of courier-type fonts, so that'll hopefully fix the issue :)

@geueds
Copy link
Contributor

geueds commented Mar 8, 2021

@piersdeseilligny Thanks. My suggestion for the full fix would be to implement something similar to CSS’s font-family, where fallback fonts can be specified in a comma-separated list in the Font: key. I.e. use the first font for everything if possible, but for any glyph that is missing, try rendering it in the next font in the stack, and repeat that process if necessary.

So unfortunately pdfkit doesn't support that (see foliojs/pdfkit#201) even though it really should. However @at-guedesnt is working on merging a bunch of courier-type fonts, so that'll hopefully fix the issue :)

Sure! Please check the Courier Plus project :)

@piersdeseilligny piersdeseilligny added the pdfkit bug A bug that results from an issue in pdfkit label May 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working pdfkit bug A bug that results from an issue in pdfkit
Projects
None yet
Development

No branches or pull requests

3 participants