Re: printing QR-codes on labels with 300dpi label printers with LaTeX
hw <hw@adminart.net> wrote:
>> That is quite likely: the pst- prefix means this is PSTricks, which is
>> an oldish way of doing vector graphics with LaTeX. I tend to avoid
>> PSTricks these days as it is generally awkward to use in PDF contexts,
>> although there are various workarounds that often allow to do so.
>
> Is that bad? It works great for what I'm doing.
Well, “bad” is a strong word in this context. ;-) First, PDF has been
replacing PostScript in the last 20+ years, so it is often easier to
find tools that do interesting things with PDF than with PostScript.
Second, regarding the existing workarounds that allow PSTricks code to
be used in PDF workflows: I haven't used many of them but AFAIK, most of
the times, if you want things to work automatically, you need to enable
\write18 which has security implications. In the most relaxed case, it
allows the compiled document, as well as any class or package it loads,
to run arbitrary shell commands. There is a restricted mode for \write18
(see -shell-restricted and “§5.5 Shell escapes” in `texdoc web2c`), but
it currently doesn't allow running ps2pdf:
,----[ /usr/share/texmf/web2c/texmf.cnf ]
| shell_escape_commands = \
| bibtex,bibtex8,\
| extractbb,\
| gregorio,\
| kpsewhich,\
| makeindex,\
| memoize-extract.pl,\
| memoize-extract.py,\
| repstopdf,\
| r-mpost,\
| texosquery-jre8,\
|
| % we'd like to allow:
| % dvips - but external commands can be executed, need at least -R1.
| % epspdf, ps2pdf, pstopdf - need to respect openout_any,
| % and gs -dSAFER must be used and check for shell injection with filenames.
| ...
`----
One of the problems with PostScript is that it is “too powerful” for
something that should only produce text and graphics—AIUI, security
concerns were not at the core of its design.
Finally, for a few things like transparency and “new” font formats
(e.g., TrueType, OpenType), PostScript is either a no-go or has
solutions that appeared very late, contrary to PDF.
>> The ubiquitous, powerful and modern way to do vector graphics in LaTeX
>> is PGF/TiKZ[1],
>
> That package has almost 1300 pages of documentation which doesn't seem
> to mention qr-codes or barcodes.
Right. Presumably, the qrcode package is good enough. BTW, since its
\qrcode command produces a TeX box without using any TikZ code, it can
be placed without restriction in a TikZ node (I say this because TikZ
nodes can't be nested—more precisely, doing so is not supported).
> I wonder why it uses different options for URLs and other data. What
> difference does that make?
I believe you misunderstood the manual here, or maybe I don't understand
what you meant. The \qrcode command can encode both URLs and other text.
What I see is simply options (and the starred variant \qrcode*) to
decide whether to turn the QR codes into PDF hyperlinks.
Global switch at \usepackage level: hyperlinks/nolinks
Local switch for each \qrcode command: link/nolink
\qrcode*{…} == \qrcode[nolink]{…}
These options are provided because when the hyperref package is loaded,
QR codes are output as hyperlinks by default; however, it is quite
possible to write QR codes that don't encode URLs, in which case making
them hyperlinks would be confusing and useless.
> It might be worth a try for when I need to experiment with qr-codes on
> small labels again. It might not work because I may need to place the
> qr-code in some way and it could conflict with other packages like the
> labels package ... I even might have already tried it; it's been a
> few years and I don't remember exactly.
Since \qrcode outputs a TeX box without using any TikZ code, it has
about the highest level of “compatibility” you can expect in a TeX
document.
> Now I'm wondering why the qr-codes I printed with the label printer
> couldn't be reliably scanned. When I look at [1] and [2], for the
> data I wanted to print (between 38 and 40 alphanumericals at L
> quality) I would have to use a version 2 qr code, i. e. 25x25 modules.
> I don't know how the modules transfer to dots, but assuming the
> minimum of 4 dots per module, it would take 25 x 4 dots, i. e. 100
> dots. Each module would be 0.33mm in size which would require 25 x
> 0.33mm, i. e. 8.25mm for the size of the qr-code.
>
> I printed the qr-code much larger than that, about 1x1". That is
> about three times as large as would be required, and the printer can
> print three times as many dots per inch as the 100 dots needed.
>
> So in theory, my theory that the resolution of the printer is too low
> can't be true.
>
> But why couldn't these qr-codes be scanned? It shouldn't have been a
> problem at all.
L quality is the worst; can't you use a better one? Also worth
considering:
- scanner limitation? Did you try to scan the codes with a smartphone?
- printer matrix alignment if printer resolution is low (more
difficult; maybe try with some very small horizontal and veritical
shifts to see if it helps...).
Regards
--
Florent
Reply to: