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.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
