<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">Hi all --<div class="mb_sig"></div><div><br></div><div>We all know that the path to a clean multilingual Squeak based on Unicode is still bumpy. The concept of #leadingChar was an interesting trade-off to efficiently extend pre-rendered StrikeFont's with selected Unicode glyphs. See StrikeFontSet and #DefaultMultiStyle. For example, #installFonts for a JapaneseEnvironment is still functional: http://metatoys.org/pub/FontJapaneseEnvironment.sar</div><div><br></div><div>Anyway. #fallbackFont in StrikeFont (and TTCFont) can do (almost) the same trick. Without having to modify the Unicode code points with a #leadingChar. That is, the original intent to circumvent Unicode's Han unification might still be preserved by configuring different fallback fonts and/or text styles per use case (e.g., tool, text field, ...).</div><div><br></div><div>As a first step, I propose to stop file-ing out those leadingChar-runs as ]lang[ in the chunk format. Even with the current implementation of leadingChar, it makes no sense to preserve them outside the .image. For example, reading code from a .changes, .sources, .st, or .cs file might preserve the leadingChar's -- however -- working with the respective code fragments (e.g., cut/copy/paste) will immediately remove that "mask on characters" anyway if the system has a different leadingChar (or 0 for Latin1/Unicode). I cannot quite grasp the original intention of preserving those in chunk format. Maybe it was performance.</div><div><br></div><div>So ... any more thoughts on this? Maybe a plausible explanation on why ]lang[ exists in the first place given that all converters sending #leadingChar:code: seem to attach that on-the-fly anyway?</div><div><br></div><div>Best,</div><div>Marcel</div></div>