bugThe FreeType Project - Bugs: bug #15056, suffixes in names of glyphs in...

 
 

bug #15056: suffixes in names of glyphs in Type 1 fonts

Submitted by:  None
Submitted on:  Fri 25 Nov 2005 05:11:26 AM UTC  
Votes:  20  
 
Severity: 3 - NormalItem Group: Incorrect behaviour
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.2

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Mon 16 Jan 2006 08:19:57 AM UTC, comment #10:

It seems the issue is fixed.

Andrey V. Panov <panov>
Wed 11 Jan 2006 10:05:30 AM UTC, comment #9:

This is fixed now in the CVS. Please test.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 16 Dec 2005 05:28:35 AM UTC, comment #8:

I have added a patch against psmodule.c. It resolves the problem, but does not account for a case when the only suufixed glyphs exist (e.g. font only has "a.init", "a.sc", "a.final" but not "a"). Note that strlen(NULL) may cause crash on some platforms (Windows).

Andrey V. Panov <panov>
Fri 09 Dec 2005 04:09:29 AM UTC, comment #7:

I suggest introducing unicode_ps_value() function on the base of ps_unicodes_init() for unicode->postcript mapping and call to this function in ps_unicodes_init().

Andrey V. Panov <panov>
Tue 06 Dec 2005 10:59:09 AM UTC, comment #6:

You are right. Still waiting for patches :-)

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 06 Dec 2005 04:47:46 AM UTC, comment #5:

In psmodule.c ps_unicodes_init() builds mapping from postcript names to unicode codes using ps_unicode_value(). Then this mapping is used in ps_unicodes_char_index() for reciprocal mapping from unicode codes to postcript names. But this is wrong solution since several postscript glyphs with suffixes may correspond to one unicode glyph.

Andrey V. Panov <panov>
Tue 29 Nov 2005 08:03:25 AM UTC, comment #4:

I now understand the problem and I agree that it would be
a good thing to fix ps_unicodes_init so that it selects glyph
`foo' if both `foo.bar' and `foo' are available.

Do you have time to implement this?

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 29 Nov 2005 03:53:31 AM UTC, comment #3:

>What do you mean with `install'?


Just make it available to X11 applications, that is add to fontconfig path.

Otherwise it may be reproduced by following command:

ftstring -m `cat aaaa.txt` 80 TemporaLGCUni-Regular.pfb

with attached file "aaaa.txt". Freetype selects "afii10017.csl" instead of "afii10017" and "guillemotright.grek" instead of "guillemotright", look at "wrong.jpg". The desired output made from opentype font version is displayed at "true.jpg".

Andrey V. Panov <panov>
Mon 28 Nov 2005 08:31:38 AM UTC, comment #2:

Werner,

First, I would like to stress the point that the problem Andrew has described is related with accessing Type 1 fonts from Unicode applications, where the font's encoding table is not used, and glyphs are accessed only by their names. Particularly I don't like this kind of "Unicode" Type 1 fonts very much, for the obvious reason that glyph names really don't represent a sufficient replacement for a CMAP table. However, people often have to use them, because it is too difficult to implement a well-instructed TTF font (and TTF instructions are subject to patent issues anyway), while OpenType-CFF fonts are still poorly supported by most X11 applications.

Now suppose we have taken a Unicode OpenType font, which includes some stylistic alternates, language-dependent forms etc., and converted it to Type 1, e. g. because we want to use it with OpenOffice.org. So, the CMAP table is now absent from the font, and only glyph names are remaning. Well, I would agree that, if we want just to map each glyph name to a specific Unicode, say, "e" and "e.fina" should equally be mapped to U+0065. However, usually we need just the opposite thing, i. e. obtaining a glyph with specific name by a Unicode codepoint, requested by user's application. In this case exactly one glyph should be selected, even if there are several alternates available. I had a look at psmodule.c, and can see that with the current algorithm it is absolutely unpredictable which glyph is returned by ps_unicodes_char_index and ps_unicodes_char_next, if there are several glyphs with the same Unicode codepoint assigned. Of course this may cause a terrible mixture of incompatible stylistic forms to be displayed in the user's application.

So, some priorities should be defined here. To my mind, it is quite clear, that, if a specific font includes both a basic glyph having a name without any suffixes, and some alternates with suffixes, then the first one should be preferred. May be, the selection should be done already in ps_unicodes_init, because I see no reason to keep references to several glyphs mapped to the same Unicode codepoint, if only one of them can be accessed anyway.

The attached font, Tempora LGC Unicode, can be used to demonstrate the problem. For example, it includes Greek (rounded) guillemets in addition to standard versions. If you install this font either for all X11 applications (via fontconfig), or just for OOo (via spadmin) you can see that the "guillemotleft" glyph is always selected for U+00AB, but "guillemotright.grek" for U+00BB. There are similar issues with some Cyrillic letters, which have alternate versions in this font. The problem can be reproduced in any X11 application which uses freetype, including OOo, KWord, Abiword, etc. Thus Type 1 fonts which include glyphs with suffixes in their names are just unusable with freetype, at least in Unicode applications.

Alexej Kryukov <anagnost>
Fri 25 Nov 2005 07:41:40 AM UTC, comment #1:

[You should log in so that a response reaches you immediately.]

> Freetype does not account for existence of a suffix
> in a glyph name with Type 1 fonts. Current algorithm of
> glyph selection in src/psnames/psmodule.c is
> unpredictable for application using freetype.


??? What are you referring to? The code in psmodule.c is
intended to map glyph names back to Unicode values (for
those fonts which don't have a Unicode cmap), and
stripping the suffix is the right way to do that, as
described in the AdobeGlyph List (AGL) algorithm.

> For example, install attached font TemporaLGCUni-Regular.pfb
> generated from Tempora LGC Unicode
> (http://www.thessalonica.org.ru/en/fonts.html).


What do you mean with `install'?

