The customer reports: We had been using version 1.41 of GhostPCL and ran into an issue previewing the output for a driver and decided to give the latest version of GhostPCL a try. I built version 1.53 under MS Visual Studio .NET 2003 using the following nmake command: nmake /f pcl6_msvc.mak MSVC_VERSION=7 DEVSTUDIO= The only change made to the make files was the inclusion of the bmpgray device into the list of output devices to be built. Once this new version of GhostPCL was built it was found that the handle io device we had been using to write the output bitmap was not working at all. The command line we would use would be along the lines of the following: pcl6.exe -r150 -dNOPAUSE -sDEVICE=bmp16m -sOutputFile="%handle%address-of-handle" path-to-spool-file No output would be generated at all. We worked around that using temp files and we found that the new version did fix our issue. However, a new problem seemed to show itself with drivers which had previously worked perfectly well with GhostPCL. We found that any Software 2000 PCL-XL drivers made by Ricoh for their range of printers would only display blank pages in the previews, on further investigation we found the same errors would appear every time we ran pcl6 on the commandline: Warning interpreter exited with error code -28 Flushing to end of job PCL XL error Subsystem: GRAPHICS Error: Internal error 0xffffffe4 Operator: Text Position: 46 file position of error = 38093 We were testing with some very simple Word 2000 files printing to a queue for the EB-135 PCL6 printer and it also happened on a Ricoh Aficio MP1350 PCL6. We stripped out as much as possible from the word files while attempting to ascertain what was causing the issue and found that any text at all in the file would result in the error. Word files with only graphics did not cause a problem, only if any text had been introduced (and even then subsequently deleted) would the error arise. I include a sample spoolfile of a Word 2000 file with an amount of text created using the =rand(n) command in Word. The exact same spool file used as input to version 1.41 GhostPCL produces perfectly fine preview bitmaps. The loss of the handle io device is bearable as we have a workaround, but the backwards step in support for these common drivers seems troubling. I do not see a problem with the build itself or with the parameters used in execution. If I am missing something I would appreciate any advice. If it is an issue with the current build of GhostPCL I would very much appreciate knowing if and when a fix may be available.
Created attachment 4658 [details] 00125.SPL
Passing to Leo for followup: ../gs/base/gxttfb.c(440): Returning error -28. Warning interpreter exited with error code -28 Flushing to end of job
Ah this is another True Type Collection problem. The user is trying to download a true type collection which we do not support. Also note the pcl was probably generated for the EFI rip base on reading the PJL on the top of the file. I don't know if this means the pcl has been customized for an efi device.
This should have been reassigned back with comment #3.
Created attachment 4728 [details] testfiles.zip additional test files with similar problems.
*** Bug 690105 has been marked as a duplicate of this bug. ***
We are still working on how we want to handle this. The problem is the driver writer is using a truetype collection header with a truetype font, resulting in a corrupt font. It looks like HP and other PCL rips don't look at the header and simply treat everything as truetype. If you are only running pcl the following patch is a workaround until we have a permanent fix. svn diff Index: base/gstype42.c =================================================================== --- base/gstype42.c (revision 9528) +++ base/gstype42.c (working copy) @@ -153,6 +153,7 @@ static const byte version_ttcf[4] = {'t', 't', 'c', 'f'}; READ_SFNTS(pfont, 0, 12, OffsetTable); +#if 0 if (!memcmp(OffsetTable, version_ttcf, 4)) { version = u32(OffsetTable + 4); if (version != 0x00010000 && version !=0x00020000) { @@ -169,11 +170,12 @@ } else { OffsetTableOffset = 0; } - if (memcmp(OffsetTable, version1_0, 4) && memcmp(OffsetTable, version_true, 4)) return_error(gs_error_invalidfont); - +#else + OffsetTableOffset = 0; +#endif numTables = U16(OffsetTable + 4); if (numTables > MAX_NUM_TT_TABLES) return_error(gs_error_invalidfont); Index: base/ttfmain.c =================================================================== --- base/ttfmain.c (revision 9528) +++ base/ttfmain.c (working copy) @@ -229,6 +229,7 @@ this->tti = tti; this->design_grid = design_grid; r->Read(r, sVersion, 4); +#if 0 if(!memcmp(sVersion, "ttcf", 4)) { unsigned int nFonts; unsigned int nPos = 0xbaadf00d; /* Quiet compiler. */ @@ -248,6 +249,7 @@ } if(memcmp(sVersion, sVersion1, 4) && memcmp(sVersion, "true", 4)) return fUnimplemented; +#endif nNumTables = ttfReader__UShort(r); ttfReader__UShort(r); /* nSearchRange */ ttfReader__UShort(r); /* nEntrySelector */
*** Bug 690323 has been marked as a duplicate of this bug. ***
fixed in ghostpdl 9600.
Changing customer bugs that have been resolved more than a year ago to closed.