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

[Mark Waddingham via use-livecode]

On 2017-03-29 22:26, Sannyasin Brahmanathaswami via use-livecode wrote:

One anomaly that appears to be generated by LC 9dp5 running on Sierra
10.12.3: Code point U803 maps in the Unicode standard to the Extended
Latin "H with dot underneath" character.


Just to check, I take it you mean 'h' followed by U803 (the latter is 
'combining underdot' so needs a preceding char to make sense).



for some bizarre reason, on my machine/system,  Livecode is mapping
this character to Lucida (I think… possibly Helvetica.)
So this is an issue with the LC engine…


Indeed, that is odd - and does put Richmond's initial issue slightly 
more under the spotlight particularly as I'm now looking at the issue on 
a 10.6 machine (still haven't had time to upgrade it...)


What I observe (in 8.1 - it happened to be the LiveCode version I had 
opened) is this:


Field's textFont set to Devawriter.

Field containing: 'h' U+803

Displays h-with-underdot glyph - not using Devawriter font.

Field containing: 'h' U+803 ' '

Displays h-with-underdot glyph - uses Devawriter font.

Revisiting the original problem with the 1CF5, 1CF6 and 1CF7 codepoints:

1CF5 on its own - square glyph
1CF5 ' ' - square glyph, then space
1CF5 'a' - VEDIC SIGN JIHVAMULIYA, square glyph

Similar story for 1CF6.

The 1CF7 codepoint always displays the 'undefined codepoint' glyph from 
the last resort font.


Using TextEdit then as long as Devawriter is set as the explicit font, 
1CF5 and 1CF6 seem happy enough to display regardless of chars before or 
after. 1CF7 does the same thing as LiveCode.


*However*, trying h,underdot in TextEdit I observe a worse behavior than 
in LiveCode - the h,underdot never displays in Devawriter font 
regardless of subsequent chars!


So:

  1) The behavior of 1CF7 seems to be because it is an 'unassigned' 
codepoint at this time - I'm not quite sure the exact rationale behind 
not just using the specified font's CMAP table to generate a glyph 
regardless but I suspect it might be to do with unassigned codepoints 
being yet to have any properties which would affect how they are 
processed.


  2) The behavior in LiveCode with regard 1CF5 and 1CF6 looks a lot like 
the behavior with [h,underdot] - where a trailing character is needed to 
make the original character appear in the appropriate font.


I'm pretty sure that (1) is an OS issue and not something we could 
necessarily do much about - it seems to be replacing it with the 
undefined codepoint early on in the rendering process (at the OS level, 
not the engine).


However, (2) does look like it could be an engine issue - indeed, it 
feels like an 'off-by-one' error somewhere in the processing of the runs 
of characters which eventually get passed to CoreText.


That being said, there is different behavior in general between TextEdit 
and LiveCode - which reminds me that I *think* Apple had not yet 
replumbed the text support in Cocoa to use CoreText in 10.6 - that 
happened in a later OS. So, in 10.6 TextEdit is most likely using 
entirely separate Text APIs from LiveCode...


Anyway, I'll take a closer look and see if I can find where the problem 
might be.


Warmest Regards,

Mark.

P.S. In terms of 1CF7 - it still looks like you might have to use a PUA 
char for it to have it work on Mac until it becomes widely supported :(


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

___
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

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

[Mark Waddingham via use-livecode]

On 2017-03-28 13:20, Richmond via use-livecode wrote:
I'd point out that TenFourFox is a fork of FireFox and is not a 
Mozilla project.


Is that a point that anyone who is prepared to go on running a PPC Mac 
should

be worried about?


They probably won't be - until the project ceases to be because a lack 
of support / input / people to use it...


What I was more trying to indicate was that whilst we (LiveCode) will 
not be directly supporting older operating systems, there is no reason 
why a similar community-led project could not exist for LiveCode to 
bring it back to older systems. Admittedly, this is not an easy project 
(if it was then the evaluation of whether we could continue to support 
them ourselves would potentially have turned out differently) but it is, 
at least, possible.



My original point was that I feel the word "unusable" is a way too
strong way of saying "not
up-to-date in the least".


Hehe - perhaps it was a little strong and I perhaps should have made it 
more specific. So "Unusable" if you need to interact with a lot of 
modern web-services and such through a fully compliant browser (i.e. 
general day-to-day use, instead of specific cases).


I'm NOT going to make Amazon purchases with my Debit card on my G3 
iMac!


Or indeed, let any information-which-needs-to-be-encrypted flow over the 
internet connection. To be fair, browsers tend to be somewhat unique in 
that they typically use their own entire network stack - relying only on 
the OS's bare sockets. So, a project like ForTenFour will likely be as 
secure as using a browser on any other more recent operating system. 
However, any app which uses system services will likely be a potential 
problem.


However, agin, this matters not one whit if the machine is not using / 
connecting to the internet or only doing so through applications which 
are known to be safe.



I have a friend who drives a 1980 Lada: it's great because as its
incredibly "primitive" not having
any on board computers anything that goes wrong can generally be
sorted out with a spanner,
a soldering iron and a few vulgar words.


Sounds a bit like computers from the 1980's too! (The spanner usually 
being used to hit the case, rather than actually spanner anything ;))


Warmest Regards,

Mark.

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

___
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

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

[Sannyasin Brahmanathaswami via use-livecode]

Two mangos on these issues from Hawaii. As one of the users of Richmond's 
program: He and I have been 'at it" for nearly 8 year with his DevaWrite Pro, 
because the "state of the art" for rendering Sanskrit in the world of fonts is 
pretty abysmal with respect to some small but mission critical unicode glyphs 
that are simply pretty much unavailable via any standard keyboard input… if 
Richmond succeeds with this app, he will have a "dream machine" for a niche 
market that, though small, can't get the job done any other way using unicode 
easily now without going back to Type 1 fonts or setting hot lead type!  enough 
back story…

One anomaly that appears to be generated by LC 9dp5 running on Sierra 10.12.3: 
Code point U803 maps in the Unicode standard to the Extended Latin "H with dot 
underneath" character. 

for some bizarre reason, on my machine/system,  Livecode is mapping this 
character to Lucida (I think… possibly Helvetica.)

see: http://wiki.hindu.org/uploads/h-with-dot-lucida-helvetica.jpeg

Not on Richmond's machine, where it maps correctly to his DevaWriter.ttf font 
point correctly.

Livecode exports the RTF code for this character correctly as u803, but does 
not render it in the font assigned to the field.

I can make a LC stack letter sized, print to PDF save the PDF as HTML and I get 
the strange anomaly where Adobe sees the PDF output from Livecode and renders

css 

f1: {font-family:Devawriter]
f2 (font-family:Ludida}

then in the html we have this odd 

