My point has been grapheme clustering doesn't matter as a useful length on its own, especially not for display length. The technical specifics/technical correct

My point has been grapheme clustering doesn't matter as a useful length on its own, especially not for display length. The technical specifics/technical corrections are getting into weeds that are orthogonal to point of the discussion in the first place. > I’m puzzled about the assertion of EBCDIC having Latin ligatures because I never encountered them in my IBM mainframe days and a casual search didn’t turn any up. The only 8-bit encoding that I was aware of that included any ligatures was Mac extended ASCII which included fi and fl (well, putting aside TeX’s 7-bit encoding which was only used by TeX and because of its using x20 to hold the acute accent was unusable by other applications which expected a blank character in that spot). EBCDIC had multiple "code pages" to handle various international encodings. (DOS and Windows inherited the "code page" concept from IBM mainframes.) Of the code pages EBCDIC supported in the mainframe era, many were "Publishing" code pages intended for "pretty printing" text to printers that supported presumably and primarily bitmap fonts. A low ID example of such is IBM Code Page (CCSID) 361: https://web.archive.org/web/20130121103957/http://www-03.ibm.com/systems/resources/systems_i_software_globalization_pdf_cp00361z.pdf https://web.archive.org/web/20130121103957/http://www-03.ibm... You can see that code page includes fi, fl, ff, ffi, ij, among others even less common in English text. Most but not all of the IBM Code Pages were a part of the earliest Unicode standards encoding efforts.