acceptability of Chinese-Traditional character substitute

[John Boncek]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On an embedded Linux / GTK 2.10 / Pango system with limited font and memory resources, we have CJK font support via the latest release of X11R7.3, using only the "misc-misc" fonts.  We have found a missing character, U+555F.  The online Unihan database at

 

http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=555F&useutf8=false

 

shows this character to have a "semantic variant" U+5553.  Would it be considered acceptable to programmatically replace the missing character with this one?  I know this is not an ideal solution.  If this is not considered acceptable, can you suggest some other solution?  Adding one of the massive CJK fonts like Wen Quan Yi is not an option for this system.  Thanks for your attention.

 

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[FangQ]

IMO, the substitution is OK if there is no other better solution, as
these characters
are pretty much identical in their meanings. However, different regions
of users
may still prefer one to the other, it may look weird  when see different
forms than
what they were taught in school (for simplified Chinese users, we use U542F
instead) although they are still able to understand the meanings.

But, why not patch your font data to add this missing glyph?

Just out of my curiosity, what is the footprint requirement for your
Chinese font?
are they bitmap or vector? Using a single strike of WenQuanYi's bitmap font
can be pretty small; it can be even smaller by using the GB2312/Big5 subset.

Qianqian

Boncek, John wrote:

> On an embedded Linux / GTK 2.10 / Pango system with limited font and
> memory resources, we have CJK font support via the latest release of
> X11R7.3, using only the "misc-misc" fonts.  We have found a missing
> character, U+555F.  The online Unihan database at
>  
> _http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=555F&useutf8=false_
> <http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=555F&useutf8=false>
>  
> shows this character to have a "semantic variant" U+5553.  Would it be
> considered acceptable to programmatically replace the missing
> character with this one?  I know this is not an ideal solution.  If
> this is not considered acceptable, can you suggest some other
> solution?  Adding one of the massive CJK fonts like Wen Quan Yi is not
> an option for this system.  Thanks for your attention.
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>  

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[John Boncek]

Thanks for your reply, Qianqian.  I had coded up the small change to do the substitution already, so I think we'll stay with that for the time being.  Your other suggestions go beyond what we really know how to do at this point and it seems that any time we try something very new we get unintended consequences.  Thanks again.

John

-----Original Message-----
From: Qianqian Fang [mailto:fangqq@...]
Sent: Tuesday, June 17, 2008 12:15 PM
To: Boncek, John
Cc: gtk-i18n-list@...
Subject: Re: acceptability of Chinese-Traditional character substitute

IMO, the substitution is OK if there is no other better solution, as
these characters
are pretty much identical in their meanings. However, different regions
of users
may still prefer one to the other, it may look weird  when see different
forms than
what they were taught in school (for simplified Chinese users, we use U542F
instead) although they are still able to understand the meanings.

But, why not patch your font data to add this missing glyph?

Just out of my curiosity, what is the footprint requirement for your
Chinese font?
are they bitmap or vector? Using a single strike of WenQuanYi's bitmap font
can be pretty small; it can be even smaller by using the GB2312/Big5 subset.

Qianqian

Boncek, John wrote:

> On an embedded Linux / GTK 2.10 / Pango system with limited font and
> memory resources, we have CJK font support via the latest release of
> X11R7.3, using only the "misc-misc" fonts.  We have found a missing
> character, U+555F.  The online Unihan database at
>
> _http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=555F&useutf8=false_
> <http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=555F&useutf8=false>
>
> shows this character to have a "semantic variant" U+5553.  Would it be
> considered acceptable to programmatically replace the missing
> character with this one?  I know this is not an ideal solution.  If
> this is not considered acceptable, can you suggest some other
> solution?  Adding one of the massive CJK fonts like Wen Quan Yi is not
> an option for this system.  Thanks for your attention.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list