Re: Unicode and languages

Ha! You beat me to it, Alex. The only extra is that Paul might be able to identify very common but distinct markers to identify the language, and create a simple algorithm. Made me wonder how Google translate does it when it is set to 'detect language’ Cheers, David G > On 6 Jun 2020, at

Re: Unicode and languages

Not LC native but take a look at Google Translate API

Re: Unicode and languages

If you simply need to protect users in the scenario you describe, then you could try a simple heuristic  - extract the first 100 (200? - 500?) characters (or first 20 words)  - spell check that  - if there are more than 10 (20? - 50??) spelling errors then flag it as a likely language mismatc

Re: Unicode and languages

I doubt that. But if you can determine the Unicode range that is being used you can at least know which writing system is being used. You could then trap for individual glyphs (such as 'џ', which is only used in Macedonian) to narrow things down a spot. On 5.06.20 20:15, Paul Dupuis via use-li

Re: Unicode and languages

On 6/5/2020 1:46 PM, Mark Waddingham via use-livecode wrote: On 2020-06-05 18:15, Paul Dupuis via use-livecode wrote: I don't even know if language exists in the IBM Unicode engine as some exportable property a future version of LiveCode could expose. Any clever ideas or thoughts on this proble

Re: Unicode and languages

On 2020-06-05 18:15, Paul Dupuis via use-livecode wrote: I don't even know if language exists in the IBM Unicode engine as some exportable property a future version of LiveCode could expose. Any clever ideas or thoughts on this problem are welcome. Unicode doesn't deal in languages but 'script

Re: Unicode mysteries

I have filed a bug report bug_22561 re the misreporting of codepoints for unicode characters. I am pretty convinced the treatment of the Rainbow flag emoji as three separate characters should be treated as incorrect behaviour and therefore

Re: Unicode mysteries

> >> Which should correspond to codepoints >> 1F3F4 E0067 E0062 E0073 E0063 E0074 E007F >> And indeed if I manually build a UTF-16 string with these code points >> it does display as the flag of Scotland. So the lesson is that the >> reported chunks are not to be naively trusted --- tho no

Re: Unicode mysteries

I see the flag here. Bob S On Mar 25, 2020, at 11:53 PM, Neville Smythe via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Taking a look at the Emoji ‘flag of Scotland’ character 🏴󠁧󠁢󠁳󠁣󠁴󠁿 which won’t display here but exists in the Apple Color Emoji font and in corresponding fonts

Re: Unicode mysteries

On 2020-03-26 06:53, Neville Smythe via use-livecode wrote: Which should correspond to codepoints 1F3F4 E0067 E0062 E0073 E0063 E0074 E007F And indeed if I manually build a UTF-16 string with these code points it does display as the flag of Scotland. So the lesson is that the reported chun

Re: Unicode is not "everywhere"...

This post regards the future of "the detailed files". I'm resurrecting this thread to reply to a couple of very important statements after helping to create a fairly fast, cross-platform tentative workaround (still in testing, and I only mention this since the code was already posted) for th

Re: Unicode is not "everywhere"...

On 2019-08-27 10:55, Dar Scott Consulting via use-livecode wrote: The added parameter approach looks very similar to an enhancement suggestion that has been around for a while. I'd mention the bug number, but I and bugs are not getting along at the moment. Indeed - it is very unlikely a new sug

Re: Unicode is not "everywhere"...

The added parameter approach looks very similar to an enhancement suggestion that has been around for a while. I'd mention the bug number, but I and bugs are not getting along at the moment. Dar > On Aug 27, 2019, at 5:54 AM, Mark Waddingham via use-livecode > wrote: > > On 2019-08-22 20:53,

Re: Unicode is not "everywhere"...

Mark, 1) Fine with shell remaining as is. Thanks to Dar and others, there are ways to execute a windows or OSX shell command that returns Unicode and get Unicode back. The Dictionary entries just need to be documented with  a caution or warning about how to handle Unicode with Shell on each p

