Bug 689691 - Error: /typecheck in --put-
Summary: Error: /typecheck in --put-
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: PC Linux
: P4 enhancement
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
: 688928 689673 689998 690072 690797 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-07 23:33 UTC by Marcos H. Woehrmann
Modified: 2023-11-15 17:33 UTC (History)
6 users (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2008-02-07 23:33:34 UTC
The customer reports and I've verified that Ghostscript 8.54, 8.60, and head
(r8518) all produce an error when reading the attached PDF files.

Acrobat Reader 8.0 and evince can both read the files without issue.

The command line I'm using for testing:

  bin/gs -sDEVICE=ppmraw -OutputFile=test.ppm ./1.PDF


Here's the tail of the output using -DPDFDEBUG:

%Resolving: [4 0]
<<
/Type /FontDescriptor /Ascent 718 /CapHeight 718 /Descent -207 /Flags 32 /FontBBox [
-170 -228 1003 962 ]
/FontName /Helvetica-BoldA /ItalicAngle 0.0 /XHeight 532 /MaxWidth 1000
/AvgWidth 493 /FontFile 5 0 R
>>
endobj
%Resolving: [5 0]
<<
/Length1 1236 /Length2 3641 /Length3 543 /Filter [
/FlateDecode ]
/Length 4458 >>
stream
%FilePosition: 2701
endobj
%Resolving: [31 0]
Error: /typecheck in --run--
Operand stack:
   --nostringval--   --dict:6/15(L)--   F1   1   --dict:9/9(L)--  
--dict:9/9(L)--   85801   --dict:9/9(L)--   false   --dict:9/17(L)--  
--dict:9/17(L)--   Private   --dict:14/19(L)--   --dict:9/17(L)--   Private  
CharStrings   --dict:32/32(ro)(L)--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904
  1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   2   --nostringval--   %for_pos_int_continue  
--nostringval--   --nostringval--   --nostringval--   --nostringval--  
%array_continue   --nostringval--   false   1   %stopped_push   --nostringval--
  %loop_continue   --nostringval--   --nostringval--   --nostringval--  
--nostringval--   --nostringval--   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1148/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--  
--dict:75/200(L)--   --dict:108/127(ro)(G)--   --dict:276/300(ro)(G)--  
--dict:23/25(L)--   --dict:4/6(L)--   --dict:25/40(L)--  
--dict:1148/1684(ro)(G)--   --dict:6/6(L)--   --dict:6/6(ro)(G)--  
--dict:75/200(L)--   --dict:1148/1684(ro)(G)--   --dict:6/6(L)--
Current allocation mode is local


The 2.PDF file produces identical output (except that the object numbers are
different):

%Resolving: [4 0]
<<
/Type /FontDescriptor /Ascent 718 /CapHeight 718 /Descent -207 /Flags 32 /FontBBox [
-170 -228 1003 962 ]
/FontName /Helvetica-BoldA /ItalicAngle 0.0 /XHeight 532 /MaxWidth 1000
/AvgWidth 493 /FontFile 5 0 R
>>
endobj
%Resolving: [5 0]
<<
/Length1 1236 /Length2 3641 /Length3 543 /Filter [
/FlateDecode ]
/Length 4458 >>
stream
%FilePosition: 2701
endobj
%Resolving: [27 0]
Error: /typecheck in --run--
Operand stack:
   --nostringval--   --dict:6/15(L)--   F1   1   --dict:9/9(L)--  
--dict:9/9(L)--   90109   --dict:9/9(L)--   false   --dict:9/17(L)--  
--dict:9/17(L)--   Private   --dict:14/19(L)--   --dict:9/17(L)--   Private  
CharStrings   --dict:32/32(ro)(L)--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904
  1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue  
--nostringval--   --nostringval--   --nostringval--   --nostringval--  
%array_continue   --nostringval--   false   1   %stopped_push   --nostringval--
  %loop_continue   --nostringval--   --nostringval--   --nostringval--  
--nostringval--   --nostringval--   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1148/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--  
--dict:75/200(L)--   --dict:108/127(ro)(G)--   --dict:276/300(ro)(G)--  
--dict:23/25(L)--   --dict:4/6(L)--   --dict:25/40(L)--  
--dict:1148/1684(ro)(G)--   --dict:6/6(L)--   --dict:6/6(ro)(G)--  
--dict:75/200(L)--   --dict:1148/1684(ro)(G)--   --dict:6/6(L)--
Current allocation mode is local
Last OS error: 2
Comment 1 Marcos H. Woehrmann 2008-02-07 23:33:53 UTC
Created attachment 3771 [details]
1.PDF
Comment 2 Marcos H. Woehrmann 2008-02-07 23:34:56 UTC
Created attachment 3772 [details]
2.PDF
Comment 3 Alex Cherepanov 2008-02-08 17:21:39 UTC
All Type 1 fonts in the sample PDF files are incorrect.
They have unbalanced curly braces near the end of the file.

   restore } if

