[Bug 1076190] New: Rendering of Unicode tie bars could be improved
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1076190
Bug ID: 1076190
Summary: Rendering of Unicode tie bars could be improved
Product: Fedora
Version: 20
Component: liberation-fonts
Severity: low
Assignee: psatpute(a)redhat.com
Reporter: rkaldari(a)wikimedia.org
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
Created attachment 874108
--> https://bugzilla.redhat.com/attachment.cgi?id=874108&action=edit
comparison between Liberation Sans and Helvetica
Description of problem:
The rendering of the two Unicode tie bar combining characters (U+035E and
U+035F) is not ideal. In particular the characters are quite short and far away
from the characters they are tying together. This makes it appear more like a
misplaced macron than a tie bar. The rendering in Liberation Sans appears to be
equivalent to that of Arial which has the same issues. The rendering in
Helvetica is better (see attachment 1).
In particular, because the under tie bar (U+035F) is so far away from the other
characters, it sometimes gets clipped when rendered, as it appears to fall
slightly outside of the bounding box for the line height (see attachment 2).
My suggestion would be to make the length of both tie bars slightly longer, and
to move both of them slightly closer to the characters they are intended to tie
together.
Version-Release number of selected component (if applicable):
12-Mar-2014 (2.x)
How reproducible:
Always
Steps to Reproduce:
1. Install latest Liberation Sans (and Helvetica if you want to compare)
2. Go to https://www.mediawiki.org/wiki/User:Kaldari/Font_test_2
Actual results:
Tie bars should be slightly longer and closer to the other characters.
Expected results:
Tie bar are quite short and far away.
Additional info:
See attachments for more info.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4qagSOJtp5&a=cc_unsubscribe
6 years, 4 months
[Bug 1084227] New: Arrow symbols too small and not nicely aligned
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1084227
Bug ID: 1084227
Summary: Arrow symbols too small and not nicely aligned
Product: Fedora
Version: 20
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: Eduard.Braun2(a)gmx.de
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
Created attachment 882471
--> https://bugzilla.redhat.com/attachment.cgi?id=882471&action=edit
testcase with some exemplary arrows
The arrow symbols contained in Liberation fonts seem to be too small and also a
little mis-aligned.
As an example consider the attached testcase which contains left/right/up/down
arrows exemplarily. The attached screenshot is a rendering of this file to
illustrate the issue:
- The arrows are much to small making them hardly discernible,
especially at small font sizes.
- The horizontally aligned arrows are positioned too low (nearly at the
baseline).
- Also visible: Hinting for the vertically aligned arrows is bad.
The screenshot was created with Firefox 28.0 on Windows 7.
The installed version of the Liberation fonts is 2.00.1
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kmf7UnRYux&a=cc_unsubscribe
6 years, 4 months
[Bug 1319249] New: incorrect use of Requires(pre)?
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1319249
Bug ID: 1319249
Summary: incorrect use of Requires(pre)?
Product: Fedora
Version: rawhide
Component: ghostscript-fonts
Assignee: twaugh(a)redhat.com
Reporter: jsilhan(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, twaugh(a)redhat.com
We've identified your package for having `Requires(pre)` RPM flag without
`Requires` [1]. `Requires(pre)` rpm tag could be interpreted wrongly, so to
prevent any harm to Fedora users I am notifying you about this fact.
Any package that is specified in `Requires(pre)` could be freely removed.
Citing from RPM pages:
```
If there are no other dependencies on the package providing /usr/sbin/useradd,
that package is permitted to be removed from the system after installation(!)
``` [2]
If you really rely on dependency just during the installation process and your
package don't necessary require the dependency for the proper run of your
application then ignore this bug report and close it as NOTABUG. Otherwise add
to your spec file additional `Requires` for the dependency, please.
[1] paste.fedoraproject.org/341611/82208431
[2] http://www.rpm.org/wiki/PackagerDocs/MoreOnDependencies
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 5 months
[Bug 477389] New: Please convert to new font packaging guidelines
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: Please convert to new font packaging guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=477389
Summary: Please convert to new font packaging guidelines
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: ghostscript-fonts
AssignedTo: twaugh(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: twaugh(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
This bug has been filed because we've detected your package includes one or
several font files:
repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb'
-f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e
's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq
Unfortunately the script
does not detect symlinks to other packages, so if that's your case, you can
close this bug report now.
Otherwise, you should know that:
- Fedora guidelines
demand the packaging of fonts in a separate package or subpackage:
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_font...
- our font packaging guidelines recently changed, and every package that ships
fonts must be adapted to the new templates available in the fontpackages-devel
package.
http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_...
http://fedoraproject.org/wiki/Fedora_fonts_policy_package
http://fedoraproject.org/wiki/Simple_fonts_spec_template
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts
Please make
your package conform to the current guidelines in rawhide.
If your package is not
principaly a font package, depending on a separate font package or subpackage
is the prefered solution. If your application does not use fontconfig you can
always package symlinks to the files provided by the font package and installed
in the correct fontconfig directories.
It is preferred to make a font package or
subpackage per font family, though it is not currently a hard guidelines
requirement (it may become before Fedora 11 is released). The definition of a
font family is given on
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family
The new
templates should make the creation of font subpackages easy and safe.
The
following packages have already been converted and can serve as examples: -
andika-fonts - apanov-heuristica-fonts - bitstream-vera-fonts - charis-fonts -
dejavu-fonts - ecolier-court-fonts - edrip-fonts - gfs-ambrosia-fonts -
gfs-artemisia-fonts - gfs-baskerville-fonts - gfs-bodoni-classic-fonts -
gfs-bodoni-fonts - gfs-complutum-fonts - gfs-didot-classic-fonts -
gfs-didot-fonts - gfs-eustace-fonts - gfs-fleischman-fonts - gfs-garaldus-fonts
- gfs-gazis-fonts - gfs-jackson-fonts - gfs-neohellenic-fonts -
gfs-nicefore-fonts - gfs-olga-fonts - gfs-porson-fonts - gfs-solomos-fonts -
gfs-theokritos-fonts - stix-fonts - yanone-kaffeesatz-fonts
If you have any remaining
questions about the new guidelines please ask them on fedora-fonts-list at
redhat.com
--
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.
6 years, 5 months
[Bug 1372368] New: freetype-2.6.5 and freetype-2.6.3 are ABI
incompatible
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1372368
Bug ID: 1372368
Summary: freetype-2.6.5 and freetype-2.6.3 are ABI incompatible
Product: Fedora
Version: 25
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: rc040203(a)freenet.de
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Description of problem:
With freetype-2.6.5, some freetype-internal functions, which were publicly
accessible before were made inaccessible,
e.g. FT_New_GlyphSlot, FT_Done_GlyphSlot
Due to the fact the SONAME was not changed and no mass-rebuild performed for
fc25, this change at least broke Inventor (Inventor uses FT_Done_GlyphSlot).
I haven't tried to check and therefore don't know if this affects more
packages.
fc25 ships an fc24-built Inventor which now contains a reference to an
unresolvable symbol which used to be provided by freetype.
Version-Release number of selected component (if applicable):
freetype-2.6.5
Additional info:
- Inventor clearly is at fault to use private functions from freetype, but it
had been this way for more than ca. 15 years.
- IMHO, it's arguable whether freetype's SONAME should have been changed.
libfreetype.so.6.12.3 and libfreetype.so.6.12.5 definitely are ABI
incompatible.
- It's not clear to me, why freetype made FT_Done_GlyphSlot inaccessible, but
left other similar functions public.
- ATM, I do not see an alternative but to "steal" FT_Done_GlyphSlot code from
freetype and to incorporate it into Inventor, to work-around Inventor's problem
on fedora >= 25.
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 8 months
[Bug 1110646] New: woff file missing on purpose?
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1110646
Bug ID: 1110646
Summary: woff file missing on purpose?
Product: Fedora
Version: rawhide
Component: fontawesome-fonts
Assignee: pvoborni(a)redhat.com
Reporter: tomspur(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
pvoborni(a)redhat.com
Description of problem:
ipython shows this warning:
2014-06-16 20:47:56.421 [tornado.access] WARNING | 404 GET
/static/components/font-awesome/font/fontawesome-webfont.woff?v=3.2.1
(127.0.0.1) 0.37ms
referer=http://localhost:8888/static/style/style.min.css?v=7775081fa91df3822d16b2087bc2c8dd
Would it be possible to also add the .woff file to fontawesome-webfont-web or
is it left out on purpose?
How reproducible:
always
Steps to Reproduce:
1. open ipython-notebook
Actual results:
no fontawesome-webfont.woff
Expected results:
fontawesome-webfont.woff
See also #1006575 for the ipython warning above.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=dtK3lFi0PP&a=cc_unsubscribe
6 years, 8 months
[Bug 1374074] New: 1px changes in line height from bold <->
non-bold breaks various websites
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1374074
Bug ID: 1374074
Summary: 1px changes in line height from bold <-> non-bold
breaks various websites
Product: Fedora
Version: 24
Component: liberation-fonts
Severity: high
Assignee: psatpute(a)redhat.com
Reporter: jonas(a)thiem.email
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
Description of problem:
The liberation fonts as packaged in Fedora can change line height by 1px as
reported by fontconfig if switched from bold to non-bold or vice versa.
This can break various sites displayed in web browsers, and for example all
gitlab code listings viewed on Fedora only (works fine on Ubuntu, Archlinux,
...) aren't lining up properly because of this with the line numbers, which
makes the whole thing look like a big mess. A more detailed analysis can be
found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1296856
Please note I'm not sure who is the best involved party to fix this and whether
e.g. the website should fix it on their side, however I tried playing around
with CSS line-height and so far I didn't manage to make it line up myself in
the affected configurations (but I'm no CSS expert). Therefore I'm filing a bug
here as well, hoping some font expert can shed some light on the issue.
There is also a firefox bug report here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1296856
There is also a gitlab bug report here:
https://gitlab.com/gitlab-org/gitlab-ce/issues/20202
Version-Release number of selected component (if applicable):
Version : 1.07.4
Release : 7.fc24
How reproducible:
100% at affected font sizes
Steps to Reproduce:
1. Run an affected configuration (Firefox Nightly on Fedora should work,
possibly also regular Firefox stable as packaged in Fedora) at an affected web
browser zoom level (100%/standard should work for firefox)
2. Visit a gitlab source code listing of more than just ~10 lines, e.g.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/group...
3. Look how line numbers and lines match up
Actual results:
Line numbers are not matching up
Expected results:
Line numbers are matching up
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 8 months