Jumping cursors

Richmond Mathewson richmondmathewson at gmail.com
Thu Jan 5 05:01:56 EST 2017


Thanks for a very clear explanation.

On 1/5/17 11:19 am, Mark Waddingham wrote:
> On 2017-01-05 09:56, Richmond Mathewson wrote:
>> Um: this could be a "stupid Richmond" case rather than anything else
>> as I populated cells FF001
>> to FF01E with Grantha Samyuktaksharas: and those in FF002 and so on
>> behave perfectly well;
>
> This is a case of 'stupid engine', rather than 'stupid Richmond':

Ha, Ha, Ha: possibly the first time ever that it hasn't been the latter :)
>
> http://quality.livecode.com/show_bug.cgi?id=19045

By 'stupid engine' do you mean the LiveCode engine, something else, or 
code that has been co-opted
from elsewhere and folded into the LC engine?

>
> The implementation of the bidi algorithm in the engine is currently 
> computing surrogate pairs incorrectly. 

"The implementation of the bidi algorithm" . . . ouch.

Aah . . . "bidi" means 'BIDIrectional'

Obviously something rather jazzier than my feevle effort: 
https://www.dropbox.com/s/rlw0t1ymwoghq5q/SURROGATER.rev.zip?dl=0

I, like a fool, had assumed that post LiveCode 7.0 the engine was, 
somehow, avoiding surrogate pairs
altogether, rather than fudging around so things were *very pleasant 
indeed* for people like me when
leveraging glyphs occupying Unicode areas above the first plain.

Obviously things were slightly too good to be true.

> In this case, 0xFF001 is being read as a character in the arabic 
> script area in the BMP which has the 'Arabic RTL' attribute. This 
> means that it is being treated as an RTL character when it should not be.

Do you have any idea which other surrogate pairs it might be getting wrong?

Until (if ?) things get sorted out that would be a useful reference list 
so as to know which Unicode slots
to avoid.

Writing as a lazy slob I feel no screaming urge to go back and recode 
all those (0x4FFF6), (0x3EEDA)
hex codes as surrogate pairs . . .
>
>> but FF001 could be a non-character which I had overlooked: If one 
>> goes here:
>>
>> http://www.unicode.org/charts/PDF/UF0000.pdf
>>
>> information regarding FF001 is not much use . . .
>>
>> The Range: F0000 - FFFFF is the Unicode Supplementary Private Use
>> Area-A; a bit like that area
>> in New Mexico.
>>
>> Although "The entire plane is dedicated to private use with the
>> exception of the last two code points."
>> would seem to imply that FF001 should cause me no problems.
>
> Indeed - end user applications are free to use SPUA-A and SPUA-B for 
> whatever purpose they wish... With the only caveat that two uses of 
> said areas might be completely incompatible. (i.e. a font designed for 
> use in one application which uses these areas, might break horribly in 
> an app which uses the area for a completely different purpose).

My Devawriter Pro application depends on my Devawriter.ttf font which 
employs all 3 Private Use Areas to
deliver the conjunct consonants used in the Indian writing systems used 
to write Sanskrit.

In fact I have spent nearly as much time developing my font as I have on 
the Devawriter Pro application itself.

Obviously my font is not going to be much use outwith my application 
beyond displaying
HTML, RTF and PDF documents derived from the application.

>
> Warmest Regards,
>
> Mark.
>
Best,

Richmond.



More information about the use-livecode mailing list