Re: On CJK font selection (was Re: [Fwd: Re: Request for review and advice on wqy-bitmap-fonts fontconfig settings])
not interested. Of the bugs you listed, only the one I opened myself is valid IMO. The rest is just left open because no matter how many times I close them, they will be reopened... Oh well. please let me know your thoughts and reasoning on whether this is feasible or not, if yes, where to get start. Does the above make sense? I understand that it's easier to apply a two line patch to Pango instead of doing what of the things I listed above, but that just doesn't fit in the design, and it introduces other problems you don't see right now. thank you for paying attention to this issue. Qianqian Regards, behdad === Bug 321113 - Wrong glyph subsituation algorithm for digital characters and punctuations http://bugzilla.gnome.org/show_bug.cgi?id=321113 Bug 345072 - changes font when typing different scripts on the same line http://bugzilla.gnome.org/show_bug.cgi?id=345072 Bug 345386 - Language and direction propagation in and between PangoLayouts http://bugzilla.gnome.org/show_bug.cgi?id=345386 (opened by yourself) https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=103679 Bug 481210 - [All lang] [firefox] - Face of the number is changing when enter number + Char, in any Locale http://bugzilla.gnome.org/show_bug.cgi?id=481210 Bug 481188 - ascii text space too narrow for Chinese encodings http://bugzilla.gnome.org/show_bug.cgi?id=481188 Bugzilla Bug 129541: changes font when typing different scripts on the same line https://bugzilla.redhat.com/show_bug.cgi?id=129541 Bugzilla Bug 131218: [RHEL4] Characters get truncated in new pango https://bugzilla.redhat.com/show_bug.cgi?id=131218 Bugzilla Bug 149991: [CJK pango] digits and punctuation in textbox give bad eol rendering and cursor placement https://bugzilla.redhat.com/show_bug.cgi?id=149991 (filed by Jens Petersen) https://bugzilla.redhat.com/show_bug.cgi?id=220885 (broken link) Bugzilla Bug 228804: [All lang] [firefox] - Face of the number is changing when enter number + Char, in any Locale https://bugzilla.redhat.com/show_bug.cgi?id=228804 Bugzilla Bug 221361: [pango] ascii text space and punctuation is narrow for CJK https://bugzilla.redhat.com/show_bug.cgi?id=221361 Bug 379125 - chinese punctuations after english letters are wrongly displayed https://bugzilla.mozilla.org/show_bug.cgi?id=379125 https://bugzilla.mozilla.org/attachment.cgi?id=263185 === -- behdad http://behdad.org/ ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * My own cave: http://me.abelcheung.org/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Markup in messages
On 7/25/06, Christian Rose [EMAIL PROTECTED] wrote: Of course in most cases the proper 'fix' is to have a boldtype font. But creating a boldface font is not always that easy, when one is talking about complex scripts that consists of at least hundreds or thousands of glyphs; and it needs quite some human horsepower as well, which may not be available for newly available languages in F/OSS world. I understand that problem, but I for sure don't agree that this is the proper way to fix it, as this hack, that is, gratiously including surrounding markup inside the translateable message content, causes a lot of problems for all translators. As a translator you want to translate the *content*, not the surrounding presentation. I don't care whether the words will be written on a billboard, a folder, or on-screen, the words will be the same. As Clytie explained: [..] I didn't say my mind clearly. What I want to say is, I don't like such kind of hack either, but it has really existed before. Right now such workaround is no more needed. Abel Here are some ways to solve the problem of bad rendering: 1) Fix the fonts. Agreed, not an easy task. 2) Solve the problem at the Pango level. Instead of encouraging the use of b and i tags, add abstract strong, em tags/attributes or some such, allowing for different interpretations for different scripts. If we know that boldface fonts for Persian always suck, strong can have a different representation for Persian script. Then the HIG and other such specifications can specify these attributes instead of a particular font style. And here's how to solve the (ab)use of using surrounding PangoMarkup inside translateable messages: 3) Make gtk+/Pango have support for *attributes* instead of forcing everyone to use PangoMarkup. If I want a label to be bold, italic, smaller, or larger, I as a developer should be able to simply set attributes to that effect. Right now, it's too common to see something like this: msgid span size=\xx-large\Bug Buddy/span msgstr span size=\xx-large\Bug Buddy/span msgid span weight=\bold\Date Time/span msgstr span weight=\bold\Datum och tid/span msgid bDate Time/b msgstr bDatum och tid/b msgid span size=\medium\bNo file/b/span msgstr span size=\medium\bIngen fil/b/span msgid No file msgstr Ingen fil Often, you will have duplicated messages in the same file, just with different markup! If gtk+/Pango and libglade would make it possible for application writers to set *attributes* for these things instead of having to resort to PangoMarkup, all problems would be solved. Christian -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: [gtk-i18n-list] Unicode PUA supporting issue in gtk+/pango
On 12/24/05, Chia-I Wu [EMAIL PROTECTED] wrote: Nothing to say, even if the charset/mapping table of new HKSCS is published, the release of the font for new HKSCS will be delayed (especially high-quality scalable fonts). Therefore, even if we ignore the possibility that some fonts have all characters of HKSCS-2001 and a part of HKSCS-2004, we have to use HKSCS-2001 mapping table for the font that is compliant to HKSCS-2001 and not to HKSCS-2004. If we use HKSCS-2004 mapping table and HKSCS-2001 fonts, some PUA codepoints are mapped to undisplayable public codepoints, coversion scripts generate undisplayable string. Therefore, I think, still we have to care which standards the font is compliant...? Yes, of course. Let's quote some vendor's description of its product: All the fonts are in Unicode encoding standard and supports the Hong Kong SAR Government's Chinese Common Interface and latest version of Hong Kong Supplementary Characters Set (HKSCS-2001). You never want to upgrade your system to HKSCS-2004 unless some or all of your fonts have been upgraded to support HKSCS-2004. This is the story for COMMERCIAL fonts, which are not used in any open platforms. About open source side, Arne's font has all HKSCS-2004 glyphs ready, and is currently bundled in almost all Linux distributions (as well as shipped by default in the future). The status for other Unices are unknown for now. Interesting. Could you tell me the framework to use the font in Taiwan? Well, if the font comes with big5 cmap (platform 3, encoding 4), and you use it, not the unicode one, to look up glyph index, then you can use it in Taiwan. But this is just in theory. I don't know if there are HKSCS fonts having such cmap nor if it really works :) Arphic fonts don't have big5 cmap (at least according to ftdump). Also search fonts from a few commercial vendors, still can't find any so far. Abel pango can not do this because it uses unicode cmap to look up glyph index. -- Regards, olv ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: [gtk-i18n-list] Unicode PUA supporting issue in gtk+/pango
On 12/31/05, Abel Cheung [EMAIL PROTECTED] wrote: [] This is the story for COMMERCIAL fonts, which are not used in any open platforms. About open source side, Arne's font has all HKSCS-2004 glyphs ready, and is currently bundled in almost all Linux distributions Sorry, I mean all the major players except Novell(SuSE). Abel (as well as shipped by default in the future). The status for other Unices are unknown for now. Interesting. Could you tell me the framework to use the font in Taiwan? Well, if the font comes with big5 cmap (platform 3, encoding 4), and you use it, not the unicode one, to look up glyph index, then you can use it in Taiwan. But this is just in theory. I don't know if there are HKSCS fonts having such cmap nor if it really works :) Arphic fonts don't have big5 cmap (at least according to ftdump). Also search fonts from a few commercial vendors, still can't find any so far. Abel pango can not do this because it uses unicode cmap to look up glyph index. -- Regards, olv ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: non-latin accelerator keys
Hi, On 12/22/05, Matthias Clasen [EMAIL PROTECTED] wrote: http://bugzilla.gnome.org/show_bug.cgi?id=323956 http://bugzilla.gnome.org/show_bug.cgi?id=104112 The first bug complains about the fact that the (_F) form in which many CJK strings display the accelerator is not fully stripped out when showing the string in a toolbar, and you end up with (F) in the visible string. I am considering to change gtk_toolbar_elide_underscores() to strip not only lone _ characters, but also a sequence of the form (_single character) at the end of the string. I have a number of questions here: - Does this sound like a reasonable thing to do ? (the risk of accidentally stripping something thats not an accelerator is probably minimal, but not 0. Indeed, there can be cases where a single CJK character is enclosed inside parenthesis, and that's not uncommon; although when enclosed character is a latin character it mostly means mnemonic key. - Is the (_F) approach generally considered just a workaround for the second bug, or are there languages where it is the preferred/standard way to display accel keys ? Well, it is preferred, since multiple keystrokes are needed to input non-latin characters, and I doubt if anything like Alt-char can be entered at all. Hope anybody can enlighten me if this is possible or not. - Are there any variations of this ? Eg does any language display accel keys by prefixing the label with _f ? I have seen (and personally used it in very rare case) a key enclosed in square bracket: [_F]. But that's very rare. The other bug asks for a way to underline a character in the label, but have a different character as accel key. I wrote patches which change the Pango/GTK+ behaviour in the following way: f_oo - o underlined, accel key o f_[x]oo - o underlined, accel key x Essentially the same questions here: - Does this sound like a reasonable thing to do ? (the risk of accidentally stripping something thats not an accelerator is probably minimal, but not 0. One question not entirely related: let's say f_[x]oo, is there any hint or visual indication that the accel key is x not o? Abel - Which languages would actually benefit from this ? Ie which languages are currently forced to use the (_F) suffix approach, but would rather underline a non-latin character in the translated string ? Matthias ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: non-latin accelerator keys
On 12/22/05, Matthias Clasen [EMAIL PROTECTED] wrote: I have a number of questions here: - Does this sound like a reasonable thing to do ? (the risk of accidentally stripping something thats not an accelerator is probably minimal, but not 0. Indeed, there can be cases where a single CJK character is enclosed inside parenthesis, and that's not uncommon; although when enclosed character is a latin character it mostly means mnemonic key. But in the case of a single CJK character in parenthesis, it will likely not have an _ before it, right ? Oh yes, you're correct :-) - Is the (_F) approach generally considered just a workaround for the second bug, or are there languages where it is the preferred/standard way to display accel keys ? Well, it is preferred, since multiple keystrokes are needed to input non-latin characters, and I doubt if anything like Alt-char can be entered at all. Hope anybody can enlighten me if this is possible or not. No, as you said, you normally need multiple keystrokes, unless you use an exotic keymap. Not an exotic keymap, but an exotic keyboard that has 60,000+ keys ;-) Anyway, this is probably technically an excellent thing to do, but from usability POV it can be bad for CJK users (even if it can be implemented). The most efficient way for activating items is Alt plus a single keystroke, needing multiple keystrokes will reduce the efficiency. The problem is tied to the hardware (keyboard) instead of bug #104112 for CJK users, and I don't think too much can be done except stripping extra mnemonic keys and parenthesis. However, for other languages, I'm not sure at all, so others can shed some light on it. Greetings, Abel The other bug asks for a way to underline a character in the label, but have a different character as accel key. I wrote patches which change the Pango/GTK+ behaviour in the following way: f_oo - o underlined, accel key o f_[x]oo - o underlined, accel key x Essentially the same questions here: - Does this sound like a reasonable thing to do ? (the risk of accidentally stripping something thats not an accelerator is probably minimal, but not 0. One question not entirely related: let's say f_[x]oo, is there any hint or visual indication that the accel key is x not o? No, but the use case for this is probably situations where the user understand that the underlined 'o' means that he has to press the x key. E.g. if there is a standard input method which maps the x key to the 'o' character. I see. Something like gl_[u]ücklich, so pressing alt-u can activate the item? Matthias -- Abel Cheung (GPG Key: 0xC67186FF) Key fingerprint: 671C C7AE EFB5 110C D6D1 41EE 4152 E1F1 C671 86FF * GNOME Hong Kong - http://www.gnome.hk/ * Opensource Application Knowledge Assoc. - http://oaka.org/ ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
