`draw-text` with `combine?` = `#t` missplaces diacritics. about draw HOT 6 OPEN

I'm running macOS 10.14.13, running a Racket head from a few days ago.

from draw.

This is not a regression from 7.5.
The exact UTF-8 bytestring I'm using for is "p̂" is #"p\314\202".

from draw.

Wikipedia suggests that 10.14.6 is the latest version of 10.14: https://en.wikipedia.org/wiki/MacOS_Mojave

from draw.

Is this related to "Unicode Acents in DrRacket" racket/drracket#46 ?

from draw.

It might be. From what I can tell drracket always uses combine as #f (judging by grepping the framework and drracket codebase)

An interesting note some fonts have special liggatures for diacritics, and that effect the behavior here. For example Futura has a diacritic for  but not p̂. The code:

(scale
 (vl-append
  (text "pp̂" (cons 'combine "Futura"))
  (text "pp̂" (cons 'no-combine "Futura"))
  (text "pÂ" (cons 'combine "Futura"))
  (text "pÂ" (cons 'no-combine "Futura")))
 3)

Renders

Which is to say, this only goes wrong if there is no ligature for the combined glyph.

But more bizzarly, if I switch to inconsolata, which has the same ligature set for this diacritic I get:

(scale
 (vl-append
  (text "pp̂" (cons 'combine "Inconsolata"))
  (text "pp̂" (cons 'no-combine "Inconsolata"))
  (text "pÂ" (cons 'combine "Inconsolata"))
  (text "pÂ" (cons 'no-combine "Inconsolata")))
 3)

Which is to say it draws the completely wrong character!

from draw.

this issue might be related to this pango bug (https://bugzilla.gnome.org/show_bug.cgi?id=584160)?

Specifically this comment https://bugzilla.gnome.org/show_bug.cgi?id=584160#c75 makes me think so.

from draw.