Hi

On 30.04.2020, at 13:49, Eric Gade eric.gade@gmail.com wrote:

Thanks Marcel.

I have used the specified Font Importer tool now, but am still having the same issue.

I'm not sure we are actually loading all glyphs. Also note, that nothing in the font (like substitiution tables) are actually supported :/ sorry.

Best regards -Tobias

On Thu, Apr 30, 2020 at 3:43 AM Marcel Taeumel marcel.taeumel@hpi.de wrote: Hi Eric!

...

I have "imported" this font using the FileList tool and it does appear as a TextStyle

Please use the Font Importer to import such fonts. You can find it in the Tools menu.

Best, Marcel

...

Am 30.04.2020 04:22:12 schrieb Eric Gade eric.gade@gmail.com:

Hello,

I am trying to load a particular TrueTypeFont that represents the Cuneiform signs in the Cuneiform Unicode block. You can find some information on this page.

Specifically, I'm attempting to work with the Neo-Assyrian font on that page ('Assurbanipal.ttf' in the zip file). I have also tried the Old Babylonian fonts with similar results.

I have "imported" this font using the FileList tool and it does appear as a TextStyle. However, if I attempt to run:

m := TextMorph new
beAllFont: ((TextStyle named: 'Assurbanipal') fontOfSize: 36);
backgroundColor: Color white.

signString := (Unicode value: 16r12038) asString.
m contents: signString.

m openInHand.

I get a TextMorph that appears blank. Either I am doing something incorrectly or the system cannot render the glyph at that code point (which should be the sign "AŠ"). Any ideas?

Eric

If you have a very well defined use case, you might be able to get away

with accessing glyphs by their index in the font directly. For this, you could inspect what ttcDescription returns and see if its glyphs field contains the ligatures you're looking for.

Thanks Tom. I don't know much at all about Fonts in any deep way, so this is a good start. I'll let you know if I have any success

On Thu, Apr 30, 2020 at 2:22 PM Beckmann, Tom < Tom.Beckmann@student.hpi.uni-potsdam.de> wrote:

Hey Eric,

I just tried with a Devanagari font, and this was able to return a form for me:

((TextStyle named: #NotoSansDevanagari) fontOfSize: 24) ttcDescription renderGlyph: 2327 height: 30 fgColor: Color white bgColor: Color black depth: 32

where 2327 is the unicode codepoint. Of course, as Tobi said, we do not support shaping (so no ligatures). If you have a very well defined use case, you might be able to get away with accessing glyphs by their index in the font directly. For this, you could inspect what ttcDescription returns and see if its glyphs field contains the ligatures you're looking for.

Best, Tom ________________________________________ From: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of Tobias Pape Das.Linux@gmx.de Sent: Thursday, April 30, 2020 1:58:12 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] TrueTypeFont and Unicode Characters

Hi

...

On 30.04.2020, at 13:49, Eric Gade eric.gade@gmail.com wrote:

Thanks Marcel.

I have used the specified Font Importer tool now, but am still having

the same issue.

I'm not sure we are actually loading all glyphs. Also note, that nothing in the font (like substitiution tables) are actually supported :/ sorry.

Best regards -Tobias

...

On Thu, Apr 30, 2020 at 3:43 AM Marcel Taeumel marcel.taeumel@hpi.de

wrote:

...

Hi Eric!

...

I have "imported" this font using the FileList tool and it does appear

as a TextStyle

...

Please use the Font Importer to import such fonts. You can find it in

the Tools menu.

...

Best, Marcel

...

Am 30.04.2020 04:22:12 schrieb Eric Gade eric.gade@gmail.com:

Hello,

I am trying to load a particular TrueTypeFont that represents the

Cuneiform signs in the Cuneiform Unicode block.

...

...

You can find some information on this page.

Specifically, I'm attempting to work with the Neo-Assyrian font on that

page ('Assurbanipal.ttf' in the zip file). I have also tried the Old Babylonian fonts with similar results.

...

...

I have "imported" this font using the FileList tool and it does appear

as a TextStyle. However, if I attempt to run:

...

...

m := TextMorph new
beAllFont: ((TextStyle named: 'Assurbanipal') fontOfSize: 36);
backgroundColor: Color white.

signString := (Unicode value: 16r12038) asString.
m contents: signString.

m openInHand.

I get a TextMorph that appears blank. Either I am doing something

incorrectly or the system cannot render the glyph at that code point (which should be the sign "AŠ"). Any ideas?

...

...

-- Eric

On Tue, Aug 4, 2020 at 1:49 PM Eric Gade 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 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.

On Wed, Aug 5, 2020 at 8:11 AM Beckmann, Tom < Tom.Beckmann@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@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!