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

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.

[devongovett]

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

[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 [e-mail] 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 https://github.com/devongovett/pdfkit/issues/114#issuecomment-404874802, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiNheBZQ_pA7E-ebwY-rXnozvalIfbCks5uGMKWgaJpZM4Acnoo .