Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Conversion tables between KPS 9566-2003(N. Korean) & Unicode|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||REOPENED ---||QA Contact:|
|Priority:||P3||CC:||a20202020, alex.thurgood, davidf, e.matthis, issues, khirano, ooo, pavel, stx123|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description ooprojlover 2004-08-27 06:47:25 UTC
Hi, I file this issue with the conversion tables between KPS 9566-2003(N. Korean national standard charset) and Unicode. I want KPS 9566-2003 to be accepted in OOo 2.0. KPS 9566-2003 is the advanced version of KPS 9566-97 and now is using in N. Korea. Regards, Kim
Comment 1 ooprojlover 2004-08-27 06:52:30 UTC
Created attachment 17373 [details] COnversion tables between KPS 9566-2003 & Unicode
Comment 2 ooo 2004-09-01 11:13:49 UTC
Hi Stephan, Will this make it into OOo2.0? We'd also need UI strings then for the encodings listbox to be able to select the encoding. Liz has to be involved for her strings approval after UI freeze, which in general isn't a problem for the languages and encodings listboxes. Thanks Eike
Comment 3 Stephan Bergmann 2004-09-13 11:15:43 UTC
To Kim: Thanks for the attached conversion tables. Is there a URL where they are available on the web (I add such URLs to the sal/textenc code where available)? One minor problem with the attached conversion tables is that they map unassigned characters to '?' (U+003F), so it is ambiguous whether a code maps to '?' or is unassigned---I assume that the only real '?' in KPS 9566-2003 is the single-byte character 0x3F. Also, from the given tables I guess that the characters in KPS 9566-2003 are single-byte characters in the range 0x00--0x7F, which map to the corresponding Unicode characters U+0000--U+007F, and double-byte characters in the range 0x8100--0xFEFF. To Eike: I'll add this for OOo2.0; Liz does not see any problems with adding an entry to the encodings listbox, either.
Comment 4 Stephan Bergmann 2004-09-21 16:27:55 UTC
Kim, could you please provide a plain text file encoded in KPS 9566-2003, so that I can test that reading it into OOo more-or-less works (I will just check that it displays as lots of Korean glyphs, as I do not understand Korean, but such a test should be better than nothing).
Comment 5 Stephan Bergmann 2004-09-22 16:12:04 UTC
sb->liz: As discussed, we need a new string for the N. Korean text encoding "KPS 9566-2003." That string will appear in the "Character set" list box of the "ASCII Filter Options" dialog of the "Text Encoded (*.txt)" Writer filter (AFAIK, that is the only place it will appear; the source is svx/source/dialog/txenctab.src). I propose the following strings: English: "Korean (KPS 9566-2003)" German: "Koreanisch (KPS 9566-2003)"
Comment 6 Stephan Bergmann 2004-09-27 11:04:00 UTC
fixed; unit-tests in sal/qa/rtl/textenc/rtl_textcvt.cxx
Comment 7 Stephan Bergmann 2004-10-21 15:32:38 UTC
Comment 8 Stephan Bergmann 2004-10-21 15:34:41 UTC
Comment 9 Stephan Bergmann 2004-10-21 15:35:11 UTC
Sorry, I have to turn this down. As an employee working for a US-based company that is bound to US export control laws, I'm not allowed to assist in the development of versions tailored for users in US embargoed or sanctioned countries, which North Korea unfortunately is.
Comment 10 alex.thurgood 2005-04-08 16:31:18 UTC
re-opening the issue with a question in response to sb's remarks : You personally as an employee and representative of Sun are not authorized, but what about someone else from the Community with integration and commit privileges ? Which bits of the software are forbidden from export ? As you may or may not know, the export restrictions for embargoed countries only apply to those particular bits of technology that expressly fall within the embargo's remit. Other questions : Is the embargo a pure US sanction or is it supported by a UN resolution ? The embargo must be identified somewhere as having been passed by Congress or the US Dept of State - which resolution was involved (date and identification) ? If the primary servers holding the code were located outside of the US, the Community could avoid this issue. That probably wouldn't help matters for Sun, since it might still fall under the aiding and abetting or facilitating aspect of the embargo. While I can appreciate this, it would be nice to have clarification on these different points. alex
Comment 11 pseudo_daoist 2005-04-09 22:15:37 UTC
I'll just point out that OOo _currently_ offers language support for other countries on the US Embargo List.
Comment 12 stx123 2005-04-26 10:59:23 UTC
extend cc list...
Comment 13 pavel 2005-08-05 16:02:55 UTC
So: what is the plan with this issue. Do we want to solve this for 2.0 or should we retarget it?
Comment 14 pavel 2005-09-13 08:02:39 UTC
retarget. We can't make it into 2.0.
Comment 15 pavel 2005-12-14 14:20:34 UTC
no developer, no fix in time for 2.0.1.
Comment 16 a20202020 2011-02-26 11:26:40 UTC
I think it is really late to point this out, but are the mappings of 0xA7B5 – 0xA7BE in kp-uni.txt really correct? Shouldn't they be mapped to U+3251 – U+325A instead of U+24F0 – U+24F9?
Comment 17 Rob Weir 2013-07-30 02:14:46 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.