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

Compound glyphs are not rendered #2749

Closed
taohkubo opened this issue May 20, 2020 · 3 comments · Fixed by #2835
Closed

Compound glyphs are not rendered #2749

taohkubo opened this issue May 20, 2020 · 3 comments · Fixed by #2835
Labels

Comments

@taohkubo
Copy link

Symptom

When a font includes a compound font, it's not rendered at all or rendered in a wrong shape. The issue occurs depending on what font is used. In my environment, the issue is observable in Albany font and Arial Unicode MS. In Albany font case, all glyphs belongs to Hangul Syllables Unicode block and 40 glyphs in Latin Extended Additional are not rendered at all or rendered in wrong shape.

Reproduce

Please obtain Albany font or Arial Unicode MS font and make base64 encoded font script file as I cannot attach the font file. The following reproduce step is based on Arial Unicode MS ver 1.01x coming with Office 2016.

  1. Get the attached testcase.zip file and extract it
    testcase.zip
  2. Deploy the font script file of Arial Unicode MS font in the same folder
  3. Open testcase.html extracted from testcase.zip with a browser, result pdf file will be exported. This may take 30 seconds or more depending on the client spec.
  4. Review the exported pdf file and observe the Hangul characters are not rendered.

As the testcase exports all characters between 0xAC00 and 0xd7af code point, it will take relatively long time to export. Please edit the testcase.html file to change the exporting characters as needed.

The attached testcase.zip file also include the sample exported pdf file showing the issue and the expected pdf file for reference.

Findings

It seems the issue occurs because glyph id becomes a negative number in CompoundGlyph function. When reading additional glyphs of the compound glyph, glyph id is read using the following code.
this.glyphIDs.push(data.readShort());

Data.readShort() returns a number as signed integer. But according to the doc below, glyph IDs seems to be unsigned integer numbers.
https://docs.microsoft.com/en-us/typography/opentype/spec/glyf

Glyphs are referenced by identifiers (glyph IDs), which are sequential integers beginning at zero.

Assuming this is applicable in jsPDF logic, the glyph id needs to be handled as unsigned integer. Then the above logic would need to be like below?
this.glyphIDs.push(data.readUInt16());

With this change, the compound glyphs seems to be rendered as expected. Please find the expected result pdf in the attached zip file which is generated with this code change.

@HackbrettXXX
Copy link
Collaborator

Sorry for my delayed answer. This sounds good. Could you prepare a pull request?

@taohkubo
Copy link
Author

Could it be possible to include the fix in your end? I attached the fixed file and diff file for your info. The build process was successfully completed with this fix in my local environment. I verified the built jsPDF script resolves the Compound glyph issue.
2749-fix.zip

@HackbrettXXX
Copy link
Collaborator

Ok, I'll include the fix myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants