[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::postscript_printing

Title:Digital PostScript printers and their associated software
Moderator:REGENT::LASKOHER
Created:Wed Jan 24 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:7230
Total number of notes:31971

7167.0. "DCPS:A Offending command is BI" by 61372::KINGSMILL (Geoff Kingsmill, Australia) Thu Apr 17 1997 04:00

I'm having problems printing the postscript file in yakka""::bad_bi.ps. 
DCPS fails with:-
  "%DCPS-W-UNDEF, undefined: Name not known - offending command is BI"
Could someone please tell me if this bad postscript output from WNT Adobe
Acrobat Reader or whether its the printer (LPS17 V5.1) or DPCS V1.3?

Thanks,
Geoff..

Here's an abbreviated output around the first BI string. 
Full file in yakka""::bad_bi.ps

.
.
%%Page: 1 1
save
PDFVars/InitAll get exec
%PDF_BeginEncoding: F1 Helvetica
[/F1/Helvetica -1 TZ
%PDF_EndEncoding 
306 396 translate
-306 -396 612 792 RC
q
0.004 0 0 RG
0 w
[]0 d
0 J
0 j
0 0 0 rg
-128.008 183.566 m
-128.116 183.134 l
.
.
-128.116 183.674 l
-128.008 183.566 l
h
f* 
0.004 0 0 RG
0.216 w
[]0 d
0 J
0 j
0 0 0 rg
-116.992 185.834 m
-117.1 185.618 l
.
.
-117.1 185.942 l
-116.992 185.834 l
h
-116.992 183.782 m
-117.1 183.566 l
.
.
-117.208 183.998 l
-116.992 183.782 l
h
f* 
0.004 0 0 RG
0.216 w
[]0 d
0 J
0 j
0 0 0 rg
-110.512 179.462 m
-111.916 179.462 l
.
.
-110.512 179.894 l
-110.512 179.462 l
h
f* 
0.004 0 0 RG
0.216 w
[]0 d
0 J
0 j
0 0 0 rg
-104.572 183.566 m
-104.68 183.134 l
.
.
-104.68 183.674 l
-104.572 183.566 l
h
f* 
q
6.372 0 0 -4.968 -103.546 185.455 cm
BI
	/Width 59
	/Height 46
	/BitsPerComponent 8
	/ColorSpace /DeviceRGB
	/Filter /ASCIIHexDecode
ID
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FF00000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000FFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFF00000000000000000000000000000000000000000000000000
.
.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000000000000000
0000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
00000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFF>    
EI

Q
q
6.372 0 0 -4.968 2.883 185.455 cm
BI
	/Width 59
	/Height 46
	/BitsPerComponent 8
	/ColorSpace /DeviceRGB
	/Filter /ASCIIHexDecode
ID
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FF00000000000000000000000000000000000000000000000000000000000000
.
.

T.RTitleUserPersonal
Name
DateLines
7167.1REGENT::POWERSThu Apr 17 1997 10:4341
This is a strange file.
It is apparently assembled from separate files by concatenation.
This is usually a suspect operation, since the files from separate
sources can conflict in expectations for prolog and other matters.
There are at least three different types of line ending codes in the
file, at least as I can see them.  (This is the evidence that I use
to conclude that this is an assembled file.)

The errant areas are the image presention areas.
The offending syntax is

BI
  <image dict data>
ID
  <image data>
EI

None of BI, ID, or EI is defined in the file. (A guess - these are 
abbreviations for Begin Image, Image Data, and End Image.)

What's strange about BI is that image dict data is normally bounded
by syntactic characters to form a dictionary.  This string would be
the level 2 character sequence << (with >> to end the dict).
These strings cannot readily be inserted as procedural substitutions
(that is, '/BI { << } def' won't work).
BI and ID could be procedures to mark operand stack and collect
data into a dictionary, so that's not a fatal flaw.
Also, the image data itself is badly delimited.
The data src proc that should be part of the image dict isn't present,
but file filtering data is.  The data doesn't start with '<' as a fixed
hex-ascii string would, but it ends with '>', which could just be 
the hex-ascii terminator.

Okay, I apologize for the pedantry above, I was thinking out loud.
The bottom line is that something is missing from the file.
Since it appears to be (manually?) assembled from disparate sections,
I can suspect that the assembly process was incomplete.

Has the process that created this file ever worked for anything?

- tom]
7167.261372::KINGSMILLGeoff Kingsmill, AustraliaFri Apr 18 1997 08:1310
Tom,
    Thanks for the detailed response. The file history fits in with what you've
observed. Two postscript files were brought into Coreldraw V7, some additional 
text added and then written out in PDF format. This was then read with Adobe 
Acrobat which displayed the document without problems, however the print output 
postscript file from Adobe Acrobat Reader fails to print and as per your 
analysis is producing bad postscript output. Sounds like I should contact Adobe.

Thanks again,
Geoff..