[h-with-dot-here[

But… if I set my preferences in Sublime text to default font  is Richmond's 
font: DevaWriter.tff

*then* the h with dot *is* rendered correctly in the Devawriter Font NOT in 
lucida

So this is an issue with the LC engine…

I may relate to other issues…but  nuisance here because I have no other way to 
print or render the text except via  LiveCode card. unless I opent the RTF 
output in Text Edit and manually change each "h-with-dot" back to Devawriter 
font

so why is LC not mapping U803 to the font assigned to the field? 

POINT: this does prove there is issues with rendering on different OS, since 
that character displays properly on Richmond's machine.
  

 

On 3/27/17, 2:39 AM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

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

___
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

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

[Bob Sneidar via use-livecode]

What is an LC 475? Do you mean an Apple Performa? 

Bob S


> On Mar 28, 2017, at 10:41 , Richmond Mathewson via use-livecode 
>  wrote:
> 
> LC 475 running system 7.1.


___
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

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

[Richmond Mathewson via use-livecode]

I came to the Macintosh party late (even if the kilt I wear is always 
Hunting Macintosh, from my Grandfather Richmond McIntosh)

in 1993 with an LC 475 running system 7.1.

Richmond

On 3/28/17 6:05 pm, Dr. Hawkins via use-livecode wrote:

On Tue, Mar 28, 2017 at 2:17 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:


Not necessarily - I believe system 7.5 was pretty advanced when it came to
text and fonts.


Introduced in 7.0.



___
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

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

[Dr. Hawkins via use-livecode]

On Tue, Mar 28, 2017 at 2:17 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Not necessarily - I believe system 7.5 was pretty advanced when it came to
> text and fonts.


Introduced in 7.0.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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

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

[Richmond via use-livecode]

On 28/03/17 12:17, Mark Waddingham via use-livecode wrote:

On 2017-03-28 10:30, Richmond via use-livecode wrote:

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?


Not necessarily - I believe system 7.5 was pretty advanced when it 
came to text and fonts. In particular, I'm sure it had an 
implementation of TrueType at least. The only difference then was that 
a font might have multiple CMAP tables for different text encodings as 
the Unicode encoding was still in its infancy. Even bitmap fonts 
(which might not necessarily have been TrueType) would have to declare 
what encoding it assumed was being used so that things could be mapped 
appropriately.


In actual fact, fonts don't really care about encoding exactly - they 
provide tables which map indexes in an encoding to the glyphs to 
represent them. Everything inside the font runs on glyph indexes and 
not codepoints in any encoding. Indeed (as I mentioned in another 
email) you can use the PUA area for your font as a direct 
codepoint->glyph map.



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.


I'd point out that TenFourFox is a fork of FireFox and is not a 
Mozilla project.


Is that a point that anyone who is prepared to go on running a PPC Mac 
should

be worried about?

The same goes for Classilla on my OS 9 G3 iMac :)

My original point was that I feel the word "unusable" is a way too 
strong way of saying "not

up-to-date in the least".

I'm NOT going to make Amazon purchases with my Debit card on my G3 iMac!

I have a friend who drives a 1980 Lada: it's great because as its 
incredibly "primitive" not having
any on board computers anything that goes wrong can generally be sorted 
out with a spanner,

a soldering iron and a few vulgar words.



i.e. A third-party has taken the responsibility for maintaining a fork 
of an open-source project to ensure there is a variant of FireFox 
which runs on older systems...


I set up a Macintosh 5400 running system 9 and a series of standalones 
hived off LC/RR 2
derived from my EFL stacks for a chap in a village near here to help the 
kids at a Syrian
refugee camp: certainly a bit ancient, but not unusable. The kids are 
smiling, and learning
basic English vocabulary so they can work out how to become illegal 
migrants into Britain and

vote for Theresa May . . . or something.

Found a donor who is shipping us 12 more PPC all-in-ones running system 
9 . . . . cool; whatever works.




Warmest Regards,

Mark.



Best, Richmond.

___
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

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

[Mark Waddingham via use-livecode]

On 2017-03-28 10:30, Richmond via use-livecode wrote:

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?


Not necessarily - I believe system 7.5 was pretty advanced when it came 
to text and fonts. In particular, I'm sure it had an implementation of 
TrueType at least. The only difference then was that a font might have 
multiple CMAP tables for different text encodings as the Unicode 
encoding was still in its infancy. Even bitmap fonts (which might not 
necessarily have been TrueType) would have to declare what encoding it 
assumed was being used so that things could be mapped appropriately.


In actual fact, fonts don't really care about encoding exactly - they 
provide tables which map indexes in an encoding to the glyphs to 
represent them. Everything inside the font runs on glyph indexes and not 
codepoints in any encoding. Indeed (as I mentioned in another email) you 
can use the PUA area for your font as a direct codepoint->glyph map.



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.


I'd point out that TenFourFox is a fork of FireFox and is not a Mozilla 
project.


i.e. A third-party has taken the responsibility for maintaining a fork 
of an open-source project to ensure there is a variant of FireFox which 
runs on older systems...


Warmest Regards,

Mark.

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

___
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

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

[Richmond via use-livecode]

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 t

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

[Mark Waddingham via use-livecode]

On 2017-03-27 14:39, Mark Waddingham via use-livecode wrote:

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.


I realized that you don't actually need this at all - the PUA can be 
used to do precisely this.


As I'm sure you realize, a font has a 'cmap' table which maps codepoints 
to glyphs and this is can be a many->one mapping - i.e. you can have 
more than one codepoint mapping to the same glyph. So what you could do 
is:


  1) Map all the unicode defined codepoints to their appropriate glyphs 
(noting that use of these codepoints will cause the standard rules to be 
applied when typesetting strings).


  2) Map all the glyphs you want access to a block in the PUA (noting 
that these codepoints will have no extra processing)


You can then use PUA codepoints to get 'just the glyphs', or the normal 
codepoints if you want the standard behavior.


In the future you could look into adding OpenType tables (GPOS, GDEF and 
GSUB in particular) to your font - these allow the font to define things 
like complex kerning, ligatures (where two characters combine into one 
glyph), accents (where single character is composed of a base glyph and 
an accent attached to it) and all kinds of other things without the 
software using it having to know anything about the gory details.


Warmest Regards,

Mark.

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

