Wogb3 j3k3: Pre-Unicode substitutions for extended characters live on
charupdate at orange.fr
Sun Oct 16 15:59:01 CDT 2016
On Sun, 16 Oct 2016 14:25:34 -0400, Mark E. Shoulson wrote:
> I have the rare good fortune to see John Cowan on a near-daily basis
> (except this month, with all the Jewish Holidays); I'll forward your
> message on.
On Sun, 16 Oct 2016 12:25:27 -0600, Doug Ewell wrote:
> Marcel Schneider wrote:
> > I guess that Moby Latin is now being reengineered, see:
> > http://www.smo.uhi.ac.uk/gaidhlig/sracan/Whacking/MobyLatinKeyboard.html#vietnamese
> That's Caoimhín Ó Donnaíle's mirror of the readme file for Whacking
> Latin, the UK version of Moby Latin. I don't see anything about
> re-engineering it, but maybe I missed something.
Right, it isnʼt talking about re-engineering. “Reconsidered” is not re-engineered.
Though I still guess that the author is doing much more now.
I remembered this sentence from having read it when youʼd shared Moby Latin here.
> > Obviously the Microsoft program used to generate will be
> > KbdUTool, the Microsoft Keyboard Table Generation Tool (Unicode).
> Yes, via MSKLC.
Then there would be nothing to be reconsidered. Iʼve in mind using the -s flag
to generate the C sources, then setting these read-only once edited.
> > Iʼm so glad that now what many people were waiting for,
> > serial dead keys, is going to become a common feature
> > on Windows.
> I would be glad to see that too, but where do you see that on the
> referenced page? All I see is John's original text about working around
> the MSKLC limitation.
By experiencing the current use of KbdUTool (via a script in batch that
Iʼve written with a comfortable UI for end-users), I feel myself in a
position to extrapolate this from John Cowanʼs wording of the disclaimer:
«These assignments are considered temporary, and will be
reconsidered when the Microsoft program used to generate
Moby Latin can handle serial dead keys.»
It doesnʼt say what program. Just “the Microsoft program used.”
If today, this variable is set to 'KbdUTool' instead of 'MSKLC',
then suddenly the Microsoft program “can handle serial dead keys.”
> If you want to work directly with KbdUTool to get serial dead keys,
> bypassing MSKLC, here is Kaplan's post from 2011 on how to do this. Be
> sure to read all the warnings twice:
Thank you for this link. This is what I should refer to when citing the feature.
There is the test issue, that seems rather awesome. Does a working layout
driver prove that there is no known bug? Iʼm actually using sucb a working
layout driver. E.g. pressing the Acute dead key twice, then ‘o’, inserts ‘ő’.
Iʼd suggest not to do this in the .klc file, too complicated through its
apparent simplicity because the diacritic doesnʼt show up on each line.
More information about the Unicode