Embedded font subset needs to be sharded to support pdf file with more than 127 glyphs

[kamikat]

When the embedded character glyph‘s id grows over 127 (the @next variable in Subset.coffee), Adobe Reader and Okular will not read the glyph(a character indicating glyph missing is displayed). Foxit Reader and Google Chrome will display the glyph correctly but have problem calculating width of character (the width of the glyph is ignored and the following character will overlay on this character). The character with id = 127 will not display in all readers.

I found that there are many pdf file have several subset to same FontFamily. Maybe there is a limit in the Subset and PDFKit should implement a sharding in font subsetting.

[nirajp]

I observe the same behavior. It is necessary to fix this.

[hks2002]

any new about this?

[nirajp]

I did make some fixes in a forked repo. You might want to check https://github.com/menway/pdfkit

[hks2002]

thank you.
But I am not familiar to coffee, even node.js. I just want to use pdfmake.js to generate PDF file on client browser side. I found CJK text can't show in pdf, then see pdfmake use pdkkit as its core, then found the root cause.

i need more times to learn coffee and node.js. thank you again.

[kamikat]

You can look into bpampuch/pdfmake#221 which makes a hack on pdfmake.

[jwerre]

What is the status on this? Is this still an issue?

[ben-at-xtramath]

@devongovett We're using pdfkit to generate certificates etc, but have been running into various issues related to the above when using Japanese. I've tried the fontkit branch and that works pretty well. The issue is that for the browser, we'd like to avoid having the user download a Japanese font every time just to get it to work.

I like pdfkit, but want to avoid the need to register/embed a font and just rely on a user's built in fonts for non Roman character. My understanding of Adobe's handling of CID fonts makes me think that this is possible. I'm getting a little lost between reading Adobe docs and pdfkit source code. Could you point me in the right direction(or provide some thoughts) if I wanted to add this capability to pdfkit?

Thank you

[devongovett]

This should be fixed in v0.8.0, which uses CID fonts.

[kelly-tock]

i'm still seeing issues with japanese characters after upgrading to the latest. is there a particular font I should specify you think to handle asian characters?

[jwerre]

@kelly-tock I had the best luck with Arial.

[kelly-tock]

so I still think there are some issues. with the interactive browser demo linked to from the docs, you can't render asian characters. is there some other metadata needed to set to handle this case?

[kelly-tock]

just as a simple repro, the interactive browser demo does not display correctly if you enter japanese characters in it.

[nirajp]

I had fixed asian character rendering in my own fork https://github.com/nirajp/pdfkit. You may want to try it out. That was more than 4 year ago, so not sure if those will still hold. You might have to merge my changes with latest devongovett/pdfkit. My changes were not compatible with devongovett/pdfkit, hence I could not submit a pull request, but nevertheless the changes did serve my purpose well at the time. Best luck.

…

On Fri, 13 Jul 2018 at 21:23, Kelly ***@***.***> wrote: just as a simple repro, the interactive browser demo does not display correctly if you enter japanese characters in it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiNheBZQ_pA7E-ebwY-rXnozvalIfbCks5uGMKWgaJpZM4Acnoo> .