Bug 690858 - pxlcolor: extra lines in first page
Summary: pxlcolor: extra lines in first page
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PXL Driver (show other bugs)
Version: 0.00
Hardware: PC Linux
: P4 normal
Assignee: Hin-Tak Leung
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2009-10-29 10:43 UTC by Marcos H. Woehrmann
Modified: 2009-11-23 17:59 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
a big patch for misc issues (9.31 KB, patch)
2009-11-01 18:54 UTC, Hin-Tak Leung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2009-10-29 10:43:15 UTC
The following files have extra lines on the first page when using pxlcolor (see
attached for an example):

  11-09.PS
  11-11.PS
  11-14.PS
  11-16.PS
  11-18.PS

Command lines used for testing:

  gshead -sDEVICE=pxlcolor -r600 -o test1.pxl ./$1
  pclhead -sDEVICE=ppmraw -r600 -sOutputFile=viapxl.ppm -dNOPAUSE ./test1.pxl

  gshead -sDEVICE=ppmraw -r600 -o direct.ppm ./$1


Note that when sending the GhostScript generated PXL files to an HP 4500 printer
page 0 is only partially printed and there are errors reported by the printer
(Error: UnsupportedProtocol), so there may be additional problems.
Comment 1 Marcos H. Woehrmann 2009-10-29 10:43:57 UTC
Created attachment 5579 [details]
11-09.PS.0.png
Comment 2 Hin-Tak Leung 2009-11-01 18:54:14 UTC
Created attachment 5599 [details]
a big patch for misc issues 

A big patch for various issues which I think should be broken down into
reasoned chunks and committed (after stripped of debug code).

This patch addresses a bunch of issues arising from the fact that PXL
co-ordinates  are signed 16-bit shorts. So

(1) to output negative co-ordinates, one needs to flip the 16th bit
(2) for co-ordinates larger than +-32767, I do a SetPageScale to span the
range, and also I found the smaller co-ordinates becomes inaccurate if I simply
scale (and clip to only +-32767), so I try look for small-co-ordinates and do a
SetPageOrigin before scaling (so that such points remains at (0,0). This
includes
  (2a) set cursor/move-to
  (2b) more complicated paths



- Some postscript files have slightly abnormal endings, where the vector device
finalizer is called before the output stream closes. This causes corruption of
the PXL stream because the PCL job footer is inserted towards but not quite at
the end of the output PXL stream. An explicit sflush(s) within close_device()
is needed for such postscript files.  This seems to apply to all the 11-*.PS in
this set.

- there seems to be a genuine typo from a previous patch for down-sampling
colors RGB->gray where the outcome is derived from (red + green + next_red)
instead of (red + green + blue).
Comment 3 Hin-Tak Leung 2009-11-01 19:07:41 UTC
This bunch of files have extra lines (and also missing lines, actually) because
the co-ordinates of the end points of the lines are coded wrong - and should be
okay when the big patch is committed.

The HP 4500 issue may be either the job footer corruption (fixed by the extra
sflush()) or a side-effect of the DeltaRow patch (bug 690069) - I changed the
header to PXL 2.1 since deltarow is a PXL 2.1 feature (not in 1.1/2.0). Maybe I
should make that 2.1 only when the user asked for that compression mode, if some
printers don't accept PXL 2.1 . 
Comment 4 Hin-Tak Leung 2009-11-02 11:22:52 UTC
 On the sflush, with the x11 device, their last page also flashes by, not
pausing back to the gs prompt when run. 
Comment 5 Hin-Tak Leung 2009-11-23 17:59:20 UTC
The big patch was broken down and committed as:

r10272 'Use SetPageScale and SetPageOrigin to work around 16-bit limit in paths.'
r10271 'Use SetPageScale to work around 16-bit limit in SetCursor'
r10270 'new SetPageScale/Unset utility routine'
r10269 'new SetPageOrigin utility routine'
r10268 'fixes age-old typo'
r10267 'write signed 16-bit integers properly'
r10264 'flush stream data in close_device()'