Bug 694978 - not working fix to Bug 694773 (missing RTL resolution)
Summary: not working fix to Bug 694773 (missing RTL resolution)
Status: RESOLVED LATER
Alias: None
Product: GhostPCL
Classification: Unclassified
Component: PCL raster (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks: 694950
  Show dependency tree
 
Reported: 2014-01-28 05:28 UTC by Hin-Tak Leung
Modified: 2023-05-23 15:49 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
tiger HP-GL/2 RTL (701.13 KB, application/octet-stream)
2014-01-28 05:28 UTC, Hin-Tak Leung
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hin-Tak Leung 2014-01-28 05:28:42 UTC
Created attachment 10620 [details]
tiger HP-GL/2 RTL

It appears that the fix to Bug 694773 (set missing RTL resolution to PJL setting) does not work completely.

Rather bizarrely, the PCL setting seems to get set at file exit, which is no use.

Here is a file to demonstrate the problem.

$ strings tiger.prn | grep RES
@PJL SET RESOLUTION = 600

If fix to bug 694773 did work, simply "pcl6 -lRTL tiger.prn" should just display the tiger. Instead, one needs to do:

pcl6 -J'@PJL SET RESOLUTION = 600' -lRTL tiger.prn

So somehow the fix to 694773 only works partly: it would take PJL settings from the command line, but not within the file itself. (In fact running in debug, shows that PJL setting within the file seems to be applied *after* the drawing is done, so are too late).
Comment 1 Hin-Tak Leung 2014-01-28 05:32:25 UTC
I came to this conclusion because the test file in Bug 694950 (same customer as Bug 694773) is affected.
Comment 2 Henry Stiles 2014-01-28 19:13:29 UTC
You need an ESC E to begin the job (just after the PJL).  That's what triggers PCL to read the PJL in the file.  Starting the program causes a reset as well, so PJL on the command line will get set even if the PCL file is malformed.  What device did you print this file on or is this a hypothetical problem?
Comment 3 Hin-Tak Leung 2014-01-28 22:36:21 UTC
(In reply to comment #2)
... What device did you print this file on or is this a
> hypothetical problem?

The file was generated by the "HP Designjet 4000 series HP-GL/2 and HP RTL Driver" version	"7.10 20 Oct 2012" for windows from the HP web site. Follow the URL:

http://h20565.www2.hp.com/portal/site/hpsc/public/psi/swdHome/?sp4ts.oid=431042&ac.admitted=1390976904379.876444892.492883150
Comment 4 Hin-Tak Leung 2014-01-29 02:02:41 UTC
It would appear that the test file in bug 694950 was made by an earlier version of the HP driver (the PJL says so, assuming it is correct).
Comment 5 Henry Stiles 2014-01-29 11:36:25 UTC
(In reply to comment #4)
> It would appear that the test file in bug 694950 was made by an earlier
> version of the HP driver (the PJL says so, assuming it is correct).

Okay I'll play with doing an implicit reset for RTL mode.  This file does look suspicious - it starts with an escape sequence followed by 150K of nulls, then the PJL.
Comment 6 Hin-Tak Leung 2014-01-29 15:55:58 UTC
(In reply to comment #5)
> Okay I'll play with doing an implicit reset for RTL mode.  This file does
> look suspicious - it starts with an escape sequence followed by 150K of
> nulls, then the PJL.

The HP people uses a certain amount of nulls to flush io buffers at the beginning of a job. This is done in hpijs for 10k. Maybe they think a A0 printer needs bigger flushing.