[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 1417250] New: Please upgrade to dejavu-fonts 2.37
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1417250
Bug ID: 1417250
Summary: Please upgrade to dejavu-fonts 2.37
Product: Fedora
Version: rawhide
Component: dejavu-fonts
Severity: medium
Assignee: nicolas.mailhot(a)laposte.net
Reporter: mcatanzaro(a)gnome.org
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, smaitra(a)redhat.com
We have dejavu-fonts 2.35, but dejavu-fonts 2.37 is available. It should be
upgraded!
--
You are receiving this mail because:
You are on the CC list for the bug.
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
[Bug 1290878] New: macros.fonts uses %define instead of %global
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1290878
Bug ID: 1290878
Summary: macros.fonts uses %define instead of %global
Product: Fedora
Version: rawhide
Component: fontpackages
Assignee: nicolas.mailhot(a)laposte.net
Reporter: tibbs(a)math.uh.edu
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
tagoh(a)redhat.com
While working on some compatibility macros for EPEL (to let the older branches
use some of the new RPM functionality without ifdefs) I found my macros broke
nothing except the font packages. After some bugging I found that use of
%define in the %_font_pkg() macro will expand itself recursively when expanded
in certain contexts. It seems to work currently by luck.
Changing that one %define to %global appears to work and generates RPMs which
differ from the current packages by nothing other than timestamps.
Is there a specific reason that %define is used there? As I understand it, the
general rule is that you should use %global unless you know that you really
need the special and difficult to explain behavior of %define. There's no
comment in the macros file about this, so I suspect that the use of %define is
not intentional.
Unfortunately this is holding up some work I'm doing so I'd like to get this
pushed out at least for EL6 and EL5 as soon as is reasonable. I'll do a
complete rebuild of all font packages and rpmdiff against current rawhide as
well as EPEL5 and 6 and post it here to make sure there's no breakage, and I'm
happy to push a package with that one line patched to any branches you desire.
Just let me know.
--
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=tEr6H2XzHZ&a=cc_unsubscribe
6 years, 8 months
[Bug 1284237] New: [kn] Change the default Kannada font to Noto from
Lohit-Kannada
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1284237
Bug ID: 1284237
Summary: [kn] Change the default Kannada font to Noto from
Lohit-Kannada
Product: Fedora
Version: rawhide
Component: fonts-indic
Assignee: extras-orphan(a)fedoraproject.org
Reporter: prasad.mvs(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: extras-orphan(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org
Description of problem:
Aesthetically the Noto fonts are way better than Lohit-Kannada. Change the
default system font for Kannada to Noto.
Actual results:
The default fonts of the current fedora releases are Lohit-Kannada
Expected results:
Noto should be made the default font.
Additional info: To see a comparison between these two fonts, please follow
below steps:
1.Make sure that you have Noto font
2.Open the UTRRS page : http://utrrs-testing.rhcloud.com/language/kn
3.Enter "Noto Sans Kannada" and click on Change Font button.
4.Compare the References (Lohit-Kannada) with those of rendered Characters
(Noto Sans) for Code points, GPOS and GSUB.
--
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=BFpLTzr5z3&a=cc_unsubscribe
6 years, 8 months
[Bug 851950] New: Latin ligatures need 'liga' standard ligature lookups
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=851950
Bug ID: 851950
QA Contact: extras-qa(a)fedoraproject.org
Severity: low
Version: 17
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: Latin ligatures need 'liga' standard ligature lookups
Regression: ---
Story Points: ---
Classification: Fedora
OS: All
Reporter: deron.meranda(a)gmail.com
Type: Bug
Documentation: ---
Hardware: All
Mount Type: ---
Status: NEW
Component: liberation-fonts
Product: Fedora
Description of problem:
Glyphs in the Latin Ligature block (U+FB00 .. U+FB06), such as "fi" and "fl",
should have the OpenType 'liga' lookup features defined. That will allow text
renderers to automatically apply the ligature glyph.
Additionally, for completeness, the ligature caret horizontal positions should
be appropriately set for these glyphs.
Version-Release number of selected component (if applicable):
liberation-fonts-2.00.0
Additional info:
You may need to solve bug #851790 first.
Also the "fi" (and "ffi" if existing) should exclude dotless-i
scripts/languages, e.g., Turkish.
--
You are receiving this mail because:
You are on the CC list for the bug.
6 years, 10 months