bugThe FreeType Project - Bugs: bug #23940, Type 1 map missing for U+021A(B)...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #23940: Type 1 map missing for U+021A(B) to T(t)commaaccent

Submitter:  Vasile Gaburici <vga>
Submitted:  Sat 26 Jul 2008 09:02:51 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Tue 29 Jul 2008 09:41:24 PM UTC, comment #6: 

It's good to know that it works.

Regarding XeTeX: A solution to make a document searchable in case the font isn't completely conforming to the AGL is simply to provide ToUnicode cmaps.  I don't know whether XeTeX supports manual insertion of such cmaps, but I can imagine that it does.

 Werner LEMBERG <wl>
Group administrator
Tue 29 Jul 2008 02:57:39 PM UTC, comment #5: 

Sorry this took me so long, but Fedora doesn't yet packaged libtool 2.x, which was required to build freetype from CVS.

Anyway, the test results are nothing short of amazing:
• OpenOffice.org works
• fontmatrix works
• Pango works
• XeTeX (dvipdfmx) works too. I didn't think it would!
∘ This isn't a result of Acrobat (or evince) using the new  freetype lib because PDFs that I had generated before upgrading freetype still show up with missing glyphs.
∘ In the PDFs generated (by XeTeX) with type-1 fonts, searching for U+021B doesn't find any matches. One has to search for U+163. This is unavoidable because searching in PDFs  works by AGL, not by code point (cf. Haralambous, "Fonts and Encodings", p. 659--661). The only way to fix this is to change the fonts themselves, but that's not freetype's business.

Also, I was worried that fontconfig may prevent some apps from working correctly because fontconfig keeps its own one-one mapping from AGL names to Unicode code points. But it doesn't seem to interfere. If you want my 2 cents on this, fontconfig doesn't need to be keeping its own map anymore; there are a bunch of fontconfig functions like FcFreeTypeCharIndex that duplicate what freetype does, but used to add some flexibility. Now that freetype has ft_extra_glyph_unicodes, those functions don't buy much anymore. Perhaps you should let Keith know about this...

Thanks a lot, Romanians are indebted to you :)
Vasile

P.S.: The obligatory "after" picture: http://www.cs.umd.edu/~gaburici/oo/ro-font-test2.png

Vasile Gaburici <vga>
Sun 27 Jul 2008 05:44:10 AM UTC, comment #4: 

This is fixed now in the CVS.  Please test.

 Werner LEMBERG <wl>
Group administrator
Sat 26 Jul 2008 11:00:59 PM UTC, comment #3: 

OK, will add a fix soon.

 Werner LEMBERG <wl>
Group administrator
Sat 26 Jul 2008 10:23:55 PM UTC, comment #2: 

Freetype doesn't just export the glyph names from a type 1 font. It also provides a mapping from Unicode to type 1 names. So, it seems to me freetype is the right place to fix the mapping. Does fontconfig normally request a glyph by type 1 name from freetype? As far as I can tell fontconfig only deals in code points.

BTW, fontconfig provides no user-configurable way to substitute a glyph with another glyph from the same font but at a different code point. I already checked this with Keith.

This isn't a locale dependent issue. That mapping needs to exist in any locale because U+021A/B are the proper code points for T(t)commaacent.

Vasile Gaburici <vga>
Sat 26 Jul 2008 09:56:13 PM UTC, comment #1: 

A preliminary note: As far as I know, Uniscribe is not the rendering engine on MS Windows.  It can rather be compared to ICU or Pango since it handles text strings and applies GSUB, GPOS, and similar tables.

Another preliminary note: The older MS Windows code page 1250 uses the (today incorrect) `cedilla' code points.  At that time it was natural for Adobe to follow that, and for backwards compatibility this won't get changed.

In my opinion it is the job of higher-level libraries to provide a proper replacement for such missing glyphs in Type 1 fonts.  You want a language specific behaviour, this is, you select a Romanian locale and expect that such an additional mapping is available.

FreeType isn't aware of such locales.  It just reports the bare facts of a font.

I think you should file a bug report for fontconfig: If the language is Romanian, it should try to map U+021A to `Tcommaaccent' in case glyph `uni021A' isn't available in the font.

Werner LEMBERG <wl>
Group administrator
Sat 26 Jul 2008 09:02:51 PM UTC, original submission:  

The proper way of writing Romanian in Unicode 3.0 and later requires using U+021A (respectively U+021B) for T (and respectively t) with comma below. See http://en.wikipedia.org/wiki/Romanian_alphabet#Unicode_and_HTML for details.

Adobe decided that T with cedilla does not appear in any language, so in AGL 2.0 they put a mapping from Tcommaaccent to U+0162, which is the proper code point for "t with cedilla"
(http://partners.adobe.com/public/developer/en/opentype/glyphlist.txt). AGL 2.0 is used as-is by freetype2 in glnames.py.

In order to use type 1 fonts for properly encoded Romanian documents, one needs an additional mapping from U+021A to Tcommaacent, and from U+021B to tcommaacent. This mapping is provided for instance by Uniscribe (the Windows Unicode renderer) at least on WinXP SP2 and possibly earlier.

So, what does this mean for the user? Since fontconfig usually sits above freetype, the missing glyphs U+021A and B get substituted from another font (see the attachment of a screenshot of Open Office on Linux). But exactly the same type 1 fonts and document work fine (no ugly substitution) on Windows with Uniscribe.

Unfortunately, freetype makes the (mistaken) assumption that there is a one-one mapping between Unicode code points and Adobe type 1 glyph names. Adding the additional mapping seem to require a serious restructuring of the psnames module, including its public interface.

If you're curious how Adobe solved this mess for OpenType fonts:
Tcommaaccent == U+0162 and uni021A == U+021A, although the two are visually indistinguishable in Adobe OpenType fonts.

Vasile Gaburici <vga>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #16188:  ro-font-test.png added by vga (54KiB - image/png - Screenshot of the missing mapping effect in Open Office)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by vga (Submitted the item)
  • -email is unavailable- added by vga (fedora fonts list)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-07-27 wl StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2008-07-26 wl StatusInvalid Confirmed
        Open/ClosedClosed Open
    2008-07-26 wl StatusNone Invalid
        Assigned toNone wl
        Open/ClosedOpen Closed
    2008-07-26 vga Attached File- Added ro-font-test.png, #16188
        Carbon-Copy- Added fedorafonts

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-54b4.
    Corresponding source code