[Bug 1813728] New: Square four dot Unicode character has incorrect
glyph
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1813728
Bug ID: 1813728
Summary: Square four dot Unicode character has incorrect glyph
Product: Fedora
Version: 31
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: low
Assignee: pwu(a)redhat.com
Reporter: guillaumepoiriermorency(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The glyph for the Unicode "square four dot" character is incorrect.
Version-Release number of selected component (if applicable):
I think this problem arose when upgrading from Fedora 30 to Fedora 31.
How reproducible:
The simplest way is to start GNOME Characters Map and search for "square four
dot".
--
You are receiving this mail because:
You are on the CC list for the bug.
9 minutes
[Bug 2119015] New: fontconfig-devel may require gettext-runtime
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2119015
Bug ID: 2119015
Summary: fontconfig-devel may require gettext-runtime
Product: Fedora
Version: rawhide
Status: NEW
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: suanand(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pnemade(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
In F37 we moved the gettext runtime programs to gettext-runtime.
So assuming if fontconfig-devel does not require any translation
management tools (like msgcat or xgettext) at runtime,
it should be possible for it to only Requires: gettext-runtime
(instead of gettext). The goal here is only to install
gettext-runtime in the Fedora live image(s), etc.
Additional info:
https://fedoraproject.org/wiki/Changes/GettextRuntimeSubpackage
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2119015
3 days, 16 hours
[Bug 2093080] New: Default fonts for Arabic do not match the font
packages list
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2093080
Bug ID: 2093080
Summary: Default fonts for Arabic do not match the font
packages list
Product: Fedora
Version: 36
Hardware: All
OS: Linux
Status: NEW
Component: fontconfig
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: awilliam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pnemade(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
There's a test case:
https://fedoraproject.org/wiki/QA:Testcase_i18n_default_fonts
which requires checking the default fonts for various languages against a list,
http://tagoh.fedorapeople.org/fonts/fc-test.sh .
The current default fonts for Arabic installs do not match the list. The list
states sans should be DejaVu Sans, serif should be FreeSerif or MPH 2B Damase,
and mono should be DejaVu Sans Mono. These may have been changed recently, as
our openQA reference text file expects them to be Noto Naskh Arabic (for both
sans and serif?) and PakType Naskh Basic for mono.
In any case, what we actually see doesn't match either the list or the openQA
reference file. We see "Noto Sans Arabic" and "PakType Naqsh" in the output
from the test, I think for serif (yes really) and monospace respectively.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2093080
4 days, 18 hours
[Bug 1833858] New: Hangul Jamo is seperated and printed respectively
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Bug ID: 1833858
Summary: Hangul Jamo is seperated and printed respectively
Product: Fedora
Version: 32
Status: NEW
Component: google-droid-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: hyunwoo.park(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, oliver(a)redhat.com,
paul(a)frixxon.co.uk, tremble(a)tremble.org.uk
Target Milestone: ---
Classification: Fedora
Created attachment 1687129
--> https://bugzilla.redhat.com/attachment.cgi?id=1687129&action=edit
wrong display of Hangul at LibreOffice Writer
Description of problem:
When Hangul is output to the monitor, Chosung, Neutral, and Jongseong are
output separately.
Version-Release number of selected component (if applicable):
Font file, /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf,
of google-droid-sans-fonts-20200215-3.fc32.noarch
How reproducible:
If you create a test.html containing "가속도" and open the file in the chrome
browser, the Korean alphabet will be displayed separately.
Or, write "가속도" at LibreOffice Writer and select font as "Droid Sans Fallback".
Steps to Reproduce:
1. write "가속도" at LibreOffece Writer
2. select the text and change font name to "Droid Sans Fallback"
Actual results:
The text is displayed like "가ㅅㅗㄱㄷㅗ".
Expected results:
Text should be "가속도"
Additional info:
https://kldp.org/node/163247
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week, 1 day
[Bug 1999078] New: Hinting broken for Bitstream Vera/DejaVu in
Epiphany
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Bug ID: 1999078
Summary: Hinting broken for Bitstream Vera/DejaVu in Epiphany
Product: Fedora
Version: 34
Status: NEW
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: ossman(a)cendio.se
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mark(a)net-c.com,
mclasen(a)redhat.com, mkasik(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1819062
--> https://bugzilla.redhat.com/attachment.cgi?id=1819062&action=edit
Screenshot with varying sub pixel placement
Description of problem:
After upgrading from Fedora 33 to Fedora 34, there is some extremely odd
hinting bug in Epiphany. The same glyph appears with different amount of
hinting in the same line of text, causing a very odd and blurry appearance.
Version-Release number of selected component (if applicable):
freetype-2.10.4-3.fc34.x86_64
bitstream-vera-sans-fonts-1.10-41.fc33.noarch
dejavu-sans-fonts-2.37-16.fc34.noarch
epiphany-40.3-1.fc34.x86_64
webkit2gtk3-2.32.3-1.fc34.x86_64
pango-1.48.9-2.fc34.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Configure Epiphany to use Bitstream Vera or DejaVu Sans Book
2. Configure full hinting
Actual results:
Fully hinted, consistent glyphs.
Expected results:
Some glyphs are fully hinted, some look like they've been offset by a fraction
of a pixel. (See screenshot)
Additional info:
So far I'm only seeing this in Epiphany. I still filed this for freetype since
as far as I know it is freetype that does all glyph layout, hinting and
sub-pixel stuff. Feel free to move as appropriate. So it seems odd that a bug
in Epiphany can screw this up.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week, 1 day
[Bug 1898319] New: dejavu-lgc-sans-mono-fonts: Misleading summary
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1898319
Bug ID: 1898319
Summary: dejavu-lgc-sans-mono-fonts: Misleading summary
Product: Fedora
Version: 33
Hardware: x86_64
OS: Linux
Status: NEW
Component: dejavu-fonts
Severity: low
Assignee: nicolas.mailhot(a)laposte.net
Reporter: van.de.bugger(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
peter(a)thecodergeek.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Summary of dejavu-lgc-sans-mono-fonts is misleading. It is: "A variable-width
Latin-Greek-Cyrillic mono-space font family". Accordingly to Wikipedia:
> A monospaced font, also called a fixed-pitch, fixed-width, or non-proportional font, is a font whose letters and characters each occupy the same amount of horizontal space. This contrasts with variable-width fonts, where the letters and spacings have different widths.
So, a font is either monospaced or variable-width but not both, these are
mutually exclusive concepts. How dejavu-lgc-sans-mono-fonts can be "a
variable-width mono-space font family"??
Version-Release number of selected component (if applicable):
dejavu-lgc-sans-mono-fonts-2.37-15.fc33
How reproducible:
Always.
Steps to Reproduce:
1. $ dnf info dejavu-lgc-sans-mono-fonts
Actual results:
Summary : A variable-width Latin-Greek-Cyrillic mono-space font family
Expected results:
Summary : A Latin-Greek-Cyrillic mono-space font family
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week, 1 day
[Bug 2144373] New: reduce the fontconfig priority of Droid fonts
below default CJK fonts
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2144373
Bug ID: 2144373
Summary: reduce the fontconfig priority of Droid fonts below
default CJK fonts
Product: Fedora
Version: 37
Status: NEW
Component: google-droid-fonts
Severity: medium
Assignee: aekoroglu(a)linux.intel.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: aekoroglu(a)linux.intel.com,
fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, oliver(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
These days Droid is considered a general fallback font so it should not
have higher fontconfig priority than other default system fonts,
including in particular google-noto-sans-cjk-ttc-fonts.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. see for example bug 517789
Actual results:
Droid interferes with system fonts priorities
Expected results:
Droid should be a fallback font.
Additional info:
The family unification configuration in the Fedora package
is also involved here, but hopefully lowering the priority
could be sufficient to avoid these issues, otherwise perhaps
the families should be un-unified.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2144373
2 weeks, 1 day
[Bug 2096153] New: strange font priorities in Firefox
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2096153
Bug ID: 2096153
Summary: strange font priorities in Firefox
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: google-droid-fonts
Assignee: ali.erdinc.koroglu(a)intel.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ali.erdinc.koroglu(a)intel.com, contact(a)dannycolin.com,
fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, oliver(a)redhat.com,
skyfaller(a)gmail.com
Depends On: 2062386
Target Milestone: ---
Classification: Fedora
Cloning to focus on the Droid specific issue here. please ignore URW related
description.
+++ This bug was initially created as a clone of Bug #2062386 +++
Description of problem:
Sometimes, when using a native font stack in CSS on a web page, fonts that are
not in the font stack at all are substituted for the desired fonts.
This only seems to affect web pages viewed using:
- Fedora (not Ubuntu, Debian 11, or Manjaro)
- Firefox (not Chrome or Chromium)
- When using the RPM version or Mozilla's official build from their website
(not the Flatpak)
Happens in the stable version of Firefox, Firefox Beta, and Firefox nightly.
Two substitutions I've identified so far:
- Droid Sans is substituted for Open Sans
- P052 is substituted for 'URW Palladio L' or Palatino
Substituting for Palatino may be less objectionable, since that's a generic
choice, but URW Palladio L is rather specific and it's surprising to see the
substitution. This also wouldn't be as objectionable if the font substitutions
were better. Droid Sans doesn't look much like Open Sans at all, and P052 looks
really ugly (it has unevenly sized letters). In Firefox Flatpak, it instead
substitutes the better-looking 'TeX Gyre Pagella', and only does that for
Palatino, not for 'URW Palladio L' (which was higher priority in my font
stack). This is more desirable behavior.
The source of the problem seems to be that if you run the following command:
fc-match :family="Open Sans"
It returns Droid Sans.
Possibly related bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1820166
https://bugzilla.mozilla.org/show_bug.cgi?id=1406790
How reproducible:
Consistently
Steps to Reproduce:
1. Open a clean Fedora 35 install, and verify that Open Sans is not installed.
2. Create the following web page and view it in a browser:
```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title></title>
<style>
h1,h2,h3,h4 {
font-family: Open Sans, Fira Sans;
}
</style>
</head>
<body>
<h1>Hello World</h1>
<p>Lorem ipsum dolor sit amet.</p>
</body>
</html>
```
Alternately, view a real live (but more complex) website at
https://www.maximumethics.dev/
Actual results:
Notice that the text on the webpage is displayed in Droid Sans, not Open Sans.
Expected results:
The webpage displays the next available font in the font stack, Fira Sans in
this case, or the browser's default font if you don't have Fira Sans.
--- Additional comment from Akira TAGOH on 2022-03-30 09:26:08 UTC ---
Well, maybe good to file a separate bug to object each substitutions.
For Open Sans, google-droid-sans-fonts has the following config:
<alias binding="same">
<family>Open Sans</family>
<accept>
<family>Droid Sans</family>
</accept>
</alias>
This is the reason why you see that behavior.
For URW Palladio L, urw-base35-fonts-common has the following config:
<alias binding="same">
<family>URW Palladio L</family>
<accept>
<family>P052</family>
</accept>
</alias>
And finally for Palatino, it is in urw-base35-p052-fonts:
<alias binding="same">
<family>Palatino</family>
<accept>
<family>P052</family>
</accept>
</alias>
Although those urw config are coming from upstream. so if you have any
objections for them, it would be good to talk with URW upstream.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2062386
[Bug 2062386] strange font priorities in Firefox
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2096153
2 weeks, 1 day
[Bug 2123720] New: Noto Sans Thai to default for Thai
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2123720
Bug ID: 2123720
Summary: Noto Sans Thai to default for Thai
Product: Fedora
Version: rawhide
Status: NEW
Component: google-noto-fonts
Keywords: FutureFeature
Assignee: tagoh(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
As we have changed most languages default to Noto, it may be good to consider
updating Thai to Noto as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2123720
1 month