Page 1 of 3

issue-#44 unicode content of links&targets saving wrong way

Posted: Wed Apr 29, 2015 3:04 pm
by Ivan Denisov
http://redmine.blackboxframework.org/issues/44

If the links & targets contain unicode content (tested for Cyrillic) it is damaging during Exteralize/Internalize.

Code: Select all

the link before save
<проверка>some link<>

the link after save, open and expanding
<?@>25@:0>some link<>
This bug is still persisting in CPC 1.7-RC6 also.

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Wed Apr 29, 2015 7:20 pm
by Ivan Denisov
I aggregated the experience from OberonCore:B2 fix and CPC version, so Cyrillic saving and restoring well.
http://redmine.blackboxframework.org/pr ... 4b15c28ec5
This is demo: blackbox-1.7-a1.124.zip

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Wed Apr 29, 2015 8:40 pm
by Ivan Denisov
Few words about versions:

0 - default behaviour: close window if shift is down, never close if link contains ShowTarget (not storing v.close);
1 - unusual behaviour: always close window or never close (storing v.close state);
2 - always storing v.close state and storing v.cmd as widechars;

So detection of 2 should go first, not after 0 like in CPC version.

Code: Select all

IF HasWideChars THEN
 version := 2
ELSE default behaviour THEN
 version := 0
ELSE
 version := 1
END;

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Sat May 02, 2015 6:40 am
by Zinn
When detection of 2 should go first, why you don't simplify to

Code: Select all

IF HasWideChars THEN
 version := 2
ELSE
 version := 1
END;
or just to

Code: Select all

 version := 2
?

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Sat May 02, 2015 1:57 pm
by Ivan Denisov
Zinn wrote:When detection of 2 should go first, why you don't simplify to ... ?
It will break some back compatibility for regular ASCII links.

Added later:
I mean that in this case if you prepare some document with our Center BB, it will not open in old versions. However with such versions keeping strategy if your link does not contain wide chars, it will be compatible with old versions.

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Sat May 02, 2015 4:47 pm
by Zinn
My first succesion is backward compatible. We needn't add 0 again.

Further there was already a discussion about the backward compatibility.
It's result was we don't need them. (See StdStamps)

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Sun May 03, 2015 2:21 am
by Ivan Denisov

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Tue May 05, 2015 7:59 pm
by Josef Templ
There is no reason for giving up backward compatibility here.
Saving a few lines is not worh introducing an unnecessary
incompatibility with the document format.
This would really be a great mistake.

- Josef

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Wed May 06, 2015 1:27 am
by Ivan Denisov
Josef Templ wrote:There is no reason for giving up backward compatibility here.
Saving a few lines is not worh introducing an unnecessary
incompatibility with the document format.
This would really be a great mistake.
Josef, do I understand right, that you want to keep 0 version?

It can be replaced to 1 in 1.5 and 1.6. So theoretically it can break compatibility only for very old versions of BB.

Re: issue-#44 unicode content of links&targets saving wrong

Posted: Wed May 06, 2015 6:28 am
by Josef Templ
I did not have the time to look into the details of the implementation yet,
so I really don't know what version 0 or 1 or 2 means. Anyway, I am surprised
that this issue has not been fixed in CPC 1.7.

- Josef