Re: Unicode is not "everywhere"...

On 2019-08-22 21:07, Paul Dupuis via use-livecode wrote: I reported what I thought was 3 bugs in 1 report in https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that report to focus on a single bug - that the detailed files (and probably the detailed folders) is broken for Unicode a

Re: Unicode is not "everywhere"...

On 2019-08-22 20:53, Paul Dupuis via use-livecode wrote: I just want it consistent and documented and able to return more than just ASCII data Currently, OSX shell returns UTF8 which may mean that it is returning binary as it is returning 8-bit bytes where Unicode text has been encoded as UTF8

Re: Unicode is not "everywhere"...

You know, I don't know. I have spent so much time on these bugs that my brain is burned out. Someone like Mark Waddingham can determine the architecturally correct return values and then make sure the Dictionary reflects the right way to use them. At this point, I have work-arounds to shell

Re: Unicode is not "everywhere"...

If shell returns text, does that mean shellCommand has to go away? > On Aug 23, 2019, at 9:05 AM, Paul Dupuis via use-livecode > wrote: > > On 8/23/2019 10:30 AM, Dar Scott Consulting via use-livecode wrote: >> SHELL() >> >> Related: https://quality.livecode.com/show_bug.cgi?id=22334 >>

Re: Unicode is not "everywhere"...

On 8/23/2019 10:30 AM, Dar Scott Consulting via use-livecode wrote: SHELL() Related: https://quality.livecode.com/show_bug.cgi?id=22334 I was on the fence concerning whether shell() returns a text string or binary data. I have fallen t

Re: Unicode is not "everywhere"...

Hi Dar, Yes, this is a viable work-around for the Windows shell bug. function newShell pCommand   local tResult   set the hideConsoleWindows to true   set the shellCommand to "cmd.exe /u" --/U for UTF16 output   put shell(pCommand) into tResult   if the result is empty then -- no errors     put

Re: Unicode is not "everywhere"...

SHELL() Related: https://quality.livecode.com/show_bug.cgi?id=22334 I was on the fence concerning whether shell() returns a text string or binary data. I have fallen to one side: BINARY. Here is a summary of my position. Tomatoes are wel

Re: Unicode is not "everywhere"...

Paul, does this solve the problem with shell() on Windows? > On Aug 22, 2019, at 10:27 PM, dsc--- via use-livecode > wrote: > > I tried it. > > on mouseUp > set the shellCommand to "cmd.exe /u" > put textDecode( shell("dir"), "UTF-16" ) > end mouseUp > > That does seem to double up the ne

Re: Unicode is not "everywhere"...

I tried it. on mouseUp set the shellCommand to "cmd.exe /u" put textDecode( shell("dir"), "UTF-16" ) end mouseUp That does seem to double up the newlines. It looks like it works otherwise. Dar > On Aug 22, 2019, at 12:15 PM, dsc--- via use-livecode > wrote: > > The shellCommand proper

Re: Unicode is not "everywhere"...

> On 23 Aug 2019, at 11:07 am, Paul Dupuis via use-livecode > wrote: > > I reported what I thought was 3 bugs in 1 report in > https://quality.livecode.com/show_bug.cgi?id=22213 > . I have edited that > report to focus on a single bug - th

Re: Unicode is not "everywhere"...

All encoding is binary, but not all binary is valid Unicode encoding. > On Aug 22, 2019, at 6:53 PM, Paul Dupuis via use-livecode > wrote: > > Currently, OSX shell returns UTF8 which may mean that it is returning binary > as it is returning 8-bit bytes where Unicode text has been encoded as U

Re: Unicode is not "everywhere"...

But that isn't the issue. Well, not what I thought the issue was. If shell() only returns binary, as suggested by the mention of textDecode(), then binary data must always have an interpretation as a string to keep from breaking legacy code. Currently, that is interpreted as an 8-bit character o

