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

[Richmond]

In 1996 I bought a copy of Fontographer, having previously developed 
several bitmap fonts
for Macintosh with Fontastic (for Anglo-Saxon and Old Slavic). At that 
time (1996) it was possible
to use Fontographer to make fonts with about 4000 characters which one 
could access through Mac Keyboard layouts. As far as I know, although 
Unicode development started in 1986, there was
no question of Unicode compatibility (and I had not heard of Unicode).

Presumably (?) ALL that Macintosh system 7.5 was doing when it displayed 
characters outwith the ASCII set was what I need now?

I intend this weekend to start up my dedicated Mac OS 9 G3 iMac 
(previously running 10.4 but
now DELIBERATELY downgraded) and LC/RR 2.1 to play around with 
Fontographer 'Classic' and so on.

On 27/03/17 15:39, Mark Waddingham via use-livecode wrote:
> 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.

Possibly in the commercial world; but not for private individuals who do 
not have the money to
buy a new Mac laptop every 3-4 years.

Currently MacBook Air laptops are running at 1200 Euros, and 
contemporary iMacs at 2300 Euros
here in Bulgaria.

One of the things I love about Linux is that, for instance, I can run 
the "latest and greatest" on
my dual core DELL OPTIPLEX 2006 with absolutely not problems at all.

Admittedly, I am planning a "dirty weekend" to try the interesting 
procedure I have been studying on and off for the last month to upgrade 
a reserve polycarbonate iMac (5 in the cupboard) from 10.7.5 to
10.11; but whether that will actually come off is quite another 
question. How long one can
"cheat on the cheese" is an interesting question.

> 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).

I'm glad you find it unusable: I have a G5 iMac (connects to the 
Internet using TenFourFox) running
dual-boot 10.4 and 10.5 that is stuffed with lots of PPC software that I 
bought when I had more money for that sort of thing than I have now: I 
would be lost without the availability of Appleworks and
Bryce.

There are large groups of people with support networks who continue to 
work very successfully with
"outdated" Macintoshes.

>
> 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.
>