Wrong glyph inserted with HarfBuzz renderer

[fpom]

I've reported issue #579 to polyglossia and got suggested that it might interest you as well. When using HarfBuzz render instead of Node, \symbol may select the wrong glyph. As a minimal example, we have:

% !TeX TS-program = lualatex
\documentclass{article}
\usepackage{fontspec}
\newfontfamily{\mdih}{Material Design Icons Desktop}[Renderer=HarfBuzz]
\newfontfamily{\mdin}{Material Design Icons Desktop}[Renderer=Node]
\begin{document}
	{\mdih\symbol{"F0A27}}{\mdin\symbol{"F0A27}}
\end{document}

Which yields:

where the correct glyph is on the right. It might be a problem related to font loading hence this report. The font used in the example above is available here.

[khaledhosny]

The right glyph is the glyph at U+F0A27 slot in this font, the left glyph is the glyph for U+F0A2E.

[zauguin]

As far as I can tell it's the other way around: The left (HarfBuzz) one is F0A27 (and therefore correct), while the right (Node) one is F0A2E.

That would be expected since the node mode does by design not support reliable selection of characters in the private use blocks. (see e.g. #185 (comment))

[khaledhosny]

That would be expected since the node mode does by design not support reliable selection of characters in the private use blocks. (see e.g. #185 (comment))

That is broken though, since private use means Unicode does not give it a meaning not that it is free for applications to reappropriate, PUA concept was borrowed from CJK encodings where it is often used for things like rare characters/personal names. https://www.unicode.org/faq/private_use.html

[jspitz]

As far as I can tell it's the other way around: The left (HarfBuzz) one is F0A27 (and therefore correct), while the right (Node) one is F0A2E.

You are right, as can be seen on the font's cheat sheet.

[callegar]

I think this is the same as bug 185

[zauguin]

Right, it's kind of the opposite (since it's about the HarfBuzz renderer not having issue 185, but in any case it's not really a separate issue