Problem with NFD normalized Unicode

[tebeka]

I'm writing a book on programming and want to show NFC & NFD normalized Unicode. The NFD version is not rendered well on PDF.

Here's a short example:

I once went to Kraków, it's a nice city. (NFC)

I once went to Kraków, it's a nice city. (NFD)

Here's the output (note the second line)

Original discussion here

[gettalong]

Tl;dr: This is to be expected due to the current implementation of ttfunk.

NFD represents composed characters with multiple Unicode code points. This means that the application doing the rendering needs to understand that. Since PDF is, so to say, pre-rendered by the application creating the PDF, this work falls to Prawn and ttfunk.

Normally there is some information in the font file that allows an application to correctly place multiple glyphs representing a single character correctly. So to render such a character the application has to make use of this information which ttfunk currently doesn't. However, there is currently work going on to support more of the OpenType standard and then this might work.

[gettalong]

@tebeka Also see https://gist.github.com/gettalong/d894c29b551917573c708cd5110653a0

[tebeka]

Thanks!

[tebeka]

When using Libertine font, the output is OK but the code doesn't render that great in non monospace font

I've tried to use LibertinusMono as the code font. It shows the umlaut but not on top of the o

Any idea for a monospaced font that will work?

[tebeka]

FWIW: IBM Plex Mono (almost) does the job

[gettalong]

@tebeka As mentioned in the link I posted, the behaviour depends entirely on the font. Each glyph defines a horizontal offset. For LibertinusMono that seems to be the "standard" offset whereas Plex Mono defines a negative offset so that the apostrophe overlaps the previous character.

In both cases no additional information from the font is used by Prawn/ttfunk. So this will probably never work with current versions of Prawn/ttfunk since the horizontal offset of the apostrophe has to vary based on the previous character. Such information is available in additional data structures inside the font but the library needs to understand that.

[pointlessone]

Prawn implement a very basic text layout algorithm. It basically takes individual glyphs and draws them one by one. This is why decomposed graphemes are rendered the way they are.

I'm closing this in favour of #1295 as it's basically what would take to resolve this.