Issue 33466

Summary: Conversion tables between KPS 9566-2003(N. Korean) & Unicode
Product: Internationalization Reporter: ooprojlover <ooprojlover>
Component: codeAssignee: AOO issues mailing list <issues>
Status: REOPENED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: a20202020, alex.thurgood, davidf, e.matthis, issues, khirano, ooo, pavel, stx123
Version: 680   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---
Description Flags
COnversion tables between KPS 9566-2003 & Unicode none

Description ooprojlover 2004-08-27 06:47:25 UTC

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. 

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.

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.

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.