Quantcast

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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode

*Mark Waddingham_wrote:_ <mailto:[hidden email]> *
> 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:

T        The 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- 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 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- via use-livecode
On Tue, Mar 28, 2017 at 2:17 AM, Mark Waddingham via use-livecode <
[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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 <
> [hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- 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 <[hidden email]> wrote:
>
> LC 475 running system 7.1.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- 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

<span class=f2>[h-with-dot-here[</a>

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" <[hidden email] on behalf of [hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

prothero--- via use-livecode
In reply to this post by prothero--- 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Loading...