Re: Unicode is not "everywhere"...

On 8/22/2019 8:46 PM, Monte Goulding via use-livecode wrote: Both of these are anomalies we could only resolve with new syntax I think… at lease the urlEncode one is. I’m not sure if the expectation of shell is it returns text or binary data… The workaround there would be to open process for U

Re: Unicode is not "everywhere"...

I just want it consistent and documented and able to return more than just ASCII data Currently, OSX shell returns UTF8 which may mean that it is returning binary as it is returning 8-bit bytes where Unicode text has been encoded as UTF8 Windows returns CP1252 text, not binary and any Unicod

Re: Unicode is not "everywhere"...

Both of these are anomalies we could only resolve with new syntax I think… at lease the urlEncode one is. I’m not sure if the expectation of shell is it returns text or binary data… The workaround there would be to open process for UTF8 text read instead of using shell... not sure if UTF8 would

Re: Unicode is not "everywhere"...

You can't have it both ways. Either shell() only characters of the broadest character set, Unicode, or it returns binary. If it returns characters, then it will not work for binary responses; that will have to be documented as excluded. If Unicode is returned then textDecode is not needed and e

Re: Unicode is not "everywhere"...

On 8/22/2019 4:08 PM, Richard Gaskin via use-livecode wrote: Dar Scott wrote: > If the result of shell() is run through textDecode, should then > shell() return binary data? This puts it outside the scope of > "everywhere". I like the idea, as long as simple ASCII characters > work transparently

Re: Unicode is not "everywhere"...

Dar Scott wrote: > If the result of shell() is run through textDecode, should then > shell() return binary data? This puts it outside the scope of > "everywhere". I like the idea, as long as simple ASCII characters > work transparently. Isn't that the goal of UTF-8, which is why so many programm

Re: Unicode is not "everywhere"...

If the result of shell() is run through textDecode, should then shell() return binary data? This puts it outside the scope of "everywhere". I like the idea, as long as simple ASCII characters work transparently. Currently, "is strictly" says it is a string, not a binary string. As far as the q

Re: Unicode is not "everywhere"...

Dar Scott wrote: > Concerning 22335... > > 1. I wonder if anyone uses shell() to return binary values. In the modern Unicode world, what is "text" and what is "binary"? I believe MacOS' HFS+ and Win's NFS use UTF-16 natively, Linux EXT4 uses UTF-8. It might seem simple to have a habit of ru

Re: Unicode is not "everywhere"...

The shellCommand property for Windows is "cmd.exe", not "command.com " as described in the dictionary. I wonder how setting that to "cmd.exe /u" would affect this behavior. > On Aug 22, 2019, at 10:19 AM, Dar Scott Consulting via use-livecode > wrote: > > Concerning 22335

Re: Unicode is not "everywhere"...

Concerning 22335... 1. I wonder if anyone uses shell() to return binary values. 2. I wonder about whether using the shellCommand property would help. > On Aug 22, 2019, at 9:37 AM, Paul Dupuis via use-livecode > wrote: > > I have filed two bug reports that are in LC905rc1 and go back to 7.0 w

Re: Unicode Store in JSON

Unicode is binary?? > Bob S not unicode per se Dictionary says *Syntax* textEncode(*stringToEncode*, encoding) *Summary* Converts from text to binary data. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscr

Re: Unicode Store in JSON

Unicode is binary?? Bob S > On Oct 14, 2018, at 17:35 , Sannyasin Brahmanathaswami via use-livecode > wrote: > > On 10/14/18 8:43 AM, J. Landman Gay via use-livecode wrote: >> I'd store the text normally, without alteration, in the JSON. TextEncode >> it when you send it to the database and

Re: Unicode Store in JSON

> On 16 Oct 2018, at 12:09 am, Sannyasin Brahmanathaswami via use-livecode > wrote: > > A "Related" entry under textDecode and textEncode might help. > > The problem is when you get to a dictionary entry for those, there is no > mention "mergJSON". > > So not matter how well "mergeJSON" is d

