• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

Cannot extract the embedded font 'T3Font_44'

Explorer ,
Jul 15, 2019 Jul 15, 2019

Copy link to clipboard

Copied

I get variants of this message when looking at a PDF with Acrobat Reader.

I understand that this is related to difficulties with a Type 3 font.  Hence the T3Font part of the message.

Does the "44" part (which varies, sometimes its 15, or 37, or 135, or 148) have any meaning?

Is it for example, the object number of the object that is a problem?  or something useful?

Or is it just an internal effectively random number?

Views

889

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Explorer , Jul 20, 2019 Jul 20, 2019

I found the problem.  It appears this message was being generated because in my PDF file, when I defined my Type 3 fonts, each character gets a "character procedure" which draws the character by the Do operator on an image.  The image Xobject is a stream.

The problem came with the representation of the image stream object.  Most of the objects were correct.  They were represented as a byte stream, and then compressed (using zlib -- /FlateDecode).  But some of the objects were too small to benefi

...

Votes

Translate

Translate
Explorer ,
Jul 20, 2019 Jul 20, 2019

Copy link to clipboard

Copied

LATEST

I found the problem.  It appears this message was being generated because in my PDF file, when I defined my Type 3 fonts, each character gets a "character procedure" which draws the character by the Do operator on an image.  The image Xobject is a stream.

The problem came with the representation of the image stream object.  Most of the objects were correct.  They were represented as a byte stream, and then compressed (using zlib -- /FlateDecode).  But some of the objects were too small to benefit from compression.  For example a 7 point period, at 600 dpi, is basically a small 7x7 image.  Since each row has to be rounded up to a multiple of 8, this becomes an 8 x 7 image,

which is then 1 byte by 7 rows -- 7 bytes total.  Compressing this image produces a compressed image of 12 bytes.  And if you then add the required "/Filter /FlateDecode", you lose even more.  So it's not a good idea to compress this particular character.   My code was noticing this, and not replacing the 7 byte uncompressed image with the 12 byte compressed image, but it was still marking the image as needing the /FlateDecode filter.  Once that was fixed, my PDF files work without error.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines