astefanutti / decktape

PDF exporter for HTML presentations

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crashes with "Unable to write GSUB: script latn has no default language system"

olberger opened this issue · comments

Hi.

Strangely, I have a crash with the following trace (see below), where I cannot get hints on google search either on "Unable to write GSUB" nor "script latn has no default language system" ... maybe the latn provides a hint... should be "latin" ? But I can't spot any culprit...

Any hints welcome.

Unable to find image 'astefanutti/decktape:3.8.0' locally
3.8.0: Pulling from astefanutti/decktape
Digest: sha256:b64970f202eabdf575a15597d8e0bcd95ce9a7d6c758d835ba61b40d5ac9a3e9
Status: Downloaded newer image for astefanutti/decktape:3.8.0
Loading page file:///COURSEROOT/index.html ...

Unable to load resource from URL: file:///COURSEROOT/reveal.js/lib/js/head.min.js
Failed to load resource: net::ERR_FILE_NOT_FOUND
Allow attribute will take precedence over 'allowfullscreen'.
Loading page finished with status: 200
Reveal JS plugin activated
Printing slide #/slide-org484a8e2 (93/93) ...
Error: Unable to write GSUB: script latn has no default language system.
    at fail (/decktape/node_modules/opentype.js/dist/opentype.js:919:12)
    at Object.argument (/decktape/node_modules/opentype.js/dist/opentype.js:926:10)
    at /decktape/node_modules/opentype.js/dist/opentype.js:2032:20
    at recordList (/decktape/node_modules/opentype.js/dist/opentype.js:1990:33)
    at new ScriptList (/decktape/node_modules/opentype.js/dist/opentype.js:2029:10)
    at Object.makeGsubTable [as make] (/decktape/node_modules/opentype.js/dist/opentype.js:6874:50)
    at Object.fontToSfntTable [as fontToTable] (/decktape/node_modules/opentype.js/dist/opentype.js:7220:27)
    at Font.toTables (/decktape/node_modules/opentype.js/dist/opentype.js:13545:18)
    at Font.toArrayBuffer (/decktape/node_modules/opentype.js/dist/opentype.js:13559:27)
    at file:///decktape/decktape.js:400:73

This appeared in 3.8.0 image and didn't occur with 3.7.0, FWIW.

I observe this as well but it seems to be duplicate with #284

It should be fixed in 3.9.0 release.

Thanks a lot for the report!