Re: Unicode Store in JSON

On 10/14/18 5:41 PM, Monte Goulding via use-livecode wrote: > Well mergJSON is documented to return UTF-8 encoded JSON, however, I agree > that JSONImport and JSONExport docs are a little ambiguous and should clarify > that the JSON needs to be textDecoded before calling JSONImport and > textEnc

Re: Unicode Store in JSON

> On 15 Oct 2018, at 2:31 pm, Sannyasin Brahmanathaswami via use-livecode > wrote: > > First can you clarify if both of these should work.? We see both in > dictionary... > > *Example* > > textEncode("A","UTF16") > > *put*textEncode(field"output","UTF-8") intotOutput > > will the 2nd param

Re: Unicode Store in JSON

First can you clarify if both of these should work.? We see both in dictionary... *Example* textEncode("A","UTF16") *put*textEncode(field"output","UTF-8") intotOutput will the 2nd param work with or without a hyphen? --- unclarity --simply: *Syntax* textEncode(*stringToEncode*, encod

Re: Unicode Store in JSON

> On 15 Oct 2018, at 11:35 am, Sannyasin Brahmanathaswami via use-livecode > wrote: > > Wow, that worked! And I thought that JSON could not be a container for > "binaryData" as described on the dictionary. Could you provide some detail where the docs are misleading. It is actually true that

Re: Unicode Store in JSON

On 10/14/18 8:43 AM, J. Landman Gay via use-livecode wrote: > I'd store the text normally, without alteration, in the JSON. TextEncode > it when you send it to the database and textDecode when you retrieve it > from the database. Wow, that worked! And I thought that JSON could not be a container

Re: Unicode Store in JSON

I'd store the text normally, without alteration, in the JSON. TextEncode it when you send it to the database and textDecode when you retrieve it from the database. On 10/14/18 9:26 AM, Sannyasin Brahmanathaswami via use-livecode wrote: I need to store unicode in JSON on Mobile; and store that

Re: unicode & umlauts

Hi Eric, I retested Scott's solution and it works like a charm. I must have made a mistake when copying the code initially. It is a lot easier and more sensible than my solution. this is Scott's script that works for me -- on mouseup local theTex

Re: unicode & umlauts

Hi Eric, it seems that urlEncode does not give the expected hex values for high ASCII characters. Yandex expects UTF8 hex values. for example the german o-umlaut after urlEncode is %F6 which is ASCII 154 in the extended ASCII table yandex expects %C3%B6 that is the utf8-urlEncode form. I

Re: unicode & umlauts

Hello Eric, Just an idea but for working with yandex, what if you textEncode and textDecode for the round trip. Like so: on mouseup repeat with i = 1 to the number of lines in card field "source" put URLEncode(textEncode(line i of cd fld "source","UTF8")) into theText put "https://

Re: unicode & umlauts

Hi Bob, > Am 21.06.2018 um 18:23 schrieb Bob Sneidar via use-livecode > : > > If only. ;-) Monsieur? Isn't it? It IS! > Bob S >> On Jun 21, 2018, at 08:59 , Klaus major-k via use-livecode >> wrote: >> Hi Eric, >>> Am 21.06.2018 um 17:42 schrieb Eric A. Engle via use-livecode >>> : >>> .. >

Re: unicode & umlauts

If only. ;-) Bob S > On Jun 21, 2018, at 08:59 , Klaus major-k via use-livecode > wrote: > > Hi Eric, > >> Am 21.06.2018 um 17:42 schrieb Eric A. Engle via use-livecode >> : >> >> ... >> Another question: in hypercard cmd + . = stop executing script. Is there any >> similar command in liv

Re: unicode & umlauts

