While testing some of the new changes to the pxl driver, I noticed that the output has different sizes depending on whether I specify -dCompressMode=1 explicitly or not - but that's absurd since -dCompressMode=1 is the default. I looked at the difference between the two, and the difference is something like this: ! ubyte_array [ ubyte 1 ! 0000 40 @ ! ! ] FontName ! // Op Pos: 29954 Op fOff: 593793 Op Hex: 52 Level: 0 ! BeginChar ! ! uint16 347 CharCode ! uint16 659 CharDataSize ! // Op Pos: 29955 Op fOff: 593804 Op Hex: 53 Level: 0 ! ReadChar ! ! // Op Pos: 29955 Op fOff: 593805 Op Hex: FA Level: 0 ! embedded_data ! length: 659 ! [ .... ! ! ] ! ! // Op Pos: 29956 Op fOff: 594469 Op Hex: 54 Level: 0 ! EndChar ! ! uint16_array [ ubyte 1 347 ] TextData ! // Op Pos: 29957 Op fOff: 594477 Op Hex: A8 Level: 0 ! Text versus ! uint16_array [ ubyte 1 328 ] TextData ! // Op Pos: 29954 Op fOff: 593794 Op Hex: A8 Level: 0 ! Text i.e. one version adds a single glyph with charcode 347 to the font "@", and immediately uses it, while the other uses an existing character code 328. This "font" code isn't about fonts but supposedly is invoked by copy_mono/fill_mask to write a bitmap/mask as a "character". It is probably not a bug, but worth figuring out why specifying -dCompressMode=1 explicitly makes any difference at all the the pxlcolor output.
Non standard device parameters have to be initialized in the device, like they are in pclxl_open_device() and pxlxl_page_init(). It appears you are depending on get_params, specifically param_read_int() in the macro intoption to initialize the parameter but ghostscript outside the pclxl device knows nothing about this parameter "Compress Mode", so the read procedure returns 1 for missing parameter, and you shouldn't use the parameter value returned. There might be similar parameter problems in this device I didn't look carefully.
I think initialization in pclxl_open_device() or pxlxl_page_init() at least doesn't work, as they get called after put/get_params. Anyway, the indeterminism isn't about (would be extremely noticeable!) changes in the compress mode, but that the bit mask tile cache isn't looked up and used in the same way. I don't know where the bit mask tale cache is maintained, but it is outside of the pxl code. I can see one possibility how that might happen - under memory pressure, the cache probably throw away older entries, and therefore cannot look up and re-use older enries. But that's just a guess as I don't even know where is the part of the code which maintains the cache is.
(In reply to comment #2) > I think initialization in pclxl_open_device() or pxlxl_page_init() at least > doesn't work, No, there is one call before put/get but that is irrelevant, the two procedures are called then a subsequent put and get is called before anything useful is done with the parameters, pretty sure you can add the initialization and this will go away.
The problem is still there. The pxlcolor device without CompressMode parameter generates a file that differs from any file with CompressMode for any value of CompressMode.
There is no command line or specimen file for this bu, which immediately makes it invalid. I tried these command lines: -sDEVICE=pxlcolor -o nocompress.pxl sbom_minimum_elements_report.pdf -sDEVICE=pxlcolor -o compress1.pxl -dCompressMode=1 sbom_minimum_elements_report.pdf -sDEVICE=pxlcolor -o compress2.pxl -dCompressMode=2 sbom_minimum_elements_report.pdf Which produced these files: 17,036,656 compress1.pxl 14,072,339 compress2.pxl 17,036,656 nocompress.pxl So without specifying CompressMode I get the same result as CompressMode 1, as expected, and by specifying CompressMode 2 I get a different size, confirming that CompressMode is working.