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-boun...@lists.runrev.com on behalf of use-livecode@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 _______________________________________________ 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
