Skip to main content
A
Anonymous
July 15, 2019
Answered

Cannot extract the embedded font 'T3Font_44'

  • July 15, 2019
  • 1 reply
  • 1700 views

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?

      This topic has been closed for replies.
      Correct answer

      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.

      1 reply

      A
      Anonymous
      Correct answer
      July 21, 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 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.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices