[Bug 499902] New: Restructure the fontconfig settings for CJK languages
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Restructure the fontconfig settings for CJK languages
https://bugzilla.redhat.com/show_bug.cgi?id=499902
Summary: Restructure the fontconfig settings for CJK languages
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: fangqq(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, petersen(a)redhat.com,
nicolas.mailhot(a)laposte.net, besfahbo(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Created an attachment (id=343146)
--> (https://bugzilla.redhat.com/attachment.cgi?id=343146)
language specific fontconfig settings for Japanese
The CJK language fontconfig settings has been a long-standing issue ever since
the beginning of using fontconfig. There hasn't been a good solution yet. The
major difficulties for causing this problem, IMO, include
1. the default 65-nonlatin.conf was badly outdated with unoptimized font orders
2. there are no CJK language-specific fontconfig files, therefore, to override
the default orders, one has to add font prefer list in the fontconfig settings
shipped with individual CJK font package.
3. because these settings were scattered into many font packages, this further
makes the problem complex, and the conflict between different CJK font packages
became more and more frequent.
To solve this issue, I propose the following solution
1. update 65-nonlatin.conf and setup an optimized and up-to-date font list
2. add language specific fontconfig settings, defining font preferred orders
with for a given lang tag, and assign these files a lower number than 65
3. remove all font order settings from all CJK related font packages
For solution step 1, I proposed a completely updated 65-nonlatin.conf at
http://bugs.freedesktop.org/show_bug.cgi?id=20911 . My rationale of the font
orders was also explained in details.
For solution step 2, I created two default settings for ja and zh locales (that
for ko can be done similarly) as examples, and you can find them in the
attachments. Because I used lang tag matching in the rules, these files can be
installed concurrently (in this sense, it is better than the language-selector
in Ubuntu, which needs to run fontconfig-voodoo to link a set of active config
under a given language).
I did the following to test this proposal. From what I saw for zh-*, ja and en
locales, all the wanted features were working properly.
Here are the details of my test:
First, I did this test with rawhide updated this morning. On the system, I
installed chinese-support and japanese-support, including wqy-bitmap-fonts,
wqy-zenhei-fonts, arphic-uming, vlgothic-fonts and some mincho Japanese font.
To clean up all the font config settings, I "su" to root, and run the following
cd /etc/fonts/conf.d/
mkdir cjk
mv *wqy* cjk
mv *vlgo* cjk
mv *arphic* cjk
mv *gothic* cjk
This is just a quick way to get rid of all the font-wise preference settings.
In the future, most of these files can stay, as long as they remove the blocks
to set <prefer> or prepend family names.
The second step is to update (of course, make a backup first) the
65-nonlatin.conf by downloading from the attachment at
http://bugs.freedesktop.org/show_bug.cgi?id=20911
Then, download the 55-language_fonts_ja-jp.conf and
55-language_fonts_zh-cn.conf from this thread and save them under
/etc/fonts/conf.d/ . This completes the settings.
For Chinese users, some of them prefer bitmap glyphs for Han characters (35%),
some prefer vectors (65%). This is controlled by installing wqy-bitmap-fonts or
uninstalling the bitmap fonts.
I tested my proposed settings for English, Japanese and Chinese languages, with
bitmap preferred settings and vector preferred settings. My screenshots for all
combination can be found at this online album:
http://picasaweb.google.com/fangqq/ProposalForFontconfigSettingsForCJKLan...
When bitmap font is installed, for en and zh desktops, fonts at sizes 9pt ~
12pt will be rendered as bitmaps for all font aliases (sans,serif, mono);
otherwise, it will be rendered by the respective vector fonts. Particularly,
for en desktop, no more font-mosaic problems caused by high priority of
Japanese fonts (such as
http://picasaweb.google.com/fangqq/ConfigScreenshot#5333302146968242258) . When
one remove the bitmap fonts, all Hanzi glyphs were rendered by the preferred
vector fonts, as expected (some remaining ones are from UMing, which I did not
disable).
For ja desktop, all fonts were rendered by their preferred vector fonts, no
matter bitmap Chinese fonts installed or not (please ignore "驿" and "阵" as they
are not defined in JIS).
I believe this approach greatly simplifies the CJK font settings by
centralizing the related settings to language specific files. All the expected
basic rendering order were achieved with the current proposed config files. Of
course one can fine-tune them further. For Korean users, a
55-language-fonts-ko.conf file can be made similarly.
It will be really great if this proposal can be tested and agreed by all CJK
font package maintainers.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 2 months
[Bug 492510] New: Regression: wqy-bitmap-fonts preferred font over truetype fonts
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Regression: wqy-bitmap-fonts preferred font over truetype fonts
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Summary: Regression: wqy-bitmap-fonts preferred font over
truetype fonts
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: wqy-bitmap-fonts
AssignedTo: fangqq(a)gmail.com
ReportedBy: wtogami(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, fangqq(a)gmail.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Failure Case 1: gramps PDF generation
=====================================
gramps is a genealogy application that generates PDF charts. It seems to ask
pango to choose fonts for it based upon given glyphs.
* In Fedora 10, it successfully output charts using entirely truetype fonts.
* In Fedora 11 however, the UTF-8 Chinese characters are rendered in PDF as
bitmap fonts, which do not scale properly and are ugly compared to the truetype
equivalents.
http://bugzilla.gnome.org/show_bug.cgi?id=576890
Behdad proposes this bug upstream, which would workaround this type of issue at
least for vector rendering cases like PDF generation. I am uncertain if this
is correct though, and it creates possibly inconsistent behavior?
Failure Case 2: pango-view
==========================
Here is a similar way to reproduce this bug:
LANG=en_US.utf8 pango-view --text "日本語 test" --font "100"
LANG=zh_CN.utf8 pango-view --text "日本語 test" --font "100"
English pango renders the Chinese characters as ugly bitmap.
Chinese pango renders the Chinese characters as truetype.
Workaround: uninstall wqy-bitmap-fonts
======================================
Both of the above problems go away if you uninstall wqy-bitmap-fonts. But this
should not be necessary.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 3 months
[Bug 484536] New: various smc-fonts have wrong default glyphs
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: various smc-fonts have wrong default glyphs
https://bugzilla.redhat.com/show_bug.cgi?id=484536
Summary: various smc-fonts have wrong default glyphs
Product: Fedora
Version: rawhide
Platform: All
OS/Version: All
Status: NEW
Severity: medium
Priority: low
Component: smc-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: roozbeh(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, rajeeshknambiar(a)gmail.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Various fonts in the smc-fonts package, especially smc-fonts-meera, which is
installed on every Fedora machine because of being being "default" in compts,
have default glyphs shaped like an R in circle for some Malayalam characters.
For example, Meera has the following default glyphs in places that it should
not have: U+0D44, U+0D62, U+0D63, U+0D71, U+0D72, U+0D73, U+0D74, U+0D79,
U+0D7A, U+0D7B U+0D7C, U+0D7D, U+0D7E, U+0D7F
Also, there are several default glyphs in places that Unicode may use for
future encoding of Malayalam characters, like U+0D00 and U+0D29.
All those R in cirlces should be removed from the font, to make the font
Unicode-complying. Alternatively, Meera can be replaced by a standard font.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 3 months
[Bug 455510] New: Undisplayable glyphs on Wikipedia
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=455510
Summary: Undisplayable glyphs on Wikipedia
Product: Fedora
Version: 9
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: beland(a)alum.mit.edu
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
I did a fresh installation of Fedora 9 using the network install method and
adding Office/Productivity software in addition to the default set. I'm seeing
undisplayable glyphs on the following pages:
http://en.wikipedia.org/wiki/Punctuation#Unicode
http://www.wikipedia.org/
http://en.wikipedia.org/wiki/Phoenician_alphabet#Encoding
I would expect a default installation to be able to display all glyphs that
appear in Wikipedia, so that readers can learn about them. Many non-English
glyphs, even fairly obscure ones, are displayed properly, which is excellent.
It would be nice to finish off the rest. I don't know if this is a flaw in
Pango, if I would need to install additional font RPMs, or something else.
This is with firefox-3.0-1.fc9.i386 and pango-1.20.4-1.fc9.i386.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
14 years, 4 months
[Bug 507637] New: Missing fontset info
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Missing fontset info
https://bugzilla.redhat.com/show_bug.cgi?id=507637
Summary: Missing fontset info
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: cjkuni-fonts
AssignedTo: cchance(a)redhat.com
ReportedBy: loganjerry(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: cchance(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Description of problem:
At least one Kai font is missing a fontset info field. See bz 489145 comment
#27 for a description of how this problem was tracked down. Also, try this:
$ xlsfonts -fn "-*-*-*-*-*-*-*-*-*-*-*-*-ISO8859-13"
-misc-ar pl ukai cn-medium-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl ukai cn-medium-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl ukai hk-medium-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl ukai hk-medium-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl ukai tw mbe-medium-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl ukai tw mbe-medium-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl ukai tw-medium-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl ukai tw-medium-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl uming cn-light-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl uming cn-light-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl uming hk-light-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl uming hk-light-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl uming tw mbe-light-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl uming tw mbe-light-r-normal--17-120-100-100-c-0-iso8859-13
-misc-ar pl uming tw-light-r-normal--0-0-0-0-c-0-iso8859-13
-misc-ar pl uming tw-light-r-normal--17-120-100-100-c-0-iso8859-13
$ xlsfonts -l -fn "-*-*-*-*-*-*-*-*-*-*-*-*-ISO8859-13"
xlsfonts: pattern "-*-*-*-*-*-*-*-*-*-*-*-*-ISO8859-13" unmatched
The "-l" option fails because of the missing info.
Version-Release number of selected component (if applicable):
cjkuni-uming-fonts-0.2.20080216.1-23.fc11.noarch
How reproducible:
Always.
Steps to Reproduce:
1. Use the xlsfonts commands above.
Actual results:
xlsfonts without "-l" lists matching font names, but xlsfonts with "-l" errors
out because of the missing fontset info, causing it to print no matches.
Expected results:
"xlsfonts -l" should print information about each matching font.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 4 months
[Bug 485050] New: Unicode 5.1 support in pango - Indic Lanuages
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Unicode 5.1 support in pango - Indic Lanuages
https://bugzilla.redhat.com/show_bug.cgi?id=485050
Summary: Unicode 5.1 support in pango - Indic Lanuages
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: rbhalera(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
There are few characters added to Indic codespace in Unicode 5.1. They are
currently not handled according to their properties/script mechanism. Thus
there needs support for these characters to be added to pango for proper
rendering. List of these characters can be found here:
http://rahulpmb.blogspot.com/2008/04/unicode-5.html
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 4 months
[Bug 502565] New: CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: CVE-2006-1861 CVE-2007-2754 Multiple freetype1 vulnerabilities [Fedora rawhide]
https://bugzilla.redhat.com/show_bug.cgi?id=502565
Summary: CVE-2006-1861 CVE-2007-2754 Multiple freetype1
vulnerabilities [Fedora rawhide]
Product: Fedora
Version: rawhide
Platform: All
URL: http://fedoraproject.org/wiki/Security/TrackingBugs
OS/Version: Linux
Status: NEW
Keywords: Security
Severity: medium
Priority: medium
Component: freetype1
AssignedTo: ajax(a)redhat.com
ReportedBy: thoger(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
This is an automatically created tracking bug! It was created to ensure that
one or more security vulnerabilities are fixed in all affected branches.
You should *not* refer to this bug publicly, as it is a private "Fedora Project
Contributors" bug.
For comments that are specific to the vulnerability please use bugs filed
against "Security Response" product referenced in "Blocks" field.
bug #484437: CVE-2006-1861 freetype: multiple integer overflow vulnerabilities
bug #240200: CVE-2007-2754 freetype integer overflow
Please close this bug with RAWHIDE (referencing appropriate N-V-R in Fixed In
field if possible) once is it fixed in devel branch. Do *not* include the bug
id of this bug in the RPM changelog and the commit message.
For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 5 months
[Bug 497311] New: Dependent Vowel (0CBC) are Render as Independenet vowel
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Dependent Vowel (0CBC) are Render as Independenet vowel
https://bugzilla.redhat.com/show_bug.cgi?id=497311
Summary: Dependent Vowel (0CBC) are Render as Independenet
vowel
Product: Fedora
Version: 10
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: mshao(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Depends on: 497292
Classification: Fedora
Target Release: ---
Clone Of: 497292
+++ This bug was initially created as a clone of Bug #497292 +++
Description of problem:
U+0CBC (unicode points) is not showing Dotted circle before it,
so Render as Independent Vowel, but it is Dependent, so one Dotted Circle
should be there (Unicode also support that only)
Version-Release number of selected component (if applicable):
pango-1.14.9-3.el5
also reproduce in pango-1.22.1-1.fc10.i386
How reproducible: Everytime
Steps to Reproduce:
1.Type the unicode of U+0CBC in gedit
2. Test with kedit
3.
Actual results:
character is as inDependent vowel (no dotted circle)
Expected results:
character should be as Dependent vowel (should be a dotted circle)
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 5 months
[Bug 499349] New: "Backspace" has wrong function in Assamese Codepoint.
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: "Backspace" has wrong function in Assamese Codepoint.
https://bugzilla.redhat.com/show_bug.cgi?id=499349
Summary: "Backspace" has wrong function in Assamese Codepoint.
Product: Fedora
Version: 10
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: xinsun(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
"Backspace" has wrong function in Assamese Codepoint.You should press it twice
to delete the word.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.Open a gedit and select the "RAW CODE" in scim-bridge.
2.Input "09CB", "09CC","09DC","09DD","09DF" in gedit.
3.Press "Backspace" to delete each word (Make sure the cursor should be at the
right of the each word).
Actual results:
Each word should be deleted totally when you press "Backspace" once.
Expected results:
Each word isn't deleted when you press "Backspace" once,you should press the
"Backspace" again to delete it totally.
Additional info:
You can get the more information by accessing
http://batman.bne.redhat.com/~indic/IndicTC/lang/as_IN/font/IndicFontTest...
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 5 months
[Bug 501847] New: [ml_IN][GSUB] U+0D21 U+0D4D U+0D30 U+0D48 U+0D35 U+0D4D delete key can't delete the whole char
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [ml_IN][GSUB] U+0D21 U+0D4D U+0D30 U+0D48 U+0D35 U+0D4D delete key can't delete the whole char
https://bugzilla.redhat.com/show_bug.cgi?id=501847
Summary: [ml_IN][GSUB] U+0D21 U+0D4D U+0D30 U+0D48 U+0D35
U+0D4D delete key can't delete the whole char
Product: Fedora
Version: 10
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: kxiong(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
DDescription of problem:
In gedit input U+0D21 U+0D4D U+0D30 U+0D48 U+0D35 U+0D4D with RAW CODE,then
press delete key,it can delete the whole char
Version-Release number of selected component (if applicable):
pango-devel-1.22.1-1.fc10.i386
pango-1.22.1-1.fc10.i386
pangomm-2.14.0-2.fc10.i386
How reproducible:
always
Steps to Reproduce:
1.In gedit input U+0D21 U+0D4D U+0D30 U+0D48 U+0D35 U+0D4D with RAW CODE,press
delete key once
Actual results:
It can't delete the whole char when pressing once
Expected result:
It should can delete the whole char when pressing once
Additional info:
U+0D05 U+0D2A U+0D4D U+0D21 U+0D47 U+0D31 U+0D4D U+0D31 U+0D4D
U+0D05 U+0D2A U+0D4D U+0D17 U+0D4D U+0D30 U+0D47 U+0D21 U+0D4D
U+0D35 U+0D4D U+0D2F U+0D15 U+0D4D U+0D24 U+0D02
U+0D07 U+0D28 U+0D4D U+200D U+0D38 U+0D4D U+0D31 U+0D4D U+0D31 U+0D4B U+0D33
U+0D4D U+200D
also has the same problem
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 5 months