88922 - rendering of non-KS X 1001 Hangul syllables should omit leading 0xADF4

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement)

Description

[Jungshik Shin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19-5mdksecure i586; en-US; rv:0.9.1)
Gecko/20010607
BuildID:    20010607

The fix for bug 9961 enabled rendering of 8822 syllables (not
encoded in pre-composed form in KS X 1001(formerly
KS C 5601 and refered to as such in Mozilla source) and thus not available
in font with the encoding ksc5601.1987-0) as a sequence of
4 characters (8 octets) with the lead character 0xADF4(in EUC-KR
encoding. in ksc5601.1987-0 encoding - KS X 1001 GL encoding -,
it's 0x2D74). When converting to KS X 1001-based-encoding
(such as EUC-KR), this lead character should be included.
However, for rendering on the screen(and in print), this lead
character is redundant and takes unncessary space. Therefore,
UnicodeToKSC5601 converter (used for Unicode -> ksc5601.1987-0
font encoding) should produce 6byte sequence (omitting the
lead character at 0x2D74) while UnicodeToEUCKR converter 
should remain as it is now. 

This can be achieved by modifying intl/uconv/src/ugen.c a little
bit. The patch will be attached to a meta-bug I'm going to
file (which will deal with all Korean converter related
bugs/enhancement requests).


Reproducible: Always
Steps to Reproduce:
1.Fire up Mozilla in Unix/X11
2.Set fonts for Korean to one of Daewoo fonts
  (
-daewoo-mincho-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0)
  in all 5 styles (serif, sans-serif, monospace, fixed, fantastic)
3. View the URL above 

Actual Results:  Each Hangul syllable (without pre-composed glyph in 
ksc5601.1987-0 font) is rendered as 4 characters
(1 'blank' glyph for 0x2D74 followed by three glyphs
for Hangul alphabets, initial consonant, medial vowel,
and final consonant). 

Expected Results:  The leading 'blank' glyph is not necessary for rendering
purpose so that they should be omitted. Instead of 4-character
sequence, 3-character sequence should be used.

A possible objection to this fix/enhancement
is that uCnGAlways8BytesGLComposedHangul() (modified
and renamed as uCnGAlways6BytesGLDecomposedHangul()) will be also
used for not-yet-implemented UnicodeToISO2022KR converter.
However, Mozilla will never have to generate ISO-2022-KR
output (although it needs to have ISO2022KRToUnicode converter)
so that this cannot be of concern. Moreover, in very very
unlikely case of having to produce ISO-2022-KR in the output
stream,
we can add another scan function and charset category
for ISO-2022-KR generation.

Comment 1

[nhottanscp]

Reassign to ftang.

Comment 2

[nhottanscp]

*** Bug 88921 has been marked as a duplicate of this bug. ***

Comment 3

[Andreas Becker]

Switching QA contact to [e-mail] for now.

Comment 4

[Frank Tang]

reassign to [e-mail]
is it done?
if so, mark it closed
if not, propose patch and reassign back to me.

Comment 5

[Jungshik Shin]

Yes, it's fixed by 88944. How can I change status? Bugzilla interface
has changed and there's no choice available for Status and Resolution fields.
Could you close it? 

Comment 6

[Jungshik Shin]

Sorry I logged in as [e-mail] and that's why I couldn't change
status. Now I'm gonna mark it as closed/resolved.

Comment 7

[Teruko Kobayashi]

Verified as fixed.