Apache OpenOffice (AOO) Bugzilla – Issue 33466
Conversion tables between KPS 9566-2003(N. Korean) & Unicode
Last modified: 2013-08-07 15:00:01 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
Created attachment 17373 [details] COnversion tables between KPS 9566-2003 & Unicode
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
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.
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).
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)"
fixed; unit-tests in sal/qa/rtl/textenc/rtl_textcvt.cxx
.
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.
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
I'll just point out that OOo _currently_ offers language support for other countries on the US Embargo List.
extend cc list...
So: what is the plan with this issue. Do we want to solve this for 2.0 or should we retarget it?
retarget. We can't make it into 2.0.
no developer, no fix in time for 2.0.1.
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?
Reset assignee on issues not touched by assignee in more than 2000 days.