<i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries on MS950 charset
naoto.sato at oracle.com
naoto.sato at oracle.com
Wed Oct 30 16:25:21 UTC 2019
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
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.
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" ,
> I tried "Create CSR" operation, but I could not determine it worked or
> (Select "Create CSR" from "More" menu)
> It worked ?
>  https://wiki.openjdk.java.net/display/csr/CSR+FAQs
> Ichiroh Takiguchi
> On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>>> 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
>>> 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.
>>> 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.
>>> Ichiroh Takiguchi
>>> On 2019-10-19 16:36, Alan Bateman wrote:
>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>>> 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 
>>>> 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.
More information about the i18n-dev