Description of problem, adapted from
PostScript Type 1 (PS1) fonts don't have a native Unicode map. Contrary to
popular belief, Type 1 fonts can store more than 256 glyphs in a pfb file, but
these can only be addressed by AGL name. At most 256 glyphs can be accessed by a
numeric index, for which various encodings schemes exist. A PS1 font can even
specify its own 8-bit encoding scheme in the afm file; this is common practice
for PS1 fonts targeting Central and Eastern Europe. The 8-bit encoding scheme is
irrelevant however for Unicode applications. Unicode-enabled libraries, like
freetype, define their own mapping from Unicode to AGL names, normally using the
list published by Adobe.
Adobe once decided that "t with cedilla" is not used in any language, so the AGL
name "Tcommaaccent", which is a glyph of T with a comma below, is actually
mapped by Adobe to the Unicode code point U+0162, which is supposed to represent
a t with cedilla. New OpenType fonts from Adobe also contain a glyph with the
AGL name "uni021A", which is visually identical to identical to "Tcommaaccent".
As you'd expect, "uni021A" is mapped to U+021A. Unfortunately, old PS1 fonts do
not a have a "uni021A" in their pfb. Thus, using the Adobe-provide AGL to
Unicode mapping for PS1 fonts, the code point U+021A remains unmapped.
Fontconfig will therefore choose to borrow the glyph from a another font, even
though the glyph is present in the pfb. This problem is illustrated by the
following OpenOffice screenshot:
[http://www.cs.umd.edu/~gaburici/oo/ro-font-test.png]. Practically all
PostScript type 1 fonts that ship with Fedora suffer from this problem.
Microsoft's Uniscribe automatically handles this issue by remapping U+21A/B to
U+162/3 when the former glyphs are missing. Unfortunately, the
Pango/fonconfig/freetype stack did't use to do this until 2008-07-27, so most
new Romanian documents cannot be displayed with Type 1 fonts properly. The extra
mapping has now been added in the CVS of freetype.
A test SRPM is available here:
Note that because it is built from CVS sources, it buildrequires libtool 2.2.4.
If anyone is foolish enough (like me) to upgrade their libtool, a SRPM is here:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.