I was preparing the following feedback long before the obituary of Michael S. Kaplan.
I stay mourning. Since discussion restarted, am I allowed to send this today, instead of tomorrow? Initially it was planned for yesterday, the day when I found Doug Ewell’s and following messages, that brought me the bad news. I’m grateful for Erkki I. Kolehmainen’s advice to complete best effort prior to sending. My apologies for previous defaults. On Thu, 15 Oct 2015 20:22:08 -0400, Don Osborn wrote: > I was surprised to learn of continued reference to and presumably use of > 8-bit fonts modified two decades ago for the extended Latin alphabets of > Malian languages [...]> > See my recent blog post for a quick and by no means complete discussion > about this topic, which of course has to do with more than just the > fonts themselves: > http://niamey.blogspot.com/2015/10/the-secret-life-of-bambara-arial.html Here is another example of legacy font usage less than two years back: http://csprousers.org/forum/viewtopic.php?f=1&t=753 ❏ Legacy fonts offer at least one substantial advantage, which is already underscored in the comments on the cited blog post: They allow to use any habitual ASCII-oriented keyboard layout like French in Mali. Personally I feel with all the people who stay using the fonts issued by the «1990s […] joint project of the Malian Ministry of Education and the French Agence de Coopération Culturelle et Technique (ACCT […])», and I wouldnʼt neither throw away a proven worktool without being sure to get a better one. I suppose the cited people in any case didn't use the "clavier unifié français-bambara" that you linked to on another blog post: http://www.mali-pense.net/IMG/pdf/le-clavier_francais-bambara.pdf cited on: http://www.mali-pense.net/Ressources-pour-la-pratique-du.html cited on: http://niamey.blogspot.fr/2014/11/writing-bambara-right.html Indeed there is a big oopsie with keyboard layouts on Windows: we cannot associate applications and default keyboard layouts like we can associate file extensions and applications. So one working method not to be bothered with switching keyboard layouts is to have appropriate templates in the word processor with extra fonts instead of extra layouts. ❏ The glyph issue: To get «"Bambara Arial" to work on the internet», a simple macro replacing ù, %/Ù, q, Q, x, X, v, V with ɔ, Ɔ, ɛ, Ɛ, ɲ, Ɲ, ŋ, Ŋ isnʼt enough because though Arial, it wonʼt be «true Bambara» any more given the inconsistency of all fonts I could view that use the “n” form for uppercase eng, like Arial and Times do, while sticking with the “N” form for uppercase palatal n. I believe itʼs not just «more to it» but even the main reason, despite of opposite opinion in comments. I couldnʼt gather any suitable font, but book-printers must have them, and possibly both shapes in the same font. Such fonts seem to be really confidential. In a bilingual Bambara-French book from France (1996), the typeface clearly shows that “n”-shaped uppercase ɲ has been emulated by using oversize lowercase. Ported to HTML, this workaround results in replacing all ‘Ɲ’ by lowercase in a [font-size: 135%; line-height: 75%; font-weight: lighter;] span, though it stays looking semi-bold when less than 400 is unavailable. That can make aware that it doesnʼt render in plain text. And it works best with sans-serif fonts. I really donʼt know if this has at least some resemblance to Bambara Arial, and I do wish to be able to check. I note, too, that such a construct is not Unicode conformant. It would be desirable to overcome that system of special fonts, workarounds, and limited support. I donʼt know if really some communities prefer the “N” form for uppercase palatal n, or even for eng, or both. Was there a problem at the time when actual fonts were created? Does anybody know a solution? Iʼm likely to believe that this would eventually be language tagging and use of modern rendering engines along with up-to-date fonts providing both glyphs. However, in my opinion, correct display of so widely spoken and written a language as Bamanankan, should not have to rely on sophisticated byways. ❏ About Unicode aware education: Iʼm not likely to share presumptions about lack of training in Mali more than in other countries, including European. Keyboard layout documentation from Europe last updated after fifteen years of Unicode still targets non-conformant rendering engines (where precomposed and decomposed characters display differently) and doesnʼt mind using canonical decomposition afterwards to streamline the input (actually, for Bambara, by using the French ‘à’, ‘è’, ‘ù’, and ‘é’ keys). Well, the existence of decomposition in text processing was about the first things Unicode taught me, as I was too ignorant to directly point the browser to TUS and UAXes to learn about—while already bothering about creating keyboard layouts... That turns out not to be a single case. And with the one-laptop-per-child program, Malian and other African technicians will be making far better keyboards than Europeans did. Iʼd quoted some parts from the following forum page of 2006, but removed them to shorten. I believe it says a lot about the topic. Interested subscribers are welcome to look it up on line: Ibibio, Efik, Anaang and ICT (fonts, keyboards, applications) http://www.quicktopic.com/37/H/q8r5VVqGF5Q — — — Yet another solution is a universal Latin backward compatible layout on French keyboard optimized for Bambara and including NʼKo: 1 - Universal Latin is rather intuitive and backwards compatible with a Compose key plus five classic dead keys (on three physical keys); optimization is performed by (a) filling up the keys on third and fourth level, and (b) filling up the circumflex group (and other groups), with the additional characters, given that circumflex is already the base shift state dead key on French layout, and Q, V, X donʼt exist with circumflex. Thatʼs overcoming definitely the traditional but unnecessary limitation of dead keys to one diacritic instead of considering that every dead key gives access to a natural group (as opposed to the artificial groups defined in the global keyboard standard), like the US International keyboard had started doing for ‘ç’. 2 - NʼKo being a caseless script, its 59 characters can be placed into the Kana shift states. The standard Kana toggle in Windows drivers requires a whole key (e.g. above Tab, suitable for French layout), while Keyman allows to add a supplemental toggle in a way that doesnʼt—invoked for example by Ctrl+CapsLock. That toggle will allow to get NʼKo integrated. 3 - Universal Latin makes sense also because it covers *all* characters listed on this page: http://www.bisharat.net/A12N/charsum.html as well as all the circled (plain text) digits and letters: ①➁⓷❹➎Ⓐⓩ, and in its final stage a lot of symbols and pictographs. Good luck, Marcel
