> On Wed, Aug 5, 2020 at 8:11 AM Beckmann, Tom <
> Tom.Beckmann at student.hpi.uni-potsdam.de> wrote:
>
>> 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.
>>
>
This is excellent, thanks! I'm having an issue trying to install according
to the instructions, but I'll post that as an issue over on Github instead
of polluting this space.

On Tue, Aug 4, 2020 at 5:24 PM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
> wrote:
>
>>
>> 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.
>>
>
Thanks, Yoshiki. That all makes sense to me. I think the basic TTF stuff is
actually in pretty good shape (aside from ligatures).

The following is more an FYI in case anyone else stumbles on this issue.
After further investigation it appears that my diagnosis was incorrect: my
particular issue is not about GSUB or any additional fancy text-handling
tables. It turns out that the `cmap` table platform ID 0 (unicode), which
is one of the few that the current Squeak implementation handles, has been
updated in the time since the library was written. Specifically, Unicode
2.0 now specifies characters whose codepoints are 32-bit values (see the
Overview here
<https://docs.microsoft.com/en-us/typography/opentype/spec/cma>). There are
different encoding table sub-formats for these scenarios, as well as other
encoding strategies for dealing with points that fall outside the 16 bit
range. My particular font seems to be using Format 4
<https://docs.microsoft.com/en-us/typography/opentype/spec/cmap#format-4-segment-mapping-to-delta-values>.
If you click that link you'll see how complex it is. I can't even say I
understand what they are talking about there, and it would be complicated
to implement.

OpenType is complicated!



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200805/b0729625/attachment.html>