[sil-lateef-fonts] (8 commits) ...Merge remote branch 'origin/f12/master'
by Hedayat Vatankhah
Summary of changes:
87d0662... Initialize branch F-12 for sil-lateef-fonts (*)
39c68b7... initial import (*)
6ddeb2b... Fix typo that causes a failure to update the common directo (*)
6a88c21... Initialize branch F-13 for sil-lateef-fonts (*)
ed9ea3e... dist-git conversion (*)
6263210... dist-git conversion (*)
fcc5beb... Merge remote branch 'origin/f13/master'
9bee1d8... Merge remote branch 'origin/f12/master'
(*) This commit already existed in another branch; no separate mail sent
13 years, 10 months
[oflb-goudy-bookletter-1911-fonts] resolve FTBFS
by Tom Callaway
commit 0d42190ddc692dc7c040d1422499a6ef45caaa13
Author: Tom "spot" Callaway <tcallawa(a)redhat.com>
Date: Thu Aug 5 15:26:46 2010 -0400
resolve FTBFS
GoudyBookletter1911.otf | Bin 0 -> 430864 bytes
oflb-goudy-bookletter-1911-fonts.spec | 11 +++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/GoudyBookletter1911.otf b/GoudyBookletter1911.otf
new file mode 100644
index 0000000..e273f01
Binary files /dev/null and b/GoudyBookletter1911.otf differ
diff --git a/oflb-goudy-bookletter-1911-fonts.spec b/oflb-goudy-bookletter-1911-fonts.spec
index 8f26a3f..250ebbf 100644
--- a/oflb-goudy-bookletter-1911-fonts.spec
+++ b/oflb-goudy-bookletter-1911-fonts.spec
@@ -11,9 +11,10 @@ Group: User Interface/X
# http://openfontlibrary.org/people/chemoelectric/chemoelectric_-_Goudy_Boo...
# It is no longer available. The main website has this zip for download:
# http://home.comcast.net/%7Ecrudfactory/cf3/fonts/GoudyBookletter1911--200...
-# However, that zip file does not contain the source, just the finished .otf file.
+# But, it doesn't have the source, just an otf.
Source0: chemoelectric_-_Goudy_Bookletter_1.zip
Source1: %{name}-fontconfig.conf
+Source2: GoudyBookletter1911.otf
URL: http://home.comcast.net/~crudfactory/cf3/gb1911.html
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: fontpackages-devel, fontforge
@@ -32,7 +33,10 @@ solid appearance.
sed -i 's|/home/trashman/bin/fontforge|/usr/bin/fontforge|g' make-otf.py
%build
-./generate-it.sh
+# Fontforge's python support is broken, so we can't build this from source, sadly.
+# ./generate-it.sh
+# The otf file was generated by converting it with Fontforge manually.
+cp %{SOURCE2} .
%install
rm -rf %{buildroot}
@@ -48,6 +52,9 @@ rm -rf %{buildroot}
%_font_pkg -f %{fontconf} *.otf
%changelog
+* Thu Aug 5 2010 Tom "spot" Callaway <tcallawa(a)redhat.com> 20080206-4
+- source building no longer sane, use pre-generated otf
+
* Mon Jun 28 2010 Tom "spot" Callaway <tcallawa(a)redhat.com> 20080206-3
- fix upstream URL and source
13 years, 10 months
[oflb-goudy-bookletter-1911-fonts/f14/master] resolve FTBFS
by Tom Callaway
commit 49740c18c59efcb93f66f2050761e21813065c1b
Author: Tom "spot" Callaway <tcallawa(a)redhat.com>
Date: Thu Aug 5 15:26:35 2010 -0400
resolve FTBFS
GoudyBookletter1911.otf | Bin 0 -> 430864 bytes
oflb-goudy-bookletter-1911-fonts.spec | 11 +++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/GoudyBookletter1911.otf b/GoudyBookletter1911.otf
new file mode 100644
index 0000000..e273f01
Binary files /dev/null and b/GoudyBookletter1911.otf differ
diff --git a/oflb-goudy-bookletter-1911-fonts.spec b/oflb-goudy-bookletter-1911-fonts.spec
index 8f26a3f..250ebbf 100644
--- a/oflb-goudy-bookletter-1911-fonts.spec
+++ b/oflb-goudy-bookletter-1911-fonts.spec
@@ -11,9 +11,10 @@ Group: User Interface/X
# http://openfontlibrary.org/people/chemoelectric/chemoelectric_-_Goudy_Boo...
# It is no longer available. The main website has this zip for download:
# http://home.comcast.net/%7Ecrudfactory/cf3/fonts/GoudyBookletter1911--200...
-# However, that zip file does not contain the source, just the finished .otf file.
+# But, it doesn't have the source, just an otf.
Source0: chemoelectric_-_Goudy_Bookletter_1.zip
Source1: %{name}-fontconfig.conf
+Source2: GoudyBookletter1911.otf
URL: http://home.comcast.net/~crudfactory/cf3/gb1911.html
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: fontpackages-devel, fontforge
@@ -32,7 +33,10 @@ solid appearance.
sed -i 's|/home/trashman/bin/fontforge|/usr/bin/fontforge|g' make-otf.py
%build
-./generate-it.sh
+# Fontforge's python support is broken, so we can't build this from source, sadly.
+# ./generate-it.sh
+# The otf file was generated by converting it with Fontforge manually.
+cp %{SOURCE2} .
%install
rm -rf %{buildroot}
@@ -48,6 +52,9 @@ rm -rf %{buildroot}
%_font_pkg -f %{fontconf} *.otf
%changelog
+* Thu Aug 5 2010 Tom "spot" Callaway <tcallawa(a)redhat.com> 20080206-4
+- source building no longer sane, use pre-generated otf
+
* Mon Jun 28 2010 Tom "spot" Callaway <tcallawa(a)redhat.com> 20080206-3
- fix upstream URL and source
13 years, 10 months
[Issue 78749] some Latin text needs CTL processing
by stevanwhite＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=78749
------- Additional comments from stevanwhite(a)openoffice.org Thu Aug 5 12:33:42 +0000 2010 -------
yaoziyuan, you are right. This has to do with the OO rendering engine.
It makes OO look very bad. Since OO is so important to the free software
community, it makes the whole community look bad.
You mentioned the rendering engines used by KDE4 and Gnome. But also Windows
Vista+ and the Mac OS have good support for these features.
The effect is, any graphical web browser, and much simpler word processors such
as KWord, and even the lowliest text processor on these systems renders mark
placement fairly well (never mind MS Word). But not OpenOffice.
OpenOffice Writer is primarily about text display of high quality. Without
that, all the fancy bells and whistles are for the garbage. Anything else you
can do with it, could be done better with some other tool.
Crucial features that still seem to be absent in OO
'ccmp' ligature composition (as opposed to the ccmp decomposition table)
'mark'
'mkmk'
certainly there are others.
Scripts that would use these features (and may be illegible without them)
include: Hebrew, Arabic, Thai, Vietnamese, but there are many more.
I don't know if OO supports 'abvm' and 'blwm', but these are used a lot with
Indic scripts, as well as Tibetan.
But mark positioning is used for fine placement in general for languages that
use marks. And that includes the *majority* of European languages. It makes
the difference between text being very ugly, and looking great.
See for example:
http://partners.adobe.com/public/developer/opentype/index_table_formats2....
This issue makes the product look stupid and useless for a large fraction of
potential users in the world, yet since this report was opened in 2007, it has
been marked priority P3 "Of interest, but not planned or expected in this
release" (and many related reports preceded it.)
Colleagues, let's get our priorities straight.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
13 years, 10 months
[Bug 620615] fedora 13 yum update 后系统中文字体变得没有原来清楚了。很模糊。
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.
https://bugzilla.redhat.com/show_bug.cgi?id=620615
Caius Chance <me(a)kaio.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |i18n, Regression
CC| |dchen(a)redhat.com,
| |fonts-bugs(a)lists.fedoraproj
| |ect.org, me(a)kaio.net,
| |pwu(a)redhat.com,
| |shawn.p.huang(a)gmail.com
Component|Chinese Simplified [zh_CN] |cjkuni-fonts
Version|unspecified |rawhide
AssignedTo|tiansworld(a)gmail.com |pwu(a)redhat.com
Product|Fedora Localization |Fedora
QAContact|tiansworld(a)gmail.com |extras-qa(a)fedoraproject.org
--- Comment #3 from Caius Chance <me(a)kaio.net> 2010-08-05 08:27:10 EDT ---
Please provide step to reproduce and screenshots. Thank you.
--
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.
13 years, 10 months
[Bug 578039] New: lang-specific overrides rule doesn't work as expected
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: lang-specific overrides rule doesn't work as expected
https://bugzilla.redhat.com/show_bug.cgi?id=578039
Summary: lang-specific overrides rule doesn't work as expected
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: lohit-tamil-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: tagoh(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Depends on: 578015
Blocks: 507684
Classification: Fedora
Target Release: ---
Description of problem:
All of detailed information is available on my post at the fonts list:
http://lists.fedoraproject.org/pipermail/fonts/2010-March/001117.html
binding="same" in the fontconfig config file prevents to apply the rule for the
specific
language only properly. As a result, fonts is used for non-targetted languages
and it may gives different look and feel in some cases.
I'd propose to get rid of binding="same" from:
66-lohit-tamil.conf
--
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.
13 years, 10 months
[Issue 113586] Unable to get correct version of OpenSymbol
by is＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=113586
------- Additional comments from is(a)openoffice.org Wed Aug 4 09:30:04 +0000 2010 -------
But if fontconfig always uses the highest version of a font, we will have no
problem, if we install the fonts in our builds into the directory
share/fonts/truetype inside the application. If there is an older version in the
system font directory, it will not be used.
On the other hand every distro repackages our packages, and includes the fonts
only into the system font dir. Then this problem also does not occur.
So do we have a problem of fontconfig here?
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
13 years, 10 months
[Issue 113586] Unable to get correct version of OpenSymbol
by nmailhot＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=113586
------- Additional comments from nmailhot(a)openoffice.org Wed Aug 4 08:08:08 +0000 2010 -------
@tl
As I wrote before fontconfig will always serve apps the font files with the
highest version (as in, version field in truetype metadata). Thus, on a
fontconfig platform, the worst that can happen is someone installed a newer
opensymbol system-wide, and the tar install uses it instead of its local one.
Therefore, as long as OO.o selects fonts through fontconfig, keeps compat in
OpenSymbol, and increments the font version when it changes, there will be no
problems. (and if compat is not kept the font should be renamed)
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
13 years, 10 months
[Issue 113586] Unable to get correct version of OpenSymbol
by hdu＠openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=113586
------- Additional comments from hdu(a)openoffice.org Wed Aug 4 08:04:50 +0000 2010 -------
Another noteworthy aspect of this question is whether and how the problem shows itself on other
platforms: on WIN, OSX, SOLS etc. the problem is usually not seen because these platforms there a
conflicting version of the OpenSymbol font is rare and it will stay this way unless the platform providers
start to push OpenSymbol in their maintenance updates. And even then it would not be a problem unless
they pushed an obsoleted version.
Platforms such as WIN do not even allow to register an app-specific font as temporary if the font has a
system-wide equivalent. So the installer must make sure that if there is a system-wide OpenSymbol
installed then that file needs to be updated in the installation process.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
13 years, 10 months
