On 15.06.2016 19:43, Mark Waddingham wrote:
Hi Richmond,
On 2016-06-15 18:27, Richmond wrote:
So, obviously, I will have to set a "bot" to trawl its way through my
code
and replace every incidence of *numToChar* to *numToCodePoint*, and
replace the surrogate pairs in the upcoming *Grantha* interface
with "standard" Unicode addresses. The first of which should (?) be
relatively
simple if the global search-N-replace behaves itself, the second will
be a
bother, but nothing insurmountable.
If all your instances of numToChar are where useUnicode is 'true' then
you probably *won't* have to do this.
When useUnicode is true, numToChar() works as it always did - it
produces two bytes which are the binary encoding of the specified
unicode code unit (not codepoint - see in a minute) as UTF-16.
Now, numToChar() (with useUnicode true) never supported unicode
codepoints above 65535 - however I think you already figured out how
to decompose a character outside of the BMP (i.e > 65535) into two
surrogate pairs which are < 65535 and thus supported by numToChar().
You mention that Devawriter Pro was written against 4.5.x - if I
recall correctly then this was *before* the field became more
intelligent at handling unicode. Around 5.5 we changed the field so
that it *understood* that a unicode code unit (any unicode char <=
65535, surrogate pairs are two code units) was a single 'char'. Prior
to 5.5, the field used 'char' to mean byte (so char 1 of field 1,
where the first character in a field was a unicode character would
return you the first byte of code unit, not the code unit itself -
which you would get with char 1 to 2 of field 1).
This latter fact probably means you will need to spend some time
looking at the code which manipulates fields as, if you are using
'char' on your fields containing unicode and computing indicies
thereof (e.g. char 3 to 4 of field 1), you'll need to adjust for that.
So, to sum up, the changes introduced around 5.5 are likely to cause
you *more* trouble than those introduced with 7.0 - if you fix your
code so it works with 5.5 functioning of the field and make sure you
put text into the field using 'set the unicodeText of <field chunk>'
or 'put unicode ... into <field chunk>'; then you *should* find that
there is little or no need to update your unicode construction code -
which has all the instances of numToChar.
This is rather interesting as all my code currently features
set the unicodeText of fld "XYZ" to the unicodeText of fld "XYZ" &
numToChar(12345)
in LC/RR 4.5, to which I should add:
1. That works 100% in LC 4.5
2. I thought that was "the way" in 4.5, so don't entirely understand
"the changes introduced around 5.5 are likely to cause you *more*
trouble than those introduced with 7.0".
Having said that, we'll see soon enough if I come-a-cropper or not :)
Richmond.
Hope this helps!
Very much so.
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
