LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham]

On 2017-03-27 13:56, Richmond via use-livecode wrote:
> "UnicodeChecker is being developed using the Objective-C programming
> language with the standard macOS developer tools, i.e. Xcode and the
> Cocoa frameworks. The display of Unicode characters uses the default
> system facilities of macOS. So there is no special handling of newer
> Unicode characters: While Mac OS X 10.7.5 does not support the latest
> Unicode versions when it comes to the character properties (such as
> „General Category“, „Combining Class“, etc.) it will happily just
> display any character that is present in a font, even if the character
> was not actually defined in the very specific version of Unicode that
> this version of Mac OS X supports."

Well, yes - it is just displaying the glyph completely out of context.

> Now what is interesting is that LC 8.1.3 on Mac OS 10.7.5 will NOT
> display characters simply as
> characters, but tries to be too clever for its own good.

No - it is not being too clever. It is doing precisely what it should 
for the purposes of laying out text (and indeed what the CoreText engine 
on MacOS does - as that is what the engine uses). Pretty much everyone 
writing apps does not want to care about the (very complex) details of 
turning text into positioned glyphs, they just want a text string to be 
rendered how 'you would' expect, with regard to the codified rules which 
have been developed over a large number of years for typesetting 
language into a printed representation. Moreover, generally people want 
that done in a way which is 100% consistent with all other apps on the 
same OS (which is why using system services for such things is so 
important - Windows, for example, has a lot of behaviors built-in for 
dealing with CJK fonts which date back 1-2 decades, if an app doesn't 
support those then it won't operate in the same fashion).

> As I am the developer of a program that does "all the knitting"
> internally all I really would like is exactly
> what this chap describes above. The fact that LiveCode seems to be
> doing some of "the knitting" off
> its own bat and/or leveraging OS "knitting" is what is causing me 
> problems.

Quite - you have a special-case - you don't want to layout text, you 
(probably) just want to render glyphs which you specify.

> I have already run the latest builds of my Devawriter on Mac OS 10.12
> and Ubuntu 16.04
> without these problems.  However I have several clients who run their
> Macs on Mac OS 10.6.

Well, it is unlikely that anything will change with regards 10.6 with 
regards LiveCode. 8.1.x will be the last branch which will support 
anything less than 10.9.

To be fair, 10.6 is pretty much now a completely dead operating system 
for anything other than offline use. Critically, it does not and will 
never support some new SSL related transport modes, nor does it get 
Certificate Store updates. Basically, as time goes by the number of 
things a 10.6 machine will happily connect to *safely and securely* 
'over the internet' will diminish to probably zero. (I know this from 
experience - my laptop is still on 10.6 for various reasons and is just 
about unusable now as it can't be used to connect a variety of online 
services anymore - updating it to 10.11 or 10.12 is on my todo list).

In regards to your specific requirements, I had a thought on that last 
night. I think essentially what you want is a way to treat a sequence of 
codepoints in a field as a sequence of glyph indicies into the current 
font. So rather than treating the 0x1CF7 codepoint as a character, it 
would just be treated as a number to index into the glyph table of the 
(inherited) font set on its style. This could be done as a textStyle, 
although that would give you no control over positioning, the only thing 
it could do there is use the advance width / baseline in the glyph to 
position it sequentially.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps