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

[Sannyasin Brahmanathaswami]

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" <use-livecode-bounces at lists.runrev.com on behalf of use-livecode at lists.runrev.com> 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