<div dir="ltr"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_attr">On Wed, Aug 5, 2020 at 8:11 AM Beckmann, Tom <<a href="mailto:Tom.Beckmann@student.hpi.uni-potsdam.de">Tom.Beckmann@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Eric,<br>
<br>
I recently played around with FreeType and ended up with this: <a href="https://github.com/tom95/sqfreetypefont" rel="noreferrer" target="_blank">https://github.com/tom95/sqfreetypefont</a><br>
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.<br></blockquote></blockquote><div><br></div><div>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.</div></div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="gmail_attr">On Tue, Aug 4, 2020 at 5:24 PM Yoshiki Ohshima <<a href="mailto:Yoshiki.Ohshima@acm.org">Yoshiki.Ohshima@acm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><br><div>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.</div><div><br></div><div>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.</div></div></div></blockquote></blockquote><div><br></div><div>Thanks, Yoshiki. That all makes sense to me. I think the basic TTF stuff is actually in pretty good shape (aside from ligatures). <br></div><div><br></div><div>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 <a href="https://docs.microsoft.com/en-us/typography/opentype/spec/cma">here</a>). 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 <a href="https://docs.microsoft.com/en-us/typography/opentype/spec/cmap#format-4-segment-mapping-to-delta-values">Format 4</a>. 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.</div><div><br></div><div>OpenType is complicated!<br></div></div></div><div class="gmail_quote"><div><br></div><div> </div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div></div>