A feature unretained in digitized Didots (as far as I have seen) that I intend to retain in mine is the peculiar italic
/v, which consistently has an initial and medial-final form across manuscripts. I suspect a similar treatment may have been given to
/w, but I am still parsing through the few manuscripts that have /w to find out:
One sees either one or the other used in the modern designs (cf. HTF Didot and LT Didot; also
this undated file).
Having read through Arabicshaping.txt and articles on Unicode compatibility characters and on Unicode equivalence, I see that it is not so simple as designing a “/v.medi.” Would one go about this by perhaps designing the medial-final variant of the /v and that transforms into the initial /v when paired with specific characters such as a /space. I can’t help but think there’s a better answer than that.
Comments
But I think your stab at the method is probably correct.
It is written for Glyphs but the Feature code is the same.
For Arabic, the shaping engine can determine whether a given character should be rendered as a connected form or not. For latin-based scripts, on the other hand, which characters do or do not connect is font-specific, and thus can't be handled by the shaping engine. I'm assuming this is why connections in English are left to 'calt' rather than to the positional features defined for some Semitic languages.
I've also encountered a few latin fonts which use 'init' and 'fina' to implement decorative initial or final forms which completely ignore questions of punctuation. Some final forms would be acceptable with a following question or exclamation mark, others not so much. An 'n' with a swashy thing on the right might be fine with a following quotation mark; a 't' with an elongated bar not so much...
Sorry about that.
https://en.wikipedia.org/wiki/Complex_text_layout
It is the other way around, almost all OpenType layout engines only supported these features for scripts that has Arabic-like shaping behavior…
No, it wasn't. Greek encodes the final sigma as a separate character, and it is input from the keyboard as such. There has never been any need to try to handle final sigma display as a glyph substitution.
The joining behaviour OTL features rely on shaping engine analysis of character strings and use rule-based application of the features to specific characters based on their adjacent characters. Those rules have to be defined somewhere, and the Unicode ArabicShaping.txt document is the only place where they are defined in a standard resource. There is no standard for joining behaviour for the Latin script: so it is excluded from application of these features on that basis.
[There is one grandfathered legacy implementation of one of these features — init — for a script outside the ArabicShaping.txt standard, and that is the initial form of vowel signs ে and ৈ in Bengali/Assamese, which relies on shaping engine analysis on the beng and bng2 layout models. Note that if this script were shaped using the Universal Shaping Engine (using the putative bng3 layout model) use of init would be excluded, since USE can only apply analysis as defined in ArabicShaping.txt. So the initial form of these Bengali vowel signs would need to be handled using contextual GSUB lookups, as is the case for word-position variants in Latin.]
The code:
@allLatin = [\A \B \C \D \a \b \c];
#etc etc everything necessary gets listed in the class
lookup caltLatinContextualAlternateslookup0 {
lookupflag 0;
ignore sub @allLatin \v';
sub \v' by \v.alt;
sub \backslash' \v' \backslash' by \v;
} caltLatinContextualAlternateslookup0;
feature calt {
lookup caltLatinContextualAlternateslookup0;
} calt;