ICEpdf
  1. ICEpdf
  2. PDF-228

Chinese font substitution issue in windows

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: 4.2
    • Component/s: Font Engine
    • Labels:
      None
    • Environment:
      Windows
    • Assignee Priority:
      P2

      Description

      Attached pdf does not display correct fonts in Windows OS. Running fonts in a Mac OS/X environment displays the fonts fine.
      1. case9581-z1-logs.txt
        1.18 MB
        Arran Mccullough
      2. z1_log
        648 kB
        Arran Mccullough
      3. z1.pdf
        636 kB
        Arran Mccullough

        Activity

        Hide
        Arran Mccullough added a comment -

        z1_log - Logging from running on Mac OS

        Show
        Arran Mccullough added a comment - z1_log - Logging from running on Mac OS
        Hide
        Patrick Corless added a comment -

        I guess there are couple issue going on here. It looks like from the logs that font's in question aren't be loaded by the font engine, so I'll have to take a closer look at that.

        Once the failure occurs the code switches over to font substitutions so one again I'll have to see what font is being used on OSX vs. windows.

        Show
        Patrick Corless added a comment - I guess there are couple issue going on here. It looks like from the logs that font's in question aren't be loaded by the font engine, so I'll have to take a closer look at that. Once the failure occurs the code switches over to font substitutions so one again I'll have to see what font is being used on OSX vs. windows.
        Hide
        Patrick Corless added a comment -

        It turns out that there was a bug in our content parser logic and cmap logic. When text extraction takes place the toUnicode cmaps are used to map a CID to a String. In our old code we would make a CID to a char but there cases where CID can be represented by more then character.

        In the Pro version the issue only showed up with text extraction as it uses the toUnocide cmaps. A little work had to be done to fix the cmap parsing issue. The problem didn't show up at render time because Pro can property read and render CID fonts.

        In the OS version the issue showed up at render time and during text extraction. Some work had to be done to first correct the cmap parsing error so we could get the correct String for a given CID and the OFont class was updated to layout and draw the extra characters found in the returned Cmap string.

        Show
        Patrick Corless added a comment - It turns out that there was a bug in our content parser logic and cmap logic. When text extraction takes place the toUnicode cmaps are used to map a CID to a String. In our old code we would make a CID to a char but there cases where CID can be represented by more then character. In the Pro version the issue only showed up with text extraction as it uses the toUnocide cmaps. A little work had to be done to fix the cmap parsing issue. The problem didn't show up at render time because Pro can property read and render CID fonts. In the OS version the issue showed up at render time and during text extraction. Some work had to be done to first correct the cmap parsing error so we could get the correct String for a given CID and the OFont class was updated to layout and draw the extra characters found in the returned Cmap string.
        Hide
        Patrick Corless added a comment -

        Accidentally closed this bug instead of 239, this is still an outstanding issue.

        Show
        Patrick Corless added a comment - Accidentally closed this bug instead of 239, this is still an outstanding issue.
        Hide
        Patrick Corless added a comment -

        -r 26389

        Removed an overly assertive throw exception on state that shouldn't affect the code flow. Did a spot check on the document in question and it seems to be rendering the glyphs correctly now.

        Show
        Patrick Corless added a comment - -r 26389 Removed an overly assertive throw exception on state that shouldn't affect the code flow. Did a spot check on the document in question and it seems to be rendering the glyphs correctly now.

          People

          • Assignee:
            Patrick Corless
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: