[KS] macOS ("Sierra") - another UPDATE
Frank Hoffmann
hoffmann at koreanstudies.com
Sat Sep 3 01:51:44 EDT 2016
One more update:
It first comes always differently and secondly, never as you think.
(German saying)
It's quite interesting, actually! As compared to the early days, maybe
up to the early 1990s, programming is now somewhat like putting
together Ikea furniture. While you may say that's Swedish I am rather
convinced that this must be a misunderstanding and that it's true soul
is of modern American origin: paint-by-number and live-by-number kits
in white, black, pink, and oak. The gas station here, the shopping mall
and outlet stores there ...
Putting together any sort of application, no matter for what operating
system, no matter for what device (self-imploding galaxies from
Samsung, macOS, Win, or Linux desktops, iOS phones, etc.), you now
follow exact, Ikea-style guidelines telling you where the gas station
needs to go (where the "About" and "Save" buttons have to be located,
etc. -- as very simple example). Because of many available toolboxes
the whole process is pretty easy. You work with an ever growing number
of "libraries" and ore-fabricated resources that provide you with a
full set of routines and sub-routines and what one may already call
mini applications that can be integrated. Say, you want the ability to
move or push an object, e.g. an image or a table, from one of your
app's documents to another document, then there is a routine you can
just copy from one of the libraries for that -- you do not need to code
this function line by line. Same applies for entire sets of Ikea-style
visuals, from the rotating beach ball or a set of national flags for
language selectors. If we wonder how a private company can within a few
years come up offering moon rockets or how a nation like North Korea,
otherwise not exactly leading in technological development, can
construct nuclear facilities, intermediate-range ballistic missiles and
other high-tech smarties, then I think a good part of the answer
relates to these Ikea-style toolboxes. Nobody needs to start from
scratch. It's of course also the main reason so many former "third
world" countries were able to climb up the ladder so fast.
So, now, if we look at the failure with Korean language in MS Word 2011
and 2016, Libre Office, Outlook, Google Chrome, and others under the
forthcoming macOS -- and we understand this as pre-packages resources
and libraries that are being accessed by applications running on that
OS, then we can nail it down easier. My first take on that (first
posting) was somewhat off. Seeing that a rather simple word processor
application like "Bean" (http://www.bean-osx.com), last updated in
2013, works perfectly fine with the brand new macOS and its new coding
for the input system got me there: basically, the OS already provides
in its the library the full Han'gŭl to Hanja input functionality. So,
any program just needs to 'call' that with very simple sub-routine --
it does not need to be part f its own code. MS Word however, both the
2011 and the 2016 version, and others, seem to PARTIALLY have their own
input systems. They did not follow the Ikea assembling guide -- just
partially so. To nail it down further, I am not 100% sure, but I think
it relates to the following change explained here --
https://developer.apple.com/swift/blog/ -- about 1/4th down that page
-- the change regarding "decomposed or precomposed character sequences"
... so, ㅎ + ㅗ (= decomposed) vs. 호 (= precomposed). But that's
still not the meaning. TECHNICALLY a Unicode (also also older) font
includes the Korean alphabet in single letters (ㅎ, ㅗ, ...) AND in all
possible components (호, etc.). "Precomposed" means here that the
computer program or the OS does access the "precomposed" ideogram 호
when you type "g" and then "h" on your keyboard. It does not access the
"decomposed" elements ㅎ and ㅗ. (This is confusing if you look at it
in a NON-technical way!)
Q U O T E from the Mac website -- that relates to "Xcode" version 8 and
"Swift" v.3, the tools that the new macOS itself is being constructed
with (https://developer.apple.com/swift/blog/):
------------
Consider the Korean writing system, which consists of 24 letters, or
Jamo, representing individual consonants and vowels. When written out
these letters are combined into characters for each syllable. For
example, the character “가” ([ga]) is composed of the letters “ᄀ”
([g]) and “ᅡ” [a]. In Swift, strings are considered equal regardless
of whether they are constructed from decomposed or precomposed
character sequences:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.jpg
Type: image/jpeg
Size: 16430 bytes
Desc: not available
URL: <http://koreanstudies.com/pipermail/koreanstudies_koreanstudies.com/attachments/20160902/a2b070bc/attachment.jpg>
-------------- next part --------------
------------
See -- what these three lines of code declare is that 'macOS' (Sierra)
now treads "decomposed" and "precomposed" elements (ㅎ + ㅗ vs. 호, or
in this example ㄱ + ㅏ vs. 가) exactly the same. The numbers you see
there, u1100, u1161, and uAC00 are the Unicode numbers for ㄱ, ㅏ, and
가 resepectively. If I understand that right .... that part is encoded
and I cannot directly check that part of the code ... if I understand
that right, then MS Word still treads these differently. As a result,
when you write (in a MS Wrd text) 호 or 가 and then hit Option + ENTER,
the program just doubles your han'gŭl syllable instead of calling the
routine getting you the pop-up window with the selection of Hanja to
choose from. That is simply because the new macOS operating system
'tells' the programm (MS Word, in this case) that ㄱ plus ㅏ is the
same as 가. -- Because the program (MS Word) only starts its Hanja
input call (the routine) when seeing the *component* ㄱ+ㅏ is being
entered, it never gets there ... because it is being told that 가 (as
direct entry, like a copy/paste routine) is the exact same as entering
it as a component (ㄱ+ㅏ). So, the new macOS cuts that fuction one step
before it is going to happen.
Basically, Microsoft's MS Word and many other programs would need to
either call the routine directly in the OS, as in the case of simple
programs like "Bean" -- or they would need to apply the new rules to
whatever library set they have integrated in their own core application
and the supporting resources. I looked at the program by opening the
package (you can do so with a simple right-click), and that is nothing
that can be edited -- which was not to be expected in any case.
Best,
Frank
--------------------------------------
Frank Hoffmann
http://koreanstudies.com
More information about the Koreanstudies
mailing list