| Author |
 Topic  |
|
|
voland255
Starting Member
9 Posts |
 Posted - 03 Feb 2010 : 17:29:51
|
Dear Alessio,
you make a wonderful programm. Thank you. 
But can you explain please, why entire program, mainly including Script Manager, work exclusively in non-Unicode mode?? 
I count that this is big disadvantage. Mainly because scripts is written in ANSI format - therefore I can't convert symbols with #SUBSTITUTEWORD# to really any worldwide symbol, this possible only to local ANSI, non-Unicode character set, as described in Control Panel in Regional Options. Any symbol from another character set will unreadable, especial non-European, e.g. Russian.
The reason is that scripts *.txt files are written (and read by MagicScript) in ANSI mode.
#SUBSTITUTEWORD# returns an symbol in react to HTML code like " & #x44F; ", returned by movie server. Probably it there is RIGHT BECAUSE we want to handle ALL symbols So probably in substitution table EXPECTED that I could say "this is equal to Russion 'ja'."
But unfortunately table for substitusion are saved in file with ANSI local coding, and my locale is currently Czech. So all Russian characters, downloaded from IMDB, e.g. movie's AKAs, will unreadable for me.
Generally, when IMDB returns symbols not in current system non-Unicode locale, they ARE unreadable, because are mapped on inaproppriate symbols.
Of course, if you try to write after #SUBSTITUTEWORD# Unocide symbol in ANSI-coded file, they changed to "?" symbols immediately after save. 
Solution? Simple.
Let MagicScript read and manipulate with Unicode-coded *.txt files. And then user will can write down to his #SUBSTITUTEWORD#s real German, Russian, Danish, French, etc. symbols.
And more than this, you can make separate convertion table, in separate files, one for all scripts, and free hands to script creators...
Thank you and good luck 
V.
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
Posted - 04 Feb 2010 : 07:01:00
|
Hi!
Thank you for your hints!
I am sorry I haven't fix it yet, but the truth is that I don't know exactly how to do it.
I think XMM should aready handle unicoded txt files.
Please make a test for me: take a script and save it to Unicode TXT file (with wordpad for example).
Then modify it and take a look if works correctly or not. You can also try to load it in MagicScript editor to see if XMM load it in the unicode or not.
Thank you!
Ale |
http://www.facebook.com/pages/eXtreme-Movie-Manager/47220214342?ref=mf
 |
 |