Hi Eric, > Am 21.06.2018 um 17:42 schrieb Eric A. Engle via use-livecode > : > > ... > Another question: in hypercard cmd + . = stop executing script. Is there any > similar command in livecode? even better, the command is identical in Livecode. :-) Best Klaus -- Klaus Major http://www.maj

Re: unicode & umlauts

Yes, I think my problem with Chinese was I had only simplified and not traditional fonts installed. Anyway I installed some libraries now my paste clipboard ctrl v works. What doesn't work is calling the Yandex api to translate and then send the translation to a livecode field. Even though I de

Re: unicode & umlauts

Dunno: I just pasted THIS from NotePad into a textField in LiveCode 9 on Xubuntu: Eine Überraschung stellen dagegen Wörter, wie „doppelgaenger“, „schadenfreude“ oder „poltergeist, dar, die sich, laut dem #Oxford #Dictionary, längst im englischen Wortschatz eingenistet haben. Anscheinend ist die

Re: Unicode inconsistency

With colourful pictures: http://forums.livecode.com/viewtopic.php?f=5&t=30718 Richmond. Bug report 21055 -- Quite interesting. Especially that decimal worked. On Sat, Mar 10, 2018 at 1:56 AM, Richmond Mathewson < richmondmathew...@gmail.com> wrote: > > > On 10/3/2018 1:32 am, Brian Milby wr

Re: Unicode inconsistency

