On Tue, Aug 4, 2020 at 1:49 PM Eric Gade <eric.gade at 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 using
> <https://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200804/52a5563b/attachment.html>