|
|
Prinz
Senior Member
Germany
1522 Posts |
Posted - 04 Feb 2010 : 13:26:02
|
| Magic Script and the Editor doesn't read UNICODE txt Files, just convert a normal Script to UNICODE and it will not load anymore. The Database it self and Dialogs can handle UNICODE, but MOVIECARDS will show UNICODE Chars as ? , because there Fonts aren't UNICODE. |
|
|
|
voland255
Starting Member
9 Posts |
Posted - 04 Feb 2010 : 18:27:19
|
To Prinz:
I disagree, my friend. Fonts in MOVIECARDS are Unicode. But this fonts can show only what you tell they to show Please take a look at your scripts AFTER you open it in Notepad, write down Unicode symbols and save it (as ANSI of cource). You will see "?" in plase of Unicode characters...
V. |
|
|
|
voland255
Starting Member
9 Posts |
Posted - 04 Feb 2010 : 18:28:03
|
To Alessio:
Do you really think that I may write all that before without try to load Unicode script in editor or try to use that kind of script direct in XMM?? 
Of course yes. As first try... But  . Script editor do nothing, like file was empty. XMM freeze. 
From other side, for your attention, data in DB are stored in Unicode. This is because MS Access IS Unicode-based and DO conversion, appropriate to codepage conversion tables, installed on PC (Control Panel/Regional Options/Advanced).
So XMM:
- get Unicode input from keyboard, translate it to CGI codes like "%E3", and send this codes to server like IMDB
- then receive HTML codes like "& #1103;" and "Д ›", and translate it by #SUBSTITUTEWORD# to ANSI (!) codes
- this ANSI symbols are shown in XMM (as is) - e.g. in "MagicScript Import Engine" window where user (during process of webquery) make choice of the right movie from "Title Found" movie list (to next to read right page from server); or in native XMM "QuickEditView" window where movie Title or OriginalTitle are edited manually
- then that ANSI data are sent to Unicode MS Access database, where are automatically saved in Unicode format - but AS IS, without translation.
This mean that if my locale IS accidentally equal with locale of symbols, returned by #SUBSTITUTEWORD#, everything is VISUALLY ok. More then this, records in DB are in right format! You may later change locale on PC and you will see exactly the same Title of movie.
Well. But if #SUBSTITUTEWORD# will send to screen ANSI russian symbols on PC with non-Russian locale, you will see unreadable string, like "Морозко", not "#1052;#1086;#1088;#1086;#1079;#1082;#1086;" (there was "Morozko" in Russian ). This symbols will stored to MS Access in this format, without any change, and reamin in this shape independently on later locale change.
Let's do experiment
I suppose you have an Italian local on your PC. So please try to find movie named "Morozko", 1964, by script kinopoisk.ru. There will be more than one choice, therefore you will be asked for choose the right movie. But, opp-la, script was written on Russian ANSI! XMM send to script correct info, script will find proper film, but show you as "Морозко". Please choose the first, with 1964. When you choose it, the appropriate info will sucsessfully load. Correctly. In non-readable ANSI
Well.
Solution is... allow #SUBSTITUTEWORD# to return truly international (=Unicode) symbols. This is however possibly only when script is saved in Unicode format. E.g. by Notepad...
There IS also ANOTHER solution as well!! 
Change locale to another language, restart PC, load non-locale movie, change locale to language 2, restart PC, load another movie with locale 2, change locale to native language, restart PC, load another movie with native locale...   
And in this case all records will be correct in the database after all that dances! You of cource mustn't use chains with locale-mixed scripts...
I think that every person, who collects non-locale movies and want to see OriginalTitle in true ORIGINAL language in XMM even in non-local language, will be very grateful for this possibility. If they will can
Thank you.
V.
P.S. I know, you don't speak Russian, I red this in your messages on this forum. So if you want know how look "Morozko" in Russian locale, take a look there: http://www.google.com/search?q=%D0%9C%D0%BE%D1%80%D0%BE%D0%B7%D0%BA%D0%BE&rls=com.microsoft:cs:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7SKPB_cs
And... this is not my best favorite movie |
Edited by - voland255 on 06 Feb 2010 13:38:43 |
|
|
|
Prinz
Senior Member
Germany
1522 Posts |
Posted - 04 Feb 2010 : 19:04:31
|
quote:
Originally posted by voland255
To Prinz:
I disagree, my friend. Fonts in MOVIECARDS are Unicode. But this fonts can show only what you tell they to show Please take a look at your scripts AFTER you open it in Notepad, write down Unicode symbols and save it (as ANSI of cource). You will see "?" in plase of Unicode characters...
V.
My Test was the following:
I used MS Access to put directly Unicode Data in the Database. It will be correctly shown in the Grid and Dialogs. Not on the Standard - Moviecard, there will be ? instead, because the Fonts used there only have the normal ANSI Char-Set. You can even copy Unicode directly into the Dialog. Only Fonts like: Arial Unicode (a 22 MB Font!) can show all Chars.
I also think it's possible and likely that the variables in the Moviecards aren't Unicode Data.
It's depending on the MovieCard of course. The MovieCards aren't the Problem. These can be adapted. |
Edited by - Prinz on 04 Feb 2010 19:16:46 |
|
|
|
voland255
Starting Member
9 Posts |
Posted - 04 Feb 2010 : 19:23:53
|
quote:
Originally posted by Prinz
I used MS Access to put directly Unicode Data in the Database. It will be correctly shown in the Grid and Dialogs. Not on the Standard - Moviecard, there will be ? instead, because the Fonts used there only have the normal ANSI Char-Set.
You right. There is the next bug I never take a look at the "HTML Card" view.
And of cource, everyone can edit your own DefaultHTMLCard.htm on your own Pc... but there is not right solution, you know... |
Edited by - voland255 on 05 Feb 2010 08:21:05 |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
| |
Topic |
|
|
|
ANSI vs Unicode. Problems since 2005 8-|