Is it a font issue? I get an empty box on Win10 and a box with a ? inside on my Mac. Had to go to fileformat.info to see what it should look like. On Fri, Mar 9, 2018 at 1:49 PM Richmond Mathewson via use-livecode < use-livecode@lists.runrev.com> wrote: > When I do this: > > put numToCodePoint(0xA

Re: Unicode Stretch

Answering my own post (nothing new in this area): YES! Richmond. On 15/2/2018 12:51 am, Richmond Mathewson wrote: Does numToCodePoint "stretch" to Supplementary Private Use Area-B (plane 16) Range: 10-10FFFD Richmond. ___ use-livecode mailin

Re: Unicode Reference stack

Nicely done Richmond! Bob S > On Apr 1, 2017, at 12:36 , Richmond Mathewson via use-livecode > wrote: > > Things just got better! > > On 3/31/17 10:11 pm, Richmond Mathewson wrote: >> Here: http://forums.livecode.com/viewtopic.php?f=26&t=29069 >> >> Richmond. > __

Re: Unicode Reference stack

Things just got better! On 3/31/17 10:11 pm, Richmond Mathewson wrote: Here: http://forums.livecode.com/viewtopic.php?f=26&t=29069 Richmond. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe

Re: Unicode 0x1cf6 and so on

NOPE: this would seem to be a LiveCode-specific problem as I just entered those 3 characters (which are present in my Devawriter.ttf) font into a LibreOffice Writer document (Mac OS) without a backward glance. Bug 19471 Richmond. On 3/25/17 5:35 pm, Richmond Mathewson wrote: I have a "funny f

Re: Unicode 0x1cf6 and so on

I have a "funny feeling" this is some problem with kerning rules for the characters 1CF5, 1CF6 and 1CF7 only. On 3/25/17 4:54 pm, Richmond Mathewson wrote: It seems impossible to do this: put numToCodepoint(0x1cf7) into fld "fff" (LC 8.1.3) all one gets is a horrible little square (which one

Re: unicode? troubles

I have been using this stack for years. I started working on it since runrev version 2.5 actually and I was working on something similar even in hypercard. (how the years pass by) Anyway, it’s a tool that helps me analyse stacks and code. For one thing, it gives me a tree view of all messages and

Re: unicode? troubles

Maybe this one? http://quality.livecode.com/show_bug.cgi?id=17590 On 26 Aug 2016 17:38, "Ali Lloyd" wrote: > Also what version are you using? I vaguely recall a similar issue having > been fixed. > > On Fri, 26 Aug 2016 at 17:11, Jeanne A. E. DeVoto < > revolut...@jaedworks.com> > wrote: > > > Ha

Re: unicode? troubles

Also what version are you using? I vaguely recall a similar issue having been fixed. On Fri, 26 Aug 2016 at 17:11, Jeanne A. E. DeVoto wrote: > Have you set the itemDelimiter to tab, or is it the default comma? > > Can you post your code, along with the contents of the field before and > after?

Re: unicode? troubles

Have you set the itemDelimiter to tab, or is it the default comma? Can you post your code, along with the contents of the field before and after? At 10:16 AM +0200 8/26/2016, runrevl...@cc-mail.nl wrote: Hi all, I have a strange problem which I can't seem to solve. I put some tab delimited te

Re: Unicode and card names

On 21/07/2016 03:00, Peter Bogdanoff wrote: Am I correct in thinking that with Unicode support, cards can now be named anything that uses Unicode characters? Formerly, I ran into trouble when trying to reference cards that had a name that contained an accented character. As I understan it,

Re: Unicode character recognition by drawing

On 12.07.2016 22:43, Dar Scott wrote: put length ( numToCodepoint( 0xE ) ) gives me 1 in 8.0. (BTW, I don't think 0xE is assigned.) It isn't and I was having a "mental moment" . . . Richmond. On Jul 12, 2016, at 1:04 PM, Richmond wrote: Thinking, as one does, Livecodewards

Re: Unicode character recognition by drawing

put length ( numToCodepoint( 0xE ) ) gives me 1 in 8.0. (BTW, I don't think 0xE is assigned.) > On Jul 12, 2016, at 1:04 PM, Richmond wrote: > > Thinking, as one does, Livecodewards I wonder why this doesn't seem to work > (7.1.4): > > put numToCodePoint(917504) > > That shoul

Re: Unicode character recognition by drawing

Thinking, as one does, Livecodewards I wonder why this doesn't seem to work (7.1.4): put numToCodePoint(917504) That should not cause any problems . . . but. Richmond. On 12.07.2016 22:01, Mark Wieder wrote: Richmond writes: Thanks, Mark; that cheered me up after a rather "non" day! Cool

Re: Unicode character recognition by drawing

Richmond writes: > Thanks, Mark; that cheered me up after a rather "non" day! Cool. You were the one I thought would be the most interested in this. At the very least it's a fun toy to play with. The web page does say "Japanese, Korean and Chinese characters are currently not supported." so I

Re: Unicode character recognition by drawing

That's a clever piece of work. I threw: Ж , ѭ, ह and छ at it, and the only one it got wrong was the last [Devanagari 'ccha']; pretty good (well, better than Meatloaf in "Two out of three ain't bad."); unfortunately as my non-Latin writing systems are limited to about 6 (Old Cyrillic, Glagolit

Re: Unicode display engine.

No joy "over here" on Linux. Arial Unicode MS. My "problem" (well, apart from all the other ones . . . ) is HOW to get my Devawriter Pro to "do" 'standard' (lots of quotation marks floating around, sorry) Hindi halant entry rather than the non-standard method (which works cross-platform, but d

Re: Unicode display engine.

On 21/05/16 09:05, RM wrote: I don't know how the Unicode display engine in Livecode 7.0 and upwards works. LiveCode doesn't include a Unicode display engine - it takes the steam of characters, breaks it down into words and then asks the operating system's display engine to render those words

Re: Unicode files

On 8/14/2015 1:36 PM, Peter TB Brett wrote: On 2015-08-14 20:32, J. Landman Gay wrote: I haven't got the materials yet so I can't test, but I am about to write a script that saves an array to a file on disk using arrayEncode (LC 7.) This is strictly for LC use; it will be saved and then re-load

Re: Unicode files

Thanks Pete, I was hoping that was the answer. This particular project is LC-7 exclusive, so the two arrayEncodings won't be a problem. In fact, I'm going to ignore it altogether. :) On 8/14/2015 1:37 PM, Peter Haworth wrote: I've done that without textEncode and it worked fine. Just watch ou

Re: Unicode files

I've done that without textEncode and it worked fine. Just watch out for the two arrayencoding algorithms used in different lc versions. On Fri, Aug 14, 2015 at 11:32 AM J. Landman Gay wrote: > I haven't got the materials yet so I can't test, but I am about to write > a script that saves an arr

Re: Unicode files

On 2015-08-14 20:32, J. Landman Gay wrote: I haven't got the materials yet so I can't test, but I am about to write a script that saves an array to a file on disk using arrayEncode (LC 7.) This is strictly for LC use; it will be saved and then re-loaded into the stack on next launch. Do I need t

Re: Unicode in file paths...

On 5/7/2015 12:42 AM, Richard Gaskin wrote: > Fails: > - OS X 10.7 QuickTime > - OS X 10.6 QuickTime > For clarification for any one following this thread: The above combinations work. I had an error in my code that had the original tests fail. Using LC704, file references for media that incl

Re: Unicode in file paths...

Paul, If you do this entire part in AppleScript, the problem solves itself. set xFile to choose file of type "mov" -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553

Re: Unicode in file paths...

On 5/6/2015 7:08 PM, Paul Dupuis wrote: > answer file "Pick a movie:" > set the fileName of player 1 to shortFilePath(it) Mark & Peter, Thank you for the tips. The issue (in LC 6.7.4) appears not to be the manipulation of the file, but having some way of prompting the user to select a file with U

Re: Unicode in file paths...

On 5/7/2015 12:42 AM, Richard Gaskin wrote: > If I read that correctly the LC 7.0.4 results for Unicode media paths > could be summarized as: > > Works: > - Windows QuickTime > - OS X 10.10 AV Foundation > - OS X 10.9 AV Foundation > - OS X 10.8 AV Foundation > > Fails: > - OS X 10.7 Qui

Re: Unicode in file paths...

Hi Paul, Before playing a movie, you could use AppleScript or shell to store a copy of the file in the temp folder with a name encoded in MacRoman-compatible characters. (Use UTF8 for the file path in AppleScript). You may need to save the AppleScript as a .scpt file on disk and execute with

Re: Unicode in file paths...

If I read that correctly the LC 7.0.4 results for Unicode media paths could be summarized as: Works: - Windows QuickTime - OS X 10.10 AV Foundation - OS X 10.9 AV Foundation - OS X 10.8 AV Foundation Fails: - OS X 10.7 QuickTime - OS X 10.6 QuickTime Not described: - OS X 10.7 A

Re: Unicode in file paths...

I think you should be able to use uniDecode to convert the filename string to its Unicode equivalent. Pete lcSQL Software Home of lcStackBrowser and SQLiteAdmin On Wed, May 6, 2015 at 4:08 PM

Re: Unicode

Normalisation, folding and collation all require a fair bit of data to do (proportional to the size of the current iteration of the unicode character tables in fact) which will be why SQLite externalises such functions as hooks. It might be we can hook this up to the routines in the engine thoug

Re: Unicode

Interesting, thanks Mark. In case any database developers are interested, it seems that the SQLite upper() and lower() functions only work with ASCII characters as does COLLATE NOCASE so at least Livecode is ahead of SQLite. It is possible to write your own collation handlers for SQLite but would

Re: Unicode

On 06/05/15 10:42, Mark Waddingham wrote: On 2015-05-06 01:53, Peter Haworth wrote: Right, this is where I get confused on the issue of whether there are uppercase equivalents of all lowercase glyphs in all languages. The link you provided sheds light on this The Greek alphabet does have upper

Re: Unicode

On 2015-05-06 01:53, Peter Haworth wrote: Right, this is where I get confused on the issue of whether there are uppercase equivalents of all lowercase glyphs in all languages. The link you provided sheds light on this The Greek alphabet does have upper and lower case variants. However, in t

Re: Unicode

Right, this is where I get confused on the issue of whether there are uppercase equivalents of all lowercase glyphs in all languages. The link you provided sheds light on this Pete lcSQL Software Home of lcStackBrowser and SQLiteA

Re: Unicode

Are you sure that the two Greek words are actually the same? I don’t know Greek but from a quick scan of the Unicode docs, it seems that not all Greek letters have an uppercase equivalent. Google translate cannot find a Greek translation of PETER other than PETER which is clearly not equal to Go

Re: Unicode

I tried pasting from Google translate using my first name in lower and upper case, but I still get false,false. The variable seems to be OSX vs Windows. Maybe someone from RunRev will chime in on this. If not, I'll probably enter a QCC report and see what they have to say. Pete lcSQL Software <

Re: Unicode

On 5/5/2015 1:52 PM, Peter Haworth wrote: > Interesting. I wonder why my results are different. I'm using LC 7.0.4 > and Yosemite. and get false,false no matter what caseSensitive is set to. > > If I use US keyboard, everything works as expected. It's only when keying > in Greek characters that

Re: Unicode

Greece has to pay a lot back to the EU, it must be a hack... Peter Haworth wrote: Interesting. I wonder why my results are different. I'm using LC 7.0.4 and Yosemite. and get false,false no matter what caseSensitive is set to. If I use US keyboard, everything works as expected. It's only w

Re: Unicode

Interesting. I wonder why my results are different. I'm using LC 7.0.4 and Yosemite. and get false,false no matter what caseSensitive is set to. If I use US keyboard, everything works as expected. It's only when keying in Greek characters that I always get false,false. Pete Pete lcSQL Softwar

Re: Unicode

On 5/5/2015 1:00 PM, Peter Haworth wrote: > I just set up the following test > > 2 fields and a button > > Using the Greek keyboard, I keyed "qwerty" into the first field and > "QWERTY" into the second field. > > The button script has in its mouseUp handler: > > set the caseSensitive to false > pu

Re: Unicode

I guess I'm not understanding the nuances of this. I just set up the following test 2 fields and a button Using the Greek keyboard, I keyed "qwerty" into the first field and "QWERTY" into the second field. The button script has in its mouseUp handler: set the caseSensitive to false put (toUpp

Re: Unicode

On 2015-05-04 22:31, Peter Haworth wrote: Does toUpper/toLower work? Similarly, does the setting of caseSensitive work OK when comparing textDecoded strings? All string operations support Unicode in LC 7. Obviously, "binary data" operations (e.g. "byte x to y of ...") don't! To answer yo

Re: Unicode

Great, thanks Richard. Pete lcSQL Software Home of lcStackBrowser and SQLiteAdmin On Mon, May 4, 2015 at 1:39 PM, Richard Gaskin wrote: > Peter Haworth wrote: > > Does toUpper/toLower work?

Re: Unicode

Peter Haworth wrote: > Does toUpper/toLower work? Similarly, does the setting of > caseSensitive work OK when comparing textDecoded strings? > > Can I use char references, e.g. char x to y of tVar or offset, or > do I need to use byte x to y, byteOffset? Character is safer for strings since it a

Re: Unicode/keyDown

OK, thanks Devin, just checking. On Wed Feb 18 2015 at 2:06:53 PM Devin Asay wrote: > > On Feb 18, 2015, at 2:34 PM, Peter Haworth wrote: > > > Reading the bug report, it sounds like it was only fixed in 7.0 not prior > > releases.. Have you seen it work OK in releases prior to 7.0, Devin? > >

Re: Unicode/keyDown

On Feb 18, 2015, at 2:34 PM, Peter Haworth wrote: > Reading the bug report, it sounds like it was only fixed in 7.0 not prior > releases.. Have you seen it work OK in releases prior to 7.0, Devin? Whoops, yes, I missed that detail in your original post, that you were working in 6.6.2. To my k

  1   2   3   >