Stabilising module / line widths at various resolutions

[anauta00]

Hi,

I have been trying to get correct QR code bitmap output from the (very nice!) BWIPP library.
By correct I mean that the output 'QR code pixels' should consist of integer bitmap blocks (e.g. 2x2) of black and white.
I am using Ghostscript (latest release) for converting my .ps files to bitmap (png here) on a Windows machine.

What happens is that the 'correctness' of output depends on the resolution set (must be identical in the .ps file and the Ghostscript command line).

At any exact multiple of 72 dpi, all output is correct. At all other resolutions, the output is mixed (good and bad, depending on the QR code's location on the page).

I have included a small demo program demonstrating this phenomenon:
BWIPP_test.txt
[It is set as a .txt file here, so I could upload it. Please change the extension to .ps after downloading it...]

The resolution is set at 324 dpi in this document (line 15).
To generate a png from it I use the following command:
gswin64c -r324 -dNOPAUSE -dBATCH -sFONTPATH=c:/Windows/Fonts -sDEVICE=png256 -sGenericResourceDir="./Resource/" -dSAFER -dTextAlphaBits=4 -sOutputFile=BWIPP_test.png BWIPP_test.ps.

Note that I have the "Resource" folder from BWIPP in the 'current' folder (version 2022-07-29) to fetch the required code here (GS parameter '-sGenericResourceDir="./Resource/"').

The output looks like this:

As you can see, only the QR code at position 60,60 was rendered correctly. All others are off.

This is rather strange behaviour in my opinion, possibly related to rounding (errors?).

I have no idea where the problem lies exactly. It could be Ghostscript related but it is difficult to check as there are little alternatives (for postscript to bitmap).

I would be pleased to get some insight in this matter.

Thanks and greetings,
Auke Nauta

[terryburton]

Your solution is re-scaling the symbols based on the resolution in order to maintain the number of device pixel per barcode module, which is good.

However, you are positioning the symbols at coordinates in userspace that do not correspond to the devicespace grid. Therefore the plotting of the symbol begins at various different offsets of the device pixels and this results in pixel grazing because PostScript will light any pixel that is touched by the path. Pixel-grazing is described by way of example here: https://stackoverflow.com/a/36204327/2568535

You can snap the starting point coordinate to the grid by transforming it into devicespace, rounding, and then transforming the result back to userspace, as follows:

/round { dtransform round exch round exch idtransform } bind def
...
15 adj 60 adj round moveto qr_string options /qrcode /uk.co.terryburton.bwipp findresource exec

This will provide you will a uniform starting point for each symbol.

You can also probe your X-resolution automatically:

/SetDPI 72 0 dtransform abs exch abs 2 copy lt {exch} if pop def

[anauta00]

Hi again Terry,

Your solution works splendidly and makes a lot of sense.
And thanks for the additional function to retrieve the resolution automatically!
I learned a thing or two about postscript userspace and devicespace...

Greetings, Auke