Pdfkit: Font Subset Failure with Multiple Languages

[dncrews]

I'm using the library to generate a PDF that contains both both Japanese and Roman characters. Future use may include even more languages in a single document.

Demo may take a second to spin up the Heroku dyno:
Demo
Code

For some reason, some characters are becoming empty during generation. In the example, look at the footer of the second page. The first word should be "Dude", but the "D" is not getting included in the font subset (Arial), so it's loading as an empty square.

I included the font in the repository, to show that the characters are there, but they're not getting included in the subset. Please help.

More Info:
In Safari, the lowercase "d" is also not shown.

[jamesblack]

+1

[jshcrowthe]

+1

[devongovett]

Thanks for leaving such a detailed description with running code for this bug, that really helps. At first glance it looks like you may be hitting some sort of limit in the number of glyphs in a single font (in the way PDFKit encodes them) of 128. A hack to test this could be to make a copy of your font file named e.g. Arial2.ttf, and do some of the text in that to see if it works. I'll take a deeper look later tonight.

[dncrews]

Good suggestion. I updated the code and demo, adding a set of that string in "arial2", and it still fails. When I switch to a completely different font, however, it does seem to work. I added one with "Times-Roman", and that one has all of its characters.

Any thoughts?

[devongovett]

Well Arial itself has a lot of characters, so maybe PDFKit is reading it wrong? I'm not sure. I'll take a look later tonight. Sorry about the wait. Let me know if you find anything else.

[dncrews]

No worries. Thank you for your help.

[jamesblack]

Thank you indeed!

[devongovett]

Yeah looks like PDFKit detected that Arial.ttf and Arial2.ttf were really the same font (they have the same name in the font file) and only embedded the first one. :frowning: After some more digging, it definitely looks like it's the number of glyphs exceeding 127 that causes the problem. This issue has been documented previously in #114 and #192.

I have been working on a brand new font engine for PDFKit for some time now and it works fine with that since everything is encoded as CID fonts. I hope to release it soon, but unfortunately it's not quite ready for prime time yet.

In the meantime, there's not a really great solution, but you can try the two font trick as before, but clearing PDFKit's font cache so it doesn't reuse the first one. You don't even need two different files, just one will do. Here's a working example:

  var doc = new pdfDocument({size: "A4", margins : {top : 0, bottom : 0, left : 0, right : 0} });

  doc.pipe(res);
  doc.registerFont('arial', path.join(__dirname + '/Arial.ttf'), 'arial');
  doc.registerFont('arial2', path.join(__dirname + '/Arial.ttf'), 'arial');
  doc.font('arial');

  // HACK: clear font cache for real font name
  delete doc._fontFamilies['ArialUnicodeMS'];

  doc.info.title = "My Booklet";

  // do some with the first font
  doc
    .fontSize(14)
    .text('(A,诶,ēi) (B,比,bǐ) (C,西,xī)')
    .text('(D,迪,dí) (E,伊,yī) (F,艾弗,ài fú)')
    .text('(G,吉,jí) (H,艾尺,ài chǐ) (I,艾,ài)')
    .text('(J,杰,jié) (K,开,kāi) (L,艾勒,ài lè)')
    .text('(M,艾马,ài mǎ) (N,艾娜,ài nà) (O,哦,ó)')

  // and some with the second font
  doc.font('arial2')
    .text('(P,屁,pì) (Q,吉吾,jí wú) (R,艾儿,ài ér)')
    .text('(S,艾丝,ài sī) (T,提,tí) (U,伊吾,yī wú)')
    .text('(V,维,wéi) (W,豆贝尔维,dòu bèi ěr wéi)')
    .text('(X,艾克斯,yī kè sī) (Y,吾艾,wú ài) (Z,贼德,zéi dé)')
    .text('abcdefghijklmnopqrstuvwxyz')
    .text('ABCDEFGHIJKLMNOPQRSTUVWXYZ');

  doc.end();

[dncrews]

OK, thanks a ton for your help and suggestions. It's not the best solution, but it's definitely better than any other one that is currently available, so I thank you for it. I'll be watching for the new font engine.

[dncrews]

FWIW, I wasn't able to get font injecting working on the client (no fs), which I would need to be able to implement this non-blockingly (character counting).

[birgitta410]

We were trying the workaround with embedding the font multiple times, but it still seemed to be caching it, even when we used a different first parameter ('arial1', 'arial2', 'arial3', ...).

When we replaced this line with "if false", the caching stopped:
https://github.com/devongovett/pdfkit/blob/e58a7ce809520144d5053e311cf36c89695b991b/lib/mixins/fonts.coffee#L44

Is that something that sneaked in after the suggestion of the workaround, or did we do something wrong when we tried it before?

[wwwmir3cq]

doc.registerFont('arial', path.join(__dirname + '/Arial.ttf'), 'arial');
doc.registerFont('arial2', path.join(__dirname + '/Arial.ttf'), 'arial');
when use the same ttf,
doc.font('arial');
doc.font('arial2') //the second font(...) don't stop cache.

int PDFFont.font :
this._font = new PDFFont(this, src, family, id);

// this._font.name  with the same name which get from ttf

//the follow code will return (may be the autor want to improve perfermance),don't clear the cache
// so,we should annotation the code,or add a params name celarCache to control it like this
// if (font = this._fontFamilies[this._font.name] && !celarCache ) {
//then we can use doc.font('arial',true), it will be stop the same ttf cache,the problem will go away.

 if (font = this._fontFamilies[this._font.name]) {
    this._font = font;
    return this;
  }
  if (cacheKey) {
    this._fontFamilies[cacheKey] = this._font;
  }
  this._fontFamilies[this._font.name] = this._font;

[bsergean]

Hi there, any news on the CID Font branch ... ?

Would it be a lot of work to push the branch to github, or would it make any sense to have an opt-in mode that enable CID support in the normal build of pdfkit ?

I tried playing with pdfkit-cjk but it looks behind, and I ran into runtime problems when trying to use it.

[jwerre]

@devongovett on Jun 25, 2014 you said:

I have been working on a brand new font engine for
PDFKit for some time now and it works fine with
that since everything is encoded as CID fonts. I
hope to release it soon, but unfortunately it's not
quite ready for prime time yet.

What is the status on this?