While digging up the piles of HP spool files (basically what hpijs can generate for every HP models), apparently I put these two in the "already working correctly" pile, and they are supposed to be just generic color and general mono laser. Now they renders to very very large size and in the color case, also segfaults: WARNING: page width 42433.333333 at 600.000000 dpi exceeds available area, clamping width to 10800.000000 WARNING: page height 54983.333333 at 600.000000 dpi exceeds available area, clamping height to 6000.000000 WARNING: page width 42500.000000 at 600.000000 dpi exceeds available area, clamping width to 10800.000000 WARNING: page height 55000.000000 at 600.000000 dpi exceeds available area, clamping height to 6000.000000 WARNING: page width 42500.000000 at 600.000000 dpi exceeds available area, clamping width to 10800.000000 WARNING: page height 55000.000000 at 600.000000 dpi exceeds available area, clamping height to 6000.000000 WARNING: page width 41333.333333 at 600.000000 dpi exceeds available area, clamping width to 10800.000000 WARNING: page height 58450.000000 at 600.000000 dpi exceeds available area, clamping height to 6000.000000 Segmentation fault (core dumped)
Created attachment 24364 [details] generic color laser output from hpijs This is supposed to be generic color laser. According to where I put it, it used to work correctly around 2014 (to give the usual tiger).
Created attachment 24365 [details] generic mono laser output from hpijs generic mono laser. again, apparently it used to work correctly in 2014. Less sure about this one - apparently I wrote that pdfwrite from it was correct, but had problems with x11/display (probably because it is b/w).
Just on a hunch, I rememeber I have a system-wide packaged pcl6 binary from a ghostpdl 9.27 release, from CERT forensics. With ghostpdl 9.27, the Mono Laser file shows a dithered b/w tiger, while the Color Laser file shows the normal tiger. So these two files were working correctly in 9.27, and got broken somewhere since 2019, relatively recently.
You haven't given me a command line..... I've tried this with current code (SHA 53c97a4b5fa208722537064291f94ce524390ee7) on Windows and Linux, both debug and release with the following command lines: gpcl6 '/home/ken/tests/MonoLaser' gpcl6 -sDEVICE=tiff24nc -o /home/ken/out/out.tif '/home/ken/tests/MonoLaser' gpcl6 -r600 -sDEVICE=tiff24nc -o /home/ken/out/out.tif '/home/ken/tests/MonoLaser' gpcl6 '/home/ken/tests/ColorLaser' gpcl6 -sDEVICE=tiff24nc -o /home/ken/out/out.tif '/home/ken/tests/ColorLaser' gpcl6 -r600 -sDEVICE=tiff24nc -o /home/ken/out/out.tif '/home/ken/tests/ColorLaser' All (24) cases worked correctly. I do see warnings with the Linux display device, which will be the X11 device, which match what you describe, so it seems likely to me that you are using the X11 device. The rendered size, at 600 dpi TIFF, seems reasonable to me (looks like A4, 8.26x11.69 inches) and they do not seg fault with any of these command lines. Hard to be certain whether the X11 display is particularly huge, since it has no scroll bars, but it does not seem excessive, despite the given numbers.
Reopening and assigning to Chris to try and reproduce the seg fault.
Sorry, indeed it is x11 segfault. I guess that's what my comments in #2 about - it is likely that in 2014, I found the mono one was okay with pdfwrite but not with x11. Color was okay with both. I had a binary built with HEAD plus a few recent submitted patch (including the bits >3 part). Now x11 with both go to very large dimensions, and for color, then segfaults (the mono one shows a very magnified corner). With pdfwrite, the mono is okay, the color one segfaults, but that may be the bits >3 part. If it is the bits >3 part segfaulting x11, then I apologise. Either way, the x11 device has regressed since 9.27 with these two files. With 9.27, these two works okay on x11.
(In reply to Hin-Tak Leung from comment #6) > I had a binary built with HEAD plus a few recent submitted patch (including > the bits >3 part). Now x11 with both go to very large dimensions, and for > color, then segfaults (the mono one shows a very magnified corner). The file is rendered at 600 dpi, so I don't really see that as a problem. If you specify a resolution (eg -r72) then you can see the entire page with the X11 device. > Either way, the > x11 device has regressed since 9.27 with these two files. With 9.27, these > two works okay on x11. I'll wait to see what Chris discovers, but I do not see a regression here. Possibly a change in behaviour, I don't have a saved GhostPCL binary for Linux and don't really want to try to build one, but IMO if your file asks for 600 dpi then you should expect the X11 device to render the file at 600 dpi, which will result in a large canvas (approx 4956 x 7014 pixels). Which looks like what I'm seeing.
OK this is a change in behaviour, and it's quite deliberate. The change is due to this commit: https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=1030e59c64c93024c52fd7b33a8f5a4564c230ee So the fact that it isn't the same as 9.27 isn't a bug. If you want to see the whole page you'll need to tell Ghostscript to render specifically at a low resolution (eg -r72), otherwise it now honours the requested resolution from the input file. If I set the code in pcindexd.c to be 'if(bits > 3)' then I can reproduce the seg fault, if I leave it as 'bits > 2' then there is no seg fault. I'll leave this with Chris to close unless he thinks otherwise.
Hmm, but 600 dpi is almost the default for pcl's, and for any normal a4 doc, it gets to 42500 x 55000 . How many people have such a large screen? What is the windows screen output device's default behavior in this case?
OK, reading backwards the accumulated threads and bugs which changes x11 in various way, I think this is what Chris says about unexpected behavior: "It still leaves (what I consider) slightly unexpected behaviour when we are forced to clamp the values." Thing is, 600 dpi a4 is such a common case. The most common case now requires an additional switch to view in the most common usage of trying to have a general idea of most of the page...
(In reply to Hin-Tak Leung from comment #9) > What is the windows screen output device's default behavior in this case? It draws the page at 600 dpi. The Windows display device, however, has scroll bars....
(In reply to Ken Sharp from comment #11) > (In reply to Hin-Tak Leung from comment #9) > > > What is the windows screen output device's default behavior in this case? > > It draws the page at 600 dpi. The Windows display device, however, has > scroll bars.... It also, I'd assume, will give a sensible out of memory condition, rather than just crashing the entire UI. Given that X11 does just crash when asked for too much memory and, as far I could tall, there's no way for us to determine what is "too much memory", so we have to limit the size of the output raster to avoid that condition, if anyone has a better suggestion for that limit than "the size of the current screen", then I'm all ears!
This is a bit unfortunate. I think some years ago there were some gtk related code, and/or suggestions of adding scroll bars. Trying to get x11 to honour HWresolution is certainly a surprise behavior, particularly after it staying at a r72 default for a couple of decades.. This is generally document-author's preference vs document-viewer's too. Having scroll bars would be nice, or some kind of viewport-aided navigation axillary display (ImageMagick's display command's view port thing?). I am also not quite getting the bug submitter's issue - I think it was about some graphic objects being rendered at different resolutions? Why can't what -r72 be applied ie. Such objects are down-sampled etc instead?
(In reply to Hin-Tak Leung from comment #13) > This is a bit unfortunate. I think some years ago there were some gtk > related code, and/or suggestions of adding scroll bars. The gtk code is still around in psi/dxmain.c it uses the display device. But licensing was judged problematic as far as making it "core" to our bulids. > Trying to get x11 to honour HWresolution is certainly a surprise behavior, > particularly after it staying at a r72 default for a couple of decades.. > This is generally document-author's preference vs document-viewer's too. According to the guy here: https://bugs.ghostscript.com/show_bug.cgi?id=703308 *Not* honouring the resolution change was a change in behaviour. > Having scroll bars would be nice, or some kind of viewport-aided navigation > axillary display (ImageMagick's display command's view port thing?). Adding scrollbars in "bare" X11 or Xt apparently proved very hard. There was an open bug for it, but we closed it, since it showed no signs of happening. > I am also not quite getting the bug submitter's issue - I think it was about > some graphic objects being rendered at different resolutions? Why can't what > -r72 be applied ie. Such objects are down-sampled etc instead?