[Bug 851790] New: Glyphs with multiple unicode encodings inhibit subsetting

bugzilla at redhat.com bugzilla at redhat.com
Sat Aug 25 20:43:13 UTC 2012


https://bugzilla.redhat.com/show_bug.cgi?id=851790

            Bug ID: 851790
        QA Contact: extras-qa at fedoraproject.org
          Severity: low
           Version: 17
          Priority: unspecified
                CC: fonts-bugs at lists.fedoraproject.org,
                    i18n-bugs at lists.fedoraproject.org,
                    petersen at redhat.com, psatpute at redhat.com
          Assignee: psatpute at redhat.com
           Summary: Glyphs with multiple unicode encodings inhibit
                    subsetting
        Regression: ---
      Story Points: ---
    Classification: Fedora
                OS: All
          Reporter: deron.meranda at gmail.com
              Type: Bug
     Documentation: ---
          Hardware: All
        Mount Type: ---
            Status: NEW
         Component: liberation-fonts
           Product: Fedora

Created attachment 607011
  --> https://bugzilla.redhat.com/attachment.cgi?id=607011&action=edit
Report on all the glyphs with multiple unicode encodings

Description of problem:
There are several glyphs which are mapped to more than one Unicode encoding at
the same time. These glyphs inhibit automated subsetting because it is not easy
to delete just one encoding slot without deleting both (as they share the same
glyph object).  See the attachment for a listing of these glyphs.

Version-Release number of selected component (if applicable):
liberation-fonts-2.00.0

Expected results:
Ideally these cases should use a glyph reference where stroke information must
be shared.

Additional info:
These glyphs are identified by looking at the alternate unicode encodings
property of the glyphs. If using the Python scripting to FontForge, look at the
'altuni' member of the glyph.  Also each glyph object for each encoding slot
should be a separate object.  For example in the regular serif font:

>>> font = fontforge.open('LiberationSerif-Regular.sfd')
>>> font[0xfb01]
<fontforge.glyph object at 0x7fdf4387d688>
>>> font[0xf001]
<fontforge.glyph object at 0x7fdf4387d688>

Notice how the glyph object id is identical for both U+FB01 and U+F001.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the fonts-bugs mailing list