Eh, I have to admit I’m tiring of this discussion, and it’s off-topic anyway. If I’m wrong, I’m wrong. shrug
No problem, dear furrykef. We’ll never know, then, if you’re mistaken or am I and about what exactly. It probably doesn’t matter in the least, which is always good.
Licet, furrykef care. Nunquàm tunc monstrabitur utrum ego errem an tu, et si quis erravisset, in quâ re id evenisset. Nec fortè istud ulli saltem referet, quod semper placet.
When creating a font, you can achieve ligatures in two ways:
-
You can encode the ligature, i.e. assign it to a codepoint. There are codepoints in Unicode for common ligatures (such as fi, fl, etc.), but this is due to backwards compatibility with older encodings. Ligatures which have no pre-defined codepoints can be placed in the Private Use Area. If, for example, you as a font designer want an “fb” ligature, you will place it in the PUA; when the user wants to access it, they will have to change each instance of the two characters “f”+“b” into this ligature character.
-
The more modern way is to store the ligature in the font as an unencoded glyph. As a user you usually can’t access this glyph directly, since it is unencoded. Instead, by means of OpenType features for example, this ligature glyph may be substituted for the base characters, if the user requests that this feature be enabled. The font may, for example, contain an “fb” glyph, which is not encoded. The user can write the two characters “f” + “b” and enable an OT feature which makes this combination show up as the “fb” ligature. However, the characters remain “f” + “b” for the purpose of searching, spell-checking, etc.
(Of course, you can let the ligature both be encoded in the PUA, and be accessible through OpenType features. This way, the users who can’t use OpenType can still access the ligature, while users with OpenType support can enjoy the automatic substitution.)
Well, I understand that because I have had to design fonts for manuscript abbreviations and ligatures while allowing for data transfer to searchable databases and, for historical-scholarship purposes in circumstances where, to the original writer, their use is optional, you don’t have any reason to discriminate between ae/oe ligatures and other ligatures other than to say “either all or none”, which is my background for interpreting the Unicode standard guideline in that way: æ et œ can be understood to be included among ligatures generally and to be discouraged in modern documents. I just was hoping for the extra clause: “unless there’s a very good reason for including them”, because there can be reasons (for example, “this ligature is here a distinct letter character”). But the argument can easily be made that it’s unnecessary to write with ligatures in latin!
Id intellego quià me typos fingere habui qui sigla ligaturasque continent et qui plicas ad ordinatrum datorum investigabile transferri permittent. En contextus meus quoàd cur sic illum directivum Unicode interpretem: benè possible et rectum est id directivum et æ et œ in ligaturas includere. Hoc autem exspectaveram: “omnibus ligaturis plerumquè excludendum est nisi exstat bona ratio cur cuidam ligaturae includendum sit”, quià rationes nonnunquàm exstare possunt (exempli gratiâ, hîc ista ligatura loco litterae distinctae scribitur"). At non necessae sunt ligaturae in latinâ linguâ scribendâ, ut benè possibile est arguere.