Fop
  1. Fop
  2. FOP-1931

[PATCH] ToUnicode table for subset font contains invalid entries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Component/s: fonts
    • Labels:
    • Environment:
      Operating System: Linux
      Platform: All
    • External issue ID:
      51144

      Description

      In the ToUnicode table that maps character codes from a subset font to unicode characters, the first three entries map to unicode <ffff>. The first one is the .notdef glyph, so this is OK, but the following two might be incorrect.

      This is the beginning of such a table:

      21 beginbfchar
      <0000> <ffff>
      <0001> <ffff>
      <0002> <ffff>
      <0003> <002d>
      <0004> <0031>

      I posted a question on the fop-users mailing list on 2 may 2011. Mehdi Houshmand replied on 3 may 2011:

      Yes this is a bug, which has been fixed in my patch, but since I
      didn't think anyone else had bumped into it I didn't want to put it
      into trunk since I also made some code improvements to the class and
      was weary that it could cause merge issues when/if the branches are
      merged.

      The issue is that in most fonts the first 3 glyphs are set to .notdef,
      and this was implemented in FOP. However, the spec says only the first
      glyph is reserved for .notdef, and what happens in MOST fonts doesn't
      happen in ALL fonts.

      1. bug51144.patch
        2 kB
        Mehdi Houshmand

        Activity

        Hide
        Jeremias Maerki added a comment -

        Patch applied: http://svn.apache.org/viewvc?rev=1099852&view=rev
        Thanks, Mehdi. It's always funny when a bug surfaces that was essentially there since the beginning. For years, we've produced PDFs with three fixed entries at the beginning of a CID subset. I haven't found out why that was done so.

        Show
        Jeremias Maerki added a comment - Patch applied: http://svn.apache.org/viewvc?rev=1099852&view=rev Thanks, Mehdi. It's always funny when a bug surfaces that was essentially there since the beginning. For years, we've produced PDFs with three fixed entries at the beginning of a CID subset. I haven't found out why that was done so.
        Hide
        Mehdi Houshmand added a comment -

        Attachment bug51144.patch has been added with description: Removed 2 reserved glyphs from the CIDSubset

        Show
        Mehdi Houshmand added a comment - Attachment bug51144.patch has been added with description: Removed 2 reserved glyphs from the CIDSubset
        Hide
        Mehdi Houshmand added a comment -

        This patch seeks to address the fact that the first 3 glyphs are being reserved, where as only the first glyph should be reserved for .notdef.

        Show
        Mehdi Houshmand added a comment - This patch seeks to address the fact that the first 3 glyphs are being reserved, where as only the first glyph should be reserved for .notdef.

          People

          • Assignee:
            fop-dev
            Reporter:
            r.grosmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development