___
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

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

[Mark Waddingham via use-livecode]

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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Richmond via use-livecode]

Here is an interesting extract from the reply I got from the maker of 
Unicode Checker:


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


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.

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.

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.


Best, Richmond.

On 27/03/17 13:36, Mark Waddingham via use-livecode wrote:

On 2017-03-26 17:48, Richmond Mathewson via use-livecode wrote:

Interestingly enough this FREE program for Macintosh:

https://www.macupdate.com/app/mac/9752/unicodechecker

Very successfully displays glyphs I have built into my Devawriter.ttf
font in comformance
with the Unicode version 10 Beta specification.

This all on my supposedly outmoded system 10.7.5 plastic box.


Just an update here - my 10.11 box does happily display all three 
characters as needed in LiveCode and other apps. When I initially 
installed the devawriter font which was supplied, it must not have 
installed it properly (I think I might have had an old version 
installed). After removing 'Devawriter' completely (using Font Book) 
and then reinstalling (by double clicking the latest version) - I get 
all codepoints appearing as expected.


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

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

[Mark Waddingham via use-livecode]

On 2017-03-26 17:48, Richmond Mathewson via use-livecode wrote:

Interestingly enough this FREE program for Macintosh:

https://www.macupdate.com/app/mac/9752/unicodechecker

Very successfully displays glyphs I have built into my Devawriter.ttf
font in comformance
with the Unicode version 10 Beta specification.

This all on my supposedly outmoded system 10.7.5 plastic box.


Just an update here - my 10.11 box does happily display all three 
characters as needed in LiveCode and other apps. When I initially 
installed the devawriter font which was supplied, it must not have 
installed it properly (I think I might have had an old version 
installed). After removing 'Devawriter' completely (using Font Book) and 
then reinstalling (by double clicking the latest version) - I get all 
codepoints appearing as expected.


Warmest Regards,

Mark.

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

___
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

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

[Richmond Mathewson via use-livecode]

Interestingly enough this FREE program for Macintosh:

https://www.macupdate.com/app/mac/9752/unicodechecker

Very successfully displays glyphs I have built into my Devawriter.ttf 
font in comformance

with the Unicode version 10 Beta specification.

This all on my supposedly outmoded system 10.7.5 plastic box.

Richmond.

___
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

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

[Richmond Mathewson via use-livecode]

*Mark Waddingham_wrote:_  *

snip
I suspect OpenOffice does its own (bespoke) font layout and rendering which is
why it 'does something there'. However, whether or not what it does is
'correct', is another matter.



snip

Of course the "nasty" question to ask at this point
is why LiveCode IS dependent for Unicode handling on the underlying OS
and is unable to do its own internal processing.

While I'm on a "nasty" streak this page needs to be sorted out: 
http://lessons.livecode.com/m/4071/l/20441-unicode

as it makes no mention of *numToCodepoint*.

Here, Fraser says something about Unicode: 
*https://livecode.com/tag/unicode/


"*Those of you who have been paying attention to my previous blog posts 
(if you exist!) will have heard me mention that to convert between Text 
and Binary you need to use textEncode and textDecode. With these 
functions, you specify an encoding. But when the engine does it 
automatically, what encoding does it use?


"The answer is the "native" encoding of the OS on which LiveCode is 
running. This means "CP1252" on Windows, "MacRoman" on OSX and iOS and 
"ISO-8859-1" on Linux and Android. All of these platforms fully support 
Unicode these days but these were the traditional encodings on these 
platforms before the Unicode standard came about. LiveCode keeps these 
encodings for backwards-compatibility."


[ Oh, and Yes, Fraser, I, at least, have read your blog posts with great 
interest. ]


So, LiveCode keeps encodings for bw compat., but penalises people who 
would like to be forward compatible; at least in the ability to
run off standalones that will function on later instantiations of 
operating systems, and to that end making sure that these things show

up on the older operating systems.

Of course one of the easier ways round this is to withdraw support for 
earlier OSes . . .


But as the documentation for LiveCode 8.1.3 states:

TThe Mac engine supports:
10.6.x (Snow Leopard) on Intel
10.7.x (Lion) on Intel
10.8.x (Mountain Lion) on Intel
10.9.x (Mavericks) on Intel
10.10.x (Yosemite) on Intel
10.11.x (El Capitan) on Intel
10.12.x (Sierra) on Intel

something is not quite right.

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