[xorg-x11-font-utils] Fix opendir error message during font install, missing encodingsdir/large
by Peter Hutterer
commit 6bfee3c45a210b5ae078d45ae96c52c599e4411b
Author: Peter Hutterer <peter.hutterer(a)who-t.net>
Date: Mon Apr 8 18:47:04 2013 +1000
Fix opendir error message during font install, missing encodingsdir/large
was missing (#928305)
xorg-x11-font-utils.spec | 6 +++++-
xorg-x11-fonts-update-dirs | 1 +
2 files changed, 6 insertions(+), 1 deletions(-)
---
diff --git a/xorg-x11-font-utils.spec b/xorg-x11-font-utils.spec
index b8b03fd..0956825 100644
--- a/xorg-x11-font-utils.spec
+++ b/xorg-x11-font-utils.spec
@@ -6,7 +6,7 @@ Name: xorg-x11-%{pkgname}
# IMPORTANT: If package ever gets renamed to something else, remove the Epoch line!
Epoch: 1
Version: 7.5
-Release: 12%{?dist}
+Release: 13%{?dist}
License: MIT
Group: User Interface/X
URL: http://www.x.org
@@ -107,6 +107,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/ucs2any.1*
%changelog
+* Mon Apr 08 2013 Peter Hutterer <peter.hutterer(a)redhat.com> 1:7.5-13
+- Fix opendir error message during font install, missing encodingsdir/large
+ was missing (#928305)
+
* Thu Mar 07 2013 Dave Airlie <airlied(a)redhat.com> 7.5-12
- autoreconf for aarch64
diff --git a/xorg-x11-fonts-update-dirs b/xorg-x11-fonts-update-dirs
index 536bfe8..9d2725c 100755
--- a/xorg-x11-fonts-update-dirs
+++ b/xorg-x11-fonts-update-dirs
@@ -51,6 +51,7 @@ fc-cache $fontdir
if ! [ -z "$encodingsdir" ]; then
[ -d "$encodingsdir" ] || mkdir -p "$encodingsdir"
+ [ -d "$encodingsdir/large" ] || mkdir -p "$encodingsdir/large"
oldpwd=$(pwd)
cd "$encodingsdir"
mkfontscale -n -e "$encodingsdir" -e "$encodingsdir/large"
11 years, 2 months
Broken dependencies: fontforge
by Fedora Koji Build System
fontforge has broken dependencies in the epel-5 tree:
On x86_64:
fontforge-20080828-1.1.el5.i386 requires libpython2.4.so.1.0
Please resolve this as soon as possible.
11 years, 2 months
Broken dependencies: fontforge
by Fedora Koji Build System
fontforge has broken dependencies in the epel-5 tree:
On x86_64:
fontforge-20080828-1.1.el5.i386 requires libpython2.4.so.1.0
Please resolve this as soon as possible.
11 years, 2 months
[Bug 946859] [regression] Webfonts not working in Firefox using F19's fontconfig
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=946859
Elad Alfassa <el.il(a)doom.co.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |needinfo?
--- Comment #4 from Elad Alfassa <el.il(a)doom.co.il> ---
quoting from upstream bug,
>According to fontconfig docs it doesn't look as though the filename should be required here, if we don't care about it being available as a pattern element. Indeed, with a downloaded font, there *is* no filename - the font data associated with the FT_Face exists only in RAM, it is not stored in a file.
>
>So this looks to me like a breaking change in the semantics of the fontconfig API. :(
Akira, can you please comment about this upstream? What should be the required
course of action when the font is not stored in a file?
--
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=7CXP1AAyiZ&a=cc_unsubscribe
11 years, 2 months
[Bug 946859] [regression] Webfonts not working in Firefox using F19's fontconfig
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=946859
Elad Alfassa <el.il(a)doom.co.il> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fonts-bugs(a)lists.fedoraproj
| |ect.org,
| |i18n-bugs(a)lists.fedoraproje
| |ct.org, pnemade(a)redhat.com,
| |tagoh(a)redhat.com
Component|firefox |fontconfig
Assignee|stransky(a)redhat.com |tagoh(a)redhat.com
Summary|Webfonts not working |[regression] Webfonts not
| |working in Firefox using
| |F19's fontconfig
Severity|unspecified |high
--- Comment #1 from Elad Alfassa <el.il(a)doom.co.il> ---
This is still a problem with firefox-20.0-1.fc19.x86_64
I downgraded fontconfig to the f18 version using rpm -Uhv --nodeps --oldpackage
and it appears that the issue is not present when using f18's fontconfig.
So I can confirm the following:
Webfonts work with fontconfig equal or lesser than fontconfig-2.10.2-2.fc18
Webfonts do not work with fontconfig fontconfig-2.10.92-2.fc19 or
fontconfig-2.10.92-1.fc19.x86_64
Status of versions in between these two and the exact cause of the problem is
still unknown.
Moving to fontconfig.
This bug causes me difficulties in doing my work, since as a web developer web
fonts are an important resource and tool.
--
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=0W6LCu5Tyx&a=cc_unsubscribe
11 years, 2 months
[Bug 37984] [Freetype] Support for "locl" tables
by bugzilla-daemon@webkit.org
https://bugs.webkit.org/show_bug.cgi?id=37984
--- Comment #45 from Georg Duffner <g.duffner(a)gmail.com> 2013-04-03 00:49:00 PST ---
(In reply to comment #44)
> (In reply to comment #43)
> > (In reply to comment #42)
> > > (In reply to comment #41)
> > > > (In reply to comment #40)
> > > > > (In reply to comment #38)
> > > > > > (In reply to comment #35)
> > > > > >
> > > > > > > I’ve updated the page with an explanation and with a screenshot of the expected result.
> > > > > >
> > > > > > Thanks - that's a good starting point for creating some LayoutTests later.
> > > > >
> > > > > Right now HarfBuzzRun doesn't hold language and doesn't set language on the buffer.
> > > > >
> > > > > This *is* a Webkit bug.
> > > >
> > > > Ok, then I’m very curious what’s going on in Chromium. Is there any other part of the program that can do something with Opentype features? Because the effects shown in the testpage can’t be replicated but with locl.
> > >
> > > Yes, as you identified yourself, it applies locl, just not the right one. And to make it apply the right one a fix in webkit is needed. I'm not quite sure what you are talking about.
> >
> > I’m sorry, I probably haven’t understood well the part of HarfBuzzRun "doesn't hold language and doesn't set language on the buffer".
> > I understood it in a way that HB isn’t responsible for the locl feature effects we see.
>
> HarfBuzz applies 'locl'. It needs to be told the text language. When it's not, it uses default language.
>
> HarfBuzzRun is a Webkit abstraction around HarfBuzz shaper. It's part of the glue code connecting Webkit HarfBuzz. As such, it must collect the correct language from other Webkit layers and pass it to HarfBuzz. It's not doing that right now.
>
> > I’m confused. But nevermind, I’m sure you’re doing the right thing.
>
> Yes, I believe the issue is clear now.
And I too understand it now. Thank you!
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
11 years, 2 months
[Bug 37984] [Freetype] Support for "locl" tables
by bugzilla-daemon@webkit.org
https://bugs.webkit.org/show_bug.cgi?id=37984
--- Comment #44 from Behdad Esfahbod <behdad(a)google.com> 2013-04-03 00:19:23 PST ---
(In reply to comment #43)
> (In reply to comment #42)
> > (In reply to comment #41)
> > > (In reply to comment #40)
> > > > (In reply to comment #38)
> > > > > (In reply to comment #35)
> > > > >
> > > > > > I’ve updated the page with an explanation and with a screenshot of the expected result.
> > > > >
> > > > > Thanks - that's a good starting point for creating some LayoutTests later.
> > > >
> > > > Right now HarfBuzzRun doesn't hold language and doesn't set language on the buffer.
> > > >
> > > > This *is* a Webkit bug.
> > >
> > > Ok, then I’m very curious what’s going on in Chromium. Is there any other part of the program that can do something with Opentype features? Because the effects shown in the testpage can’t be replicated but with locl.
> >
> > Yes, as you identified yourself, it applies locl, just not the right one. And to make it apply the right one a fix in webkit is needed. I'm not quite sure what you are talking about.
>
> I’m sorry, I probably haven’t understood well the part of HarfBuzzRun "doesn't hold language and doesn't set language on the buffer".
> I understood it in a way that HB isn’t responsible for the locl feature effects we see.
HarfBuzz applies 'locl'. It needs to be told the text language. When it's not, it uses default language.
HarfBuzzRun is a Webkit abstraction around HarfBuzz shaper. It's part of the glue code connecting Webkit HarfBuzz. As such, it must collect the correct language from other Webkit layers and pass it to HarfBuzz. It's not doing that right now.
> I’m confused. But nevermind, I’m sure you’re doing the right thing.
Yes, I believe the issue is clear now.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
11 years, 2 months