Stabilising module / line widths at various resolutions #198
-
Hi, I have been trying to get correct QR code bitmap output from the (very nice!) BWIPP library. 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: The resolution is set at 324 dpi in this document (line 15). 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/"'). 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, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
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:
This will provide you will a uniform starting point for each symbol. You can also probe your X-resolution automatically:
|
Beta Was this translation helpful? Give feedback.
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 …