Support "Traditional Arabic Windows 3.1 font page"

[khaledhosny]

(This comment is edited by Ebrahim) Currently it needs Uniscribe support as the client needs to use ScriptGetCMap() or so since the fonts don’t have an Arabic cmap subtable.

However these fonts are still rather popular among Arabic users and there are hundreds of them floating around the web and people often complain about them not working on HarfBuzz-using applications (for example libass/libass#292).

I don’t know if we can just do PUA shaping similar to Thai or if there is someway to identify these fonts like the Windows API do.

[behdad]

I like to do this, but don't think we'd have ANY way to detect these.

[dscorbett]

(Edited by Ebrahim: this comment is related to #992, ignore it for this issue)

It should be possible to detect them. ssee1256.fon declares its dfCharSet as 178 (Arabic), which corresponds to Windows-1256. The font doesn’t fully comply with Windows-1256 but it is similar. Compare with ssee1255.fon, which uses a modification of Windows-1255.

[behdad]

(Edited by Ebrahim: this comment is related to #992, ignore it for this issue)

Right. But we don't support .fon files. Client font-funcs should support them before we can shape anything, and they should synthesize the cmap.

I'm open to coming up with a way to implement .fon and Type 1 in HarfBuzz itself if it's not too intrusive and does not distract from OpenType stuff.

[ebraminio]

(Edited by Ebrahim: this comment is related to #992, ignore it for this issue)

Does the implementation have to be cross platform (and afterward support big endian machines also)? If so I guess we will have so fun with parsing EXE resources (as FON is just an alias, IIUC) and then FNT, writing a limited set of little endian int parsers. And do we need just to implement something equivalent to ScriptGetCMap or we need more? I mean are the other font rendering stack layers ready for it? It will be like my .dfont work but way cooler! (but I don't think if I can reach to it)

[ebraminio]

There is two fonts with the similar to "MS Sans Serif" name, one "MS Sans Serif" with "sserife.fon" file name which is ".fon" file and "Microsoft Sans Serif" with "micross.ttf" file name. Which one is fixed here and referred on here @jfkthame? The bitmap one or the sfnt one? "micross.ttf" is not getting passed on #986 check AFAICS, maybe I am checking a newer version and not the version used to be? And maybe this is a different bug and #991 is headed on a wrong direction?

[ebraminio]

Ok, I guess I am now more confident that we were talking about two separate issues, lets separate them, #992 for .fon support and this for "Traditional Arabic Windows 3.1 font page" support as @khaledhosny's finding here.

[ebraminio]

I've found just A LOT of them here

This is a survey of them, fonts.txt

Note the number of fonts HarfBuzz can't render.

Of them 468 ones are "Traditional Arabic Windows 3.1 font page", 13 ones are "Simplified Arabic Windows 3.1 font page" and 3 with 0xEE00 (unknown font page, "Phyllis ATT Italic.TTF", "LUCASIT.TTF" and "SIGNETRO.TTF")

[ebraminio]

Aha, now I see, as originally was stated by Khaled and David, this is about Windows-1256 and probably can use some of the things as f28b1c8 but fixing this completely is not limited to that. The interesting thing is OS2's font page list can be completed with fonts dfCharSet as was noted by David but even more interesting, we have found some of the dfCharSet values were not available on the link!

[ebraminio]

Or maybe not, 0xBA refers to Simplified Farsi Windows 3.1 font page on OS2 font pages list but to BALTIC_CHARSET on dfCharSet but at least I guess the fonts I found with 0xEE00 were referring to Windows-1250.