Hello Sato-san.
I could not find any specific reason for this issue.
I said "1-way trip conversion", I should say "round trip conversion".
bestfit950.txt has many 1-way trip entries for Unicode to MS950
conversion.
At least, I think round trip conversion needs to be consistent between
Windows and Java.
Thanks,
Ichiroh Takiguchi
On 2019-10-31 01:25, naoto.s...@oracle.com wrote:
Takiguchi-san,
Personally I am reluctant to make this change. If we were to introduce
this, it will be a different encoding from the existing MS950, so
either 1) we need a new encoding, or 2) make some switch between the
encoding, possibly a system property. But neither seems worth doing,
as :-
1) JDK's conversion is not a bug per se.
2) Seems that Unicode.org's "best fit" was introduced around 2006?
(From the date on the unicode.org
(https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt),
so JDK's mapping predates it.
3) Those code points are not a common ones (BOX DRAWINGS), and no
customer had a complaint about it.
Please let me know if there are some rationale for fixing it.
BTW, as to the CSR, I don't see it was created.
Naoto
On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote:
Thanks, Sato-san.
There is no special meaning to the word "until now".
I rewrote charset related testcases, then I found this issue.
I read "Frequently Asked Questions about the CSR" [1],
I tried "Create CSR" operation, but I could not determine it worked or
not...
(Select "Create CSR" from "More" menu)
It worked ?
[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
Thanks,
Ichiroh Takiguchi
On 2019-10-29 03:03, naoto.s...@oracle.com wrote:
Hi Takiguchi-san,
On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
Hello.
I have no idea about compatibility impact.
But according to
ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
These are BOX DRAWINGS characters.
2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE
HORIZONTAL;;;;
255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT
DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;;
2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT
DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND LEFT DOUBLE;;;;
256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL
DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
I don't think it was used as valuable data until now.
I think it's necessary to evaluate compatibility.
What do you mean by "until now"? Are there customers claiming that it
should be corrected? Since the current JDK's mapping is not incorrect
per se (not just "best match"), I would like to know why this needs
to
be fixed now.
Naoto
To Sato-san,
if you have any question and suggestion, please let me know.
To other reviewers,
please let me know if you have any question and concern.
Thanks,
Ichiroh Takiguchi
On 2019-10-19 16:36, Alan Bateman wrote:
On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
Hello.
Could you review the fix ?
Bug: https://bugs.openjdk.java.net/browse/JDK-8232161
Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
I have a concern about 1-way trip conversion entries (4 entries)
on MS950 charset.
The detail information is in JDK-8232161 [1]
Do you know any sense on the compatibility impact of changing this?
I
think Naoto has the same question and we aren't sure if this one
with
need a compatibility property. I think it will need a CSR.
-Alan
