Unicode rendered properly on macOS but not on ubuntu

[halo]

This issue got me thinking. I agree that this is 99.9% related to the font that is used. But I wanted to ask if there is any other possible explanation for unicode not working properly?

For me, the Euro-sign and the "endash" work only in development (macOS) but not in production (heroku):

I'm using Roboto Condensed throughout most of the PDF, which has a pretty good support for unicode.

I noticed however, that the Euro-symbol in my generated PDF does not look like it should have. In the used font Roboto Condensed the symbol should have looked like the following, but it doesn't.

I'm not just switching fonts anywhere as far as I can tell. Maybe the endash is also just a fallback but it's hard to tell.

So, does prawn on macOS fall back to standard fonts when rendering unicode, but on ubuntu it does not? Is there an encoding setting in prawn that could have changed on another machine? Or could the file become corrupted at the time of the download? How can prawn fall back in one case but not in another? Is there any external library (outside of ruby) that could be out-of-sync between the environments?

I'm having a hard time even explaining how this different rendering might occur.

Thank you for your time!

[gettalong]

Prawn doesn't depend on the operating system for fonts, it works the same everywhere. What may be different may be the font rendering on different operating system in case a font is not embedded in the PDF. However, since Prawn always embeds fonts this shouldn't be a problem.

[gettalong]

@halo Could you provide the same PDF, once generated in production and once in development? Then I can have a look and see if there are differences.

[halo]

What may be different may be the font rendering on different operating system

Encouraged by your train of thoughts I tried to find where in the process the PDF could become corrupted. Alas, I found who is responsible. The PDF files in development and production are identical. I just happen do "see" them in Chrome locally whereas I'm logged into production using Safari and its viewer.

The built-in Chrome PDF viewer will happily fall back to another font for any unicode character, whereas Safari shows me the PDF as it is.

I just never noticed, because the Euro-sign and the endash look so similar in my custom font and in the fallback font.

Thank you very much for letting me ping-pong this with you 👍🏻 and I hope someone else will find this discussion useful. As for me, I'll now simply have to dig in why the font is not used for these characters, but I think I can handle that, because I know now how to reproduce the problem locally.

[halo]

And I quickly identified the root cause. I've been using ttf-files distributed via an NPM package instead of downloading the files directly from Google and checking them into my git repository.

Those files from NPM appear to support unicode, because when I install them on my operating system and choose them as font in a text editor, the euro sign and the endash work properly (they look just as they should in Roboto and there is no fallback). But for some reason prawn cannot handle them. I assume it has to do with the magic that the author of the NPM package does to the files:

I checked the pristine ttf files from Google into my code now and prawn handles unicode just fine with those. 🚀