[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