There are other errors in the fonts inside eexec section.
We urgently need a Type 1 font reader that recognizes a few keywords
but ignores all the PostScript baggage.
Comment 4 Ray Johnston 2008-02-09 10:26:05 UTC
Can we adapt the Freetype Type 1 interpreter rather than re-inventing the
wheel?
Comment 5 Alex Cherepanov 2008-03-29 19:33:50 UTC
*** Bug 689673 has been marked as a duplicate of this bug. ***
Comment 6 Alex Cherepanov 2008-04-21 21:03:32 UTC
*** Bug 688928 has been marked as a duplicate of this bug. ***
Comment 7 Alex Cherepanov 2008-08-10 22:08:23 UTC
*** Bug 689998 has been marked as a duplicate of this bug. ***
Comment 8 Alex Cherepanov 2008-09-16 19:06:54 UTC
*** Bug 690072 has been marked as a duplicate of this bug. ***
Comment 9 Henry Stiles 2008-12-16 10:10:01 UTC
Alex will prepare a fix this week.
Comment 10 Masaki Ushizaka 2009-08-11 06:15:35 UTC
Tried with r9948 on MacBook Pro 13" + OS X 10.5.7 + Xcode 3.1.2.  Both file failed as described.
Comment 11 Shailesh Mistry 2011-07-28 17:27:03 UTC
Fixed in Ghostscript 9.03
Comment 12 Alex Cherepanov 2011-07-28 22:33:18 UTC
The problem is not fixed. Resent versions of Ghostscript trap errors and load
the font by name. Ghostscript still cannot use fonts that have PostScript errors.
Comment 13 Ken Sharp 2011-08-18 07:50:47 UTC
*** Bug 690797 has been marked as a duplicate of this bug. ***
Comment 14 Chris Liddell (chrisl) 2011-10-31 09:23:26 UTC
We've decided to pursue using Freetype (through FAPI) to provide a Postscript-independent Type 1 interpreter, hence it bouncing into my queue.

I'm in the process of working out what needs changed in Freetype to retrieve the Type 1 data, and have tacit approval from Werner for the additional Freetype API.
Comment 15 Chris Liddell (chrisl) 2012-03-23 15:30:33 UTC
Changed to enhancement, as it's handling a clearly non-compliant font.

This won't affect my scheduling of the work to handle it, though.
Comment 16 Henry Stiles 2012-09-09 16:16:51 UTC
Scheduled with language FAPI changes 9.07 (February)
Comment 17 Ray Johnston 2020-12-07 17:10:53 UTC
Tested with 9.53.3

Apparently fixed, as this runs with the expected error messages about the fonts:
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Querying operating system for font files...
Substituting font Helvetica-Bold for Helvetica-BoldA.
Loading NimbusSans-Bold font from %rom%Resource/Font/NimbusSans-Bold... 4419684 2869426 4661408 3312859 4 done.
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Substituting font Helvetica for HelveticaA.
Loading NimbusSans-Regular font from %rom%Resource/Font/NimbusSans-Regular... 4486156 3069706 5017952 3666348 4 done.
   **** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect.
Substituting font Helvetica-BoldOblique for Helvetica-BoldObliqueA.
Loading NimbusSans-BoldItalic font from %rom%Resource/Font/NimbusSans-BoldItalic... 4633428 3290258 5152296 3792678 4 done.

Closing as FIXED.
Comment 18 Chris Liddell (chrisl) 2020-12-07 18:03:42 UTC
This is *not* fixed, as can be see by the:

"**** Error: can't process embedded font stream,
        attempting to load the font using its name.
               Output may be incorrect."

message,
Comment 19 Chris Liddell (chrisl) 2021-01-07 17:39:17 UTC
Note that the intention is for this to be resolved with the transition to the new C based PDF interpreter - there is no practical way to divorce Type 1 fonts loaded from Postscript, from the Postscript interpreter.
Comment 20 Chris Liddell (chrisl) 2023-11-15 17:33:56 UTC
Works with the new PDF interpreter.