In a trunk image I get a char value 8217 - which is 16r2019, so correct - but it renders as a ?. So what we’re almost certainly seeing is a failure of the rendering process to find a font glyph with the relevant characters included. Which, given the large number of chars needed doesn’t surprise me a lot. The rendering does its little dance, finds that there is no glyph in the StrikeFont, delegates to the backup font (a Fixed FaceFont in the typical case) which has a little think and uses #displayErrorOn:length:at:kern:baselineY: to display the ‘substitutionCharacter’ which is ascii 63, or ‘?’.

The only way you’re likely to get the glyph you want would be to use Pango rendering via the UnicodePlugin (I think!). I know that can work because it’s what I used for nice fonts on the Pi for NuScratch, but whether it actually works or is even generated by default for other platforms I can’t say. The NuScratch code is all on SqueakSource if you want to dig into it to find usages of UnicodePlugin etc.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Homeopathy: Logic diluted, to make it stronger....