I am not asking you for the test, although an automated jtreg test would
be welcome.
What I am asking is that the issue was tested against japanese
characters. but have you or anyone else verified the fix against other
CJK locales?
Regards
Prasanta
On 01-Jun-20 5:38 PM, Vyom Tiwari wrote:
Hi Prasanta,
sorry for the late reply, my teammate Jayashree will send you the test
by today.
Thanks,
Vyom
On Mon, Jun 1, 2020 at 5:20 PM Prasanta Sadhukhan
<prasanta.sadhuk...@oracle.com <mailto:prasanta.sadhuk...@oracle.com>>
wrote:
Hi Vyom,
On 15-May-20 12:34 PM, Prasanta Sadhukhan wrote:
Thanks Vyom. You could have proposed the patch yourself only...
Anyways, I have tested with Font2DTest with all unicodes for
default Latin and it seems ok. Will you be able to test in other
CJK locales (as I am not sure of the unicodes being displayed
correctly) just to ensure they are not adversely affected?
Any feedback on CJK locale testing with your fix? If not, I am
afraid we need to retarget this fix for jdk16.
Regards
Prasanta
Regards
Prasanta
On 14-May-20 9:01 PM, Vyom Tiwari wrote:
Hi prasanta,
Code changes look OK to me, although I am not a expert in this
area, but the same patch resolves the issue at our end.
Thanks,
Vyom
On Thu, May 14, 2020 at 4:20 PM Prasanta Sadhukhan
<prasanta.sadhuk...@oracle.com
<mailto:prasanta.sadhuk...@oracle.com>> wrote:
Hi All,
Please review a fix for an issue seen whereby RTFEditorKit
used to read Japanese characters reads some garbage characters.
The default character set used for the RTF document is set
to "ansi" in our RTFReader.java.
And share/classes/javax/swing/text/rtf/charsets/ansi.txt
code table has undefined values , i.e., 91-98 and A0 are
"0". According to javax/swing/text/rtf/RTFParser.java, If
the ch is 0, handleText() is not called
As per http://www.biblioscape.com/rtf15_spec.htm#Heading8,
/RTF file includes the following Character set in its header
: //
//<character set> //
// (\ansi | \mac | \pc | \pca)? \ansicpgN? //
//Where, //
//\ansicpgN This keyword represents the default ANSI code
page used to perform the *Unicode to ANSI conversion* when
writing RTF text. N represents the code page in decimal.
This is typically set to the default ANSI code page of the
run-time environment (for example, \ansicpg1252 for U.S.
Windows). The reader can use the same ANSI code page to
convert ANSI text back to Unicode. This keyword should be
emitted in the RTF header section right after the \ansi,
\mac, \pc or \pca keyword. /
Possible values include those in the following table.We can
make use of ansicpgN (can switch ANSI text to Unicode),
define it to refer to the latin1TranslationTable [RTFParser
inherits it from AbstractFilter] which does not include
undefined areas instead of ansi's translationTable which has
undefined areas as seen above.
Bug: https://bugs.openjdk.java.net/browse/JDK-8244324
webrev: http://cr.openjdk.java.net/~psadhukhan/8244324/webrev.0/
Note: I am not able to create a testcase for this as it
involves reading from rtf file which probably is copyrighted
and inserting Japanese characters as a string (instead of
rtf file) was not working.
--
Thanks,
Vyom
--
Thanks,
Vyom
