John Hudson

In Aldhabi, and most other cascading styles, cursive attachment connections are going to be necessary for basically all joining glyphs, because all involve arbitrary movements in the y-direction (vertical offsets from the baseline) determined by context of the whole letter group. So only the final glyph in a letter group is sitting at its' default height, and all the others use cursive attachment positioning to chain together.

200,000? Each right-joining glyph requires a cursive attachment point to be defined on the right side, to which left-joining glyphs attach. The left-joining glyphs are all designed so that the cursive attachment on that size is the 0,0 origin point of the glyph. This means that one only needs to define the right-side attachment points. These are manually defined, but it doesn't take very long. I use a script that places a key component (generic-left joining glyph) at the advance width (right side) of each right-joining glyph, and then I just need to move it up so that the connecting strokes align nicely. Then I have a script that writes a VOLT GPOS cursive attachment lookup based on those positions. [We developed this workflow long before tools like Glyphs made it fairly easy to create Arabic fonts without recourse to VOLT, but I still like my old tools that have served me so well for so many years.]

The macron sign on the italic г in both Serbian and Macedonian is an oddity. The macron signs on the italic п and т make sense, because they distinguish the letters from the otherwise identical и and ш, but there is no letter in either modern orthography that could be confused with either shape of italic г. So why the macron? I am guessing that it is an artefact of cursive writing in which the single stem of the italic г could be confused with part of another letter, so is marked in this way to distinguish it from connected stems on either side. That being the case, I can see how the acute accent in ѓ would serve the same function by itself, without the macron, so I revise my suggestion above: italic ѓ doesn't need the macron.

Regarding nastaliq OpenType Fonts (as distinct from formats that are limited to particular software), I think the Noto Nastaliq Urdu is one of the best, in terms of going to considerable lengths to handle dot interaction within the clumsy mechanism of OpenType contextual GPOS (but also cheating a bit, by using smaller dots than are conventional in Urdu style of nastaliq). But there are still many issues in the interaction of spacing and mark positioning, and the deep problem is that OpenType Layout was not designed to be able to handle cascading styles of Arabic (I have this acknowledgement directly from the man who invented OpenType Layout).

For more information on the Aldhabi project, including illustration of the relatively small glyph set and some of the GPOS issues referred to above, see the slides from my 2012 ISType presentation: Adventures on the way to curls. At the time of the project, we didn't realise just how unsuited to what we were trying to do was the OpenType GPOS mechanism. The result is that the font is really only useful for headlines and other short pieces of display typography, and preferably in environments where the user can manually adjust spacing between lettergroups.

For a more general discussion of the issues around spacing and mark interaction, see my TypeCon 2014 presentation text and illustrations: Problems of adjacency.

My two deni worth:

I don't think it makes sense to have the typical Russian etc. cursive form of г with acute in Macedonian typography if the localised form is used for г without acute. As far as I know, the information provided in the Noto GitHub link that Michel posted above is reliable. The 'locl' feature substitutions for Macedonian should be extended to cover ѓ.

I'll be making this revision to the Brill fonts in the next update.

I don't have information indicating that ѓ is used in any alphabet other than Macedonian; however, I would be wary of making the localised italic form of this glyph the default, just in case it does show up anywhere else. Also, in case of failure of the 'locl' feature, it wouldn't be good to end up with Macedonian ѓ and Russian г — when failing, better to fail consistently.

Hrant,


Not any more. The environments that ignore hints to advance widths are too many and too pervasive. We lost that ability around the time that sub-pixel rendering with sub-pixel positioning became the dominant model.

______


With regard to the design of Spectral, what I'm mostly struck by is that it seems a nice, traditional book face, in terms of its proportions and style. That strikes me as an odd choice in something that is ostensibly designed for online document use. Some of the illustrations of it in use remind me of pre-Calibri/Cambria MS Office documents, and can't help seeming old-fashioned as a result.

[Disclosure: I suggested to Dave Crossland a few years ago developing a suite of fonts for Google Documents, which would have included both serif and sans, as well as a condensed face especially for spreadsheets. Would still like to do it.]