> Freetype selects "afii10017.csl" instead of "afii10017",
> "guillemotright.grek" instead of "guillemotright".


In which context? If you use FT_Get_Name_Index, nothing
is stripped from the glyph name.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 25 Nov 2005 05:11:26 AM UTC, original submission:

Freetype does not account for existence of a suffix in a glyph name with Type 1 fonts. Current algorithm of glyph selection in src/psnames/psmodule.c is unpredictable for application using freetype. For example, install attached font TemporaLGCUni-Regular.pfb generated from
Tempora LGC Unicode (http://www.thessalonica.org.ru/en/fonts.html ). Freetype selects "afii10017.csl" instead of "afii10017", "guillemotright.grek" instead of "guillemotright".

Obviously if font designer decided to add a glyph with a suffix besides unsuffixed one he (she) meant that both glyphs differ. For example ".sc" suffix is usually used to denote small capitals. Accordingly Adobe specifications http://partners.adobe.com/public/developer/opentype/index_glyph.html#6 , http://partners.adobe.com/public/developer/opentype/index_glyph2.html there is only one unification for such glyphs with suffixes: "Even when the original font file is present, glyphs which do not match characters in the Unicode specification may still be usefully connected to a Unicode character by the glyph name. For example, naming a decorative variant of "t" as "t.alt" allows a PDF producing program to note that "t.alt" carries the same semantics as "t", for searching."

I think at first attempt freetype must choose glyph with exactly the requested name.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #2419:  psmodule.c.diff added by panov (3KiB - text/x-patch - A patch against psmodule.c)
file #2567:  true.jpg added by panov (13KiB - image/jpeg - The same string displayed using opentype font (desired selection))
file #2566:  wrong.jpg added by panov (13KiB - image/jpeg - Wrong selection of glyphs from Type 1 font)
file #2565:  aaaa.txt added by panov (20B - text/plain - Sample unicode string)
file #2594:  TemporaLGCUni-Regular.pfb added by None (164KiB - application/x-font-type1 - TemporaLGCUni-Regular font)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 20 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 14 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 11 Jan 2006 10:05:30 AM UTCwlStatusConfirmed=>Fixed
  Open/ClosedOpen=>Closed
  Planned ReleaseNone=>2.2
Fri 16 Dec 2005 05:28:35 AM UTCpanovAttached File-=>Added psmodule.c.diff, #3192
Tue 29 Nov 2005 08:03:25 AM UTCwlStatusNeed Info=>Confirmed
Tue 29 Nov 2005 03:53:31 AM UTCpanovAttached File-=>Added true.jpg, #3143
Tue 29 Nov 2005 03:46:24 AM UTCpanovAttached File-=>Added wrong.jpg, #3142
Tue 29 Nov 2005 03:44:38 AM UTCpanovAttached File-=>Added aaaa.txt, #3141
Fri 25 Nov 2005 07:41:40 AM UTCwlStatusNone=>Need Info
  Assigned toNone=>wl
Fri 25 Nov 2005 05:19:41 AM UTCpanovCarbon-CopyRemoved -unavailable-=>-
Fri 25 Nov 2005 05:19:00 AM UTCpanovCarbon-Copy-=>Added -unavailable-
  Carbon-Copy-=>Added panov
Fri 25 Nov 2005 05:11:26 AM UTCNoneAttached File-=>Added TemporaLGCUni-Regular.pfb, #3132

Back to the top


Powered by Savane 3.1-cleanup1