Hi Eric,
I recently played around with FreeType and ended up with this: https://github.com/tom95/sqfreetypefont It was developed for Linux and may work on Mac. The version of FreeType that you can get for Windows is, however, not compatible it appears.
Note that if the font you're using also makes use of ligatures this may still not help you, as a library like HarfBuzz is required for the shaping process. The lookup is also optimized for characters in the ASCII range and otherwise uses a Dictionary, so it may be worth changing this if rendering turns out to be slow for large bodies of text outside the ASCII range.
If you do try out the FreeTypeFont and run into any problems, I'm happy to assist via the Github issues of the project.
Best, Tom ________________________________________ From: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of Yoshiki Ohshima Yoshiki.Ohshima@acm.org Sent: Tuesday, August 4, 2020 11:24:08 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] TrueTypeFont and Unicode Characters
On Tue, Aug 4, 2020 at 1:49 PM Eric Gade <eric.gade@gmail.commailto:eric.gade@gmail.com> wrote: Hello all,
I wanted to revisit this issue as I'm working on it again. Back in April, Tobias mentioned the following:
I'm not sure we are actually loading all glyphs. Also note, that nothing in the font (like substitiution tables) are actually supported :/ sorry.
It appears that the particular ancient fonts that I'm usinghttps://www.hethport.uni-wuerzburg.de/cuneifont/ -- and other ancient fonts whose codepoints are now part of the Unicode standard -- make use of substitution in order to access points beyond 65535 (a full unsigned 16 bits). I know this to be true for my particular Akkadian fonts because if I dig into the code I am able to render the glyphs that TTFontReader has parsed out of the file, but only if I modify the renderGlyph:height:fgColor:bgColor:depth: message to look in the Font description's table of glyphs (rather than the codepoint sparsetable, which is 65535 entries long and has no glyphs at all in it).
Is there some deep reason not to support GSUB (substitution), aside from the complexity of ligatures? Right now if a TTF file has a GSUB entry it's not even being parsed out by TTFontReader. I'm really bumping around in the dark here, but I might be able to come up with something that at least permits the use of straight 1 to 1 substitutions. Any thoughts or ideas?
I'm attaching a few screenshots that can give a better idea of what I've done just to get something to render properly. I created a modified version of renderGlyph: (etc, etc).
It looks very cool!
The major reason is historical; using TrueType for rendering text was added with the idea that it follows the Smalltalk-80's basic text handling, e.g. the text width is the sum of individual character width, and none has non-positive advance width, etc., etc. One of the reasons is that it is not about just rendering, but if the user points within the text on screen, it'd have to figure out the index in the text.
The original design was that one can write a dedicated renderer and position-to-index feature for each language etc., but nobody (including me) spent much time to utilize it (except for Japanese language). Another run to support more complete text handling, either in Squeak native or perhaps in the manner of calling external libraries could be useful.
-- -- Yoshiki