Title: | Digital PostScript printers and their associated software |
Moderator: | REGENT::LASKO HER |
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 |
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.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
7167.1 | REGENT::POWERS | Thu Apr 17 1997 10:43 | 41 | ||
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.2 | 61372::KINGSMILL | Geoff Kingsmill, Australia | Fri Apr 18 1997 08:13 | 10 | |
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.. |