Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268167 > unrolled thread

libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

Back to article view | Back to linux.debian.user

Contents

  libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping Jeffrey Walton <noloader@gmail.com> - 2024-03-08 05:20 +0100
    Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage  shipping gene heskett <gheskett@shentel.net> - 2024-03-08 11:30 +0100
    Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage  shipping Charles Curley <charlescurley@charlescurley.com> - 2024-03-08 16:20 +0100
      Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping Jeffrey Walton <noloader@gmail.com> - 2024-03-08 16:40 +0100
    Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage  shipping Max Nikulin <manikulin@gmail.com> - 2024-03-08 17:30 +0100
      Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-09 17:30 +0100
        Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-09 21:50 +0100
          Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-10 04:30 +0100
            Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-10 05:00 +0100
              Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-10 08:50 +0100
                Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-10 09:20 +0100
        Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-10 01:00 +0100
          Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-11 03:00 +0100
            Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-12 21:00 +0100
              Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-13 18:00 +0100
              Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-14 10:50 +0100
                Re: printing QR-codes on labels with 300dpi label printers with LaTeX jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-14 11:00 +0100
        Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-10 04:00 +0100
          Re: printing QR-codes on labels with 300dpi label printers with LaTeX Florent Rougon <f.rougon@free.fr> - 2024-03-11 12:00 +0100
            Re: printing QR-codes on labels with 300dpi label printers with LaTeX Florent Rougon <f.rougon@free.fr> - 2024-03-13 11:40 +0100
              Re: printing QR-codes on labels with 300dpi label printers with LaTeX Florent Rougon <f.rougon@free.fr> - 2024-03-13 17:10 +0100
          Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-11 17:50 +0100
            Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-19 17:10 +0100
              Re: printing QR-codes on labels with 300dpi label printers with LaTeX "Thomas Schmitt" <scdbackup@gmx.net> - 2024-03-19 20:00 +0100
                Re: printing QR-codes on labels with 300dpi label printers with LaTeX Max Nikulin <manikulin@gmail.com> - 2024-03-20 18:00 +0100
                  Re: printing QR-codes on labels with 300dpi label printers with LaTeX "Thomas Schmitt" <scdbackup@gmx.net> - 2024-03-20 18:40 +0100

Page 1 of 2  [1] 2  Next page →

#268167 — libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

Hi Everyone,

I need to generate some shipping labels for drop-off at the USPS post
office using USPS Ground Advantage.

I have a USB thermal printer for the shipping labels,
<https://www.amazon.com/gp/product/B08V28J3JS>.

I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
module's GitHub at
<https://github.com/ssimms/business-us-usps-webtools>, but the
examples are on the lite side. I don't see a workflow similar to
creating and printing a shipping label.

My question is, can I use the module to create and print a shipping
label for a USPS Ground Advantage package?

Thanks in advance.

[toc] | [next] | [standalone]

#268169 — Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

On 3/7/24 23:15, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I need to generate some shipping labels for drop-off at the USPS post
> office using USPS Ground Advantage.
> 
> I have a USB thermal printer for the shipping labels,
> <https://www.amazon.com/gp/product/B08V28J3JS>.
> 
> I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> module's GitHub at
> <https://github.com/ssimms/business-us-usps-webtools>, but the
> examples are on the lite side. I don't see a workflow similar to
> creating and printing a shipping label.
> 
> My question is, can I use the module to create and print a shipping
> label for a USPS Ground Advantage package?
> 
> Thanks in advance.

Probably not Jeffery. the thermal printers output fades quickly in 
bright light or turns black in higher summer heat.  A laser printer 
using carbon toner is 10,000% more permanent. That and the shipping 
materials for labels are slowly going paperless, instead using a 
recyclable plastic label material, you should probably be asking for 
something compatible with the plastic paper labels.
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#268173 — Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

On Thu, 7 Mar 2024 23:15:13 -0500
Jeffrey Walton <noloader@gmail.com> wrote:

> I need to generate some shipping labels for drop-off at the USPS post
> office using USPS Ground Advantage.
> 
> I have a USB thermal printer for the shipping labels,
> <https://www.amazon.com/gp/product/B08V28J3JS>.
> 
> I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> module's GitHub at
> <https://github.com/ssimms/business-us-usps-webtools>, but the
> examples are on the lite side. I don't see a workflow similar to
> creating and printing a shipping label.
> 
> My question is, can I use the module to create and print a shipping
> label for a USPS Ground Advantage package?

charles@jhegaala:~$ apt-cache show libbusiness-us-usps-webtools-perl
Package: libbusiness-us-usps-webtools-perl
Version: 1.125-2
Installed-Size: 74
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Architecture: all
Depends: perl:any, libhash-asobject-perl, liburi-perl, libwww-perl
Description-en: Perl module enabling use of USPS Web Tools services
 Business::US::USPS::WebTools provides a Perl interface to the US
 Postal Service's Web Tools service. You need a UserID and Password
 to use these services. See the Web Tools site at
 http://www.usps.com/webtools/ for details.
Description-md5: 9c76d38752bb4c43151a4c8fe5224e7e
Homepage: https://github.com/ssimms/business-us-usps-webtools
Tag: devel::lang:perl, devel::library, implemented-in::perl
Section: perl
Priority: optional
Filename: pool/main/libb/libbusiness-us-usps-webtools-perl/libbusiness-us-usps-webtools-perl_1.125-2_all.deb
Size: 26856
MD5sum: 2323b592f161074380195b80880115e3
SHA256: 8341a6417ce7017af88cba6185042911c88d9024a2b886428ba0803946085c73

charles@jhegaala:~$ 

So I would start at the web site for the Web Tools.
http://www.usps.com/webtools/

On a brief scan of that site, I think the answer is yes, but you have
some software development ahead of you.
-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#268174

On Fri, Mar 8, 2024 at 10:16 AM Charles Curley
<charlescurley@charlescurley.com> wrote:
>
> On Thu, 7 Mar 2024 23:15:13 -0500
> Jeffrey Walton <noloader@gmail.com> wrote:
>
> > I need to generate some shipping labels for drop-off at the USPS post
> > office using USPS Ground Advantage.
> >
> > I have a USB thermal printer for the shipping labels,
> > <https://www.amazon.com/gp/product/B08V28J3JS>.
> >
> > I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> > module's GitHub at
> > <https://github.com/ssimms/business-us-usps-webtools>, but the
> > examples are on the lite side. I don't see a workflow similar to
> > creating and printing a shipping label.
> >
> > My question is, can I use the module to create and print a shipping
> > label for a USPS Ground Advantage package?
>
> charles@jhegaala:~$ apt-cache show libbusiness-us-usps-webtools-perl
> Package: libbusiness-us-usps-webtools-perl
> Version: 1.125-2
> [...]
>
> So I would start at the web site for the Web Tools.
> http://www.usps.com/webtools/
>
> On a brief scan of that site, I think the answer is yes, but you have
> some software development ahead of you.

Yeah, I was thinking the perl package is not very useful. I don't need
a perl wrapper to make a web service call. I need the other value
added stuff, like printing a label once I receive a successful
response.

Thanks.

Jeff

[toc] | [prev] | [next] | [standalone]

#268179 — Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

On 08/03/2024 12:35, hw wrote:
> On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:
>>
>> I have a USB thermal printer for the shipping labels,
>> <https://www.amazon.com/gp/product/B08V28J3JS>.
> 
> This printer has only 300dpi.  If you print QR-codes on it make sure
> you can scan them: they have to be large enough or get you an
> unscanable smear.

I believed that 300dpi is high enough resolution for QR-codes of 
reasonable size if source image has proper quality. On the other hand, 
if possible, it is better to scale QR-codes to match some whole factor 
of printer pixel size.

[toc] | [prev] | [next] | [standalone]

#268187 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 09/03/2024 19:08, hw wrote:
> On Fri, 2024-03-08 at 23:21 +0700, Max Nikulin wrote:
>> On 08/03/2024 12:35, hw wrote:
>>> On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:
>>>>
>>>> I have a USB thermal printer for the shipping labels,
>>>> <https://www.amazon.com/gp/product/B08V28J3JS>.
>>>
>>> This printer has only 300dpi.  If you print QR-codes on it make sure
>>> you can scan them: they have to be large enough or get you an
>>> unscanable smear.
>>
>> I believed that 300dpi is high enough resolution for QR-codes of
>> reasonable size if source image has proper quality. On the other hand,
>> if possible, it is better to scale QR-codes to match some whole factor
>> of printer pixel size.
> 
> What do you consider a 'reasonable size'?

Looking at a QR code likely having ~75 pixels per inch I find it 
unreasonably small for delivery labels. I am in doubts if its redundancy 
is high enough to reliably recognize it if it would be scratched during 
delivery. Another limitation may be stability of optics in scanners in 
respect to labels. This one is printed using a laser printer with 
resolution at least 600 dpi. Each QR code pixel has still 4x4 printer 
dots in the case of 300dpi, so when image is properly aligned, printer 
quality is not an issue.

> There is no source image other than whatever LaTeX creates.  I can
> specify the size of the QR-code.  Other than that, how do you apply
> scaling?

I am unsure what particular QR code generator do you use and what is the 
format of QR codes. Is it raster or vector image? Specify size that 
makes QR code pixels having whole number of printer pixels.

"Fit to page" or "fit to printable area" in printer options may make an 
image blurry. In the case of low input image resolution, upscaling 
method suitable for photos may make QR code blurry. However consistent 
configuration should make QR codes sharp.

[toc] | [prev] | [next] | [standalone]

#268189 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/3/24 00:20, Max Nikulin wrote:
>
> Looking at a QR code likely having ~75 pixels per inch I find it 
> unreasonably small for delivery labels. I am in doubts if its 
> redundancy is high enough to reliably recognize it if it would be 
> scratched during delivery. Another limitation may be stability of 
> optics in scanners in respect to labels. This one is printed using a 
> laser printer with resolution at least 600 dpi. Each QR code pixel has 
> still 4x4 printer dots in the case of 300dpi, so when image is 
> properly aligned, printer quality is not an issue. 

Standard thermal label printers are 203DPI (8 dots per mm).

The problem with printing QR codes and bar codes is not the resolution 
of the printer but getting the the software drivers to produce a bitmap 
that is the same resolution as the printer resolution and aligned at the 
pixel level when it goes to the printer

I have written a CUPS driver for a thermal printer and routinely print 
labels with barcodes and QR style codes. I have immense problems with 
PDF labels generated by my local postal service which are generated for 
a 300 DPI printer. The barcodes especially end up with too thick or too 
thin bars where the pixel mapping doesn't align. These will not scan.

I have asked the postal service to generate labels at 203dpi which will 
print just fine at 600 dpi and so work with laser and thermal printers, 
but they will not cooperate.

I am in the process of developing software to take the issued labels, 
extract the barcode and QR fields, decode them, and then generate new 
bitmaps at 203 dpi to replace  the misaligned bitmaps. This is not 
straight forward as the postal service does not fully comply with the 
coding rules.

In the meantime I have to extract the QR and bar code fields, enlarge 
them, and print on separate labels.

As far as printer drivers work, CUPS typically generates a bitmap from a 
source document such as PDF or postscript, and passes that to a raster 
printer. This in itself can be a problem as any stage of the process of 
generation of pdf, 'printing', and rasterisation can misalign and 
distort pixels. To be absolutely sure of clean output you need a custom 
program directly driving the printer.

[toc] | [prev] | [next] | [standalone]

#268192 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/03/2024 03:48, jeremy ardley wrote:
> 
> Standard thermal label printers are 203DPI (8 dots per mm).

Thanks, this number suits better to my expectation. I just trusted hw 
earlier.

> I have asked the postal service to generate labels at 203dpi which will 
> print just fine at 600 dpi and so work with laser and thermal printers, 
> but they will not cooperate.

Is the QR image a raster one? I am unsure concerning its printer dots 
per QR pixel ratio. Let's take e.g. 4 as a value inconvenient for direct 
scaling from 300dpi to 203dpi. I expect that upscaling it by 3 and 
downscaling the result by 4 with disabled smoothing (e.g. using splines) 
should generate an image that is 1.5% larger than the one suitable for 
203dpi. So setting 98.5% scaling for printer should allow to achieve 
sharp QR image without re-encoding QR.

You may try to find rational approximation for (4*208)/300 better than 
4/3 (or for actual QR pixel size).

[toc] | [prev] | [next] | [standalone]

#268193 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/3/24 11:21, Max Nikulin wrote:
>
> Is the QR image a raster one? I am unsure concerning its printer dots 
> per QR pixel ratio. Let's take e.g. 4 as a value inconvenient for 
> direct scaling from 300dpi to 203dpi. I expect that upscaling it by 3 
> and downscaling the result by 4 with disabled smoothing (e.g. using 
> splines) should generate an image that is 1.5% larger than the one 
> suitable for 203dpi. So setting 98.5% scaling for printer should allow 
> to achieve sharp QR image without re-encoding QR.


In my case I have never seen a bigger dogs breakfast of a pdf! It has 
many elements in different formats including bitmaps, scalable vector 
graphics, and text elements. That and some images are colour and some 
black and white. I just preprocess it

I have far less problems with the QR code (in my case data_matrix code) 
than with the barcode. The pixel elements of the QR code are much larger 
than the lines in a barcode so there is much less chance for pixel 
ambiguity.

I think i you make it 'big enough' it will scan fine. So a factor of 2 
magnification should work with a QR code.

I spent many (un)happy hours with gimp and imagemagick to try and get 
the best solution for barcodes. Sadly there is none other than print the 
barcode as big as possible in your page real-estate.

I spent an hour today with my friend GPT4 and python and I can now pluck 
out any and all codes from my mailing labels and I next plan to generate 
new labels at 203dpi using freshly encoded barcodes and data_matrix codes.

Here is some experimental code

from PIL import Image
import pyzbar.pyzbar as pyzbar
import qrcode  # For generating QR codes
from barcode import EAN13, generate  # Using EAN13 as an example; this 
might vary
from barcode.writer import ImageWriter
import os

from pdf2image import convert_from_path

def pdf_to_image(pdf_path, dpi=600):
     images = convert_from_path(pdf_path, dpi=dpi)
     for img in images:
         yield img

def detect_and_extract_codes(images):
     for img in images:
         detected_codes = pyzbar.decode(img)
         for code in detected_codes:
             print(code)
             if code.type == 'QRCODE':
                 # Process QR code
                 process_qr_code(code)
             else:
                 # Process other types of barcodes
                 process_barcode(code)

def process_qr_code(code):
     qr = qrcode.QRCode(
         version=1,
         error_correction=qrcode.constants.ERROR_CORRECT_L,
         box_size=10,
         border=4,
     )
     qr.add_data(code.data.decode())
     qr.make(fit=True)
     img = qr.make_image(fill_color="black", back_color="white")
     img.show()  # Or save the image

[toc] | [prev] | [next] | [standalone]

#268194 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/03/2024 10:51, jeremy ardley wrote:
> 
> I have far less problems with the QR code (in my case data_matrix code) 
> than with the barcode. The pixel elements of the QR code are much larger 
> than the lines in a barcode so there is much less chance for pixel 
> ambiguity.

 From your earlier message I count approximately 1000px for 5in (125 mm) 
barcode. If it is 1:1 to ~200dpi then it is incompatible with 300dpi 
printers, so it may be a reason why your proposal to the post office was 
rejected. If it is 500 black or white lines and each one occupies 2 
printer dots then 300dpi image of the same size has 3 dots per line. 
(Sorry, I am unsure concerning "module" term.) You should be able to 
rasterize PDF files to 600dpi (2x factor) and downsample them by 1/3 
keeping lines sharp.

Certainly this simple trick would fail if QR in the same file requires 
3/4 scaling.

> from pdf2image import convert_from_path

The pdfimage(1) tool may extract images in their original format, 
perhaps there is a similar python module.

>          detected_codes = pyzbar.decode(img)

Each barcode and QR code may be resampled individually without 
recognizing it. If position of each image on the page is known,
resampled images may be put back to correct places in the document 
rasterized to your printer resolution.

P.S. Post office guys may believe that labels created using laser 
printers are more resistant to wearing during processing and delivery, 
so 300dpi resolution may be intentional to discourage usage of thermal 
printers.

[toc] | [prev] | [next] | [standalone]

#268195 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/3/24 15:39, Max Nikulin wrote:
> From your earlier message I count approximately 1000px for 5in (125 
> mm) barcode. If it is 1:1 to ~200dpi then it is incompatible with 
> 300dpi printers, so it may be a reason why your proposal to the post 
> office was rejected. If it is 500 black or white lines and each one 
> occupies 2 printer dots then 300dpi image of the same size has 3 dots 
> per line. (Sorry, I am unsure concerning "module" term.) You should be 
> able to rasterize PDF files to 600dpi (2x factor) and downsample them 
> by 1/3 keeping lines sharp.

In barcodes such as Code-128 a module is 12 'slots' which at minimum is 
one pixel per slot or 12 pixels. Code-128 has over 100 character 
encodings in a module.

So code 128 on a 203dpi printer 12 * characters / 8 mm e.g. for 40 
characters it's 12*40/8 = 60mm. 2 pixels per module make it 120mm. 3 
pixels per module make it 180mm so too big for mailing labels.

As for my post office, their barcodes do not match 300dpi or 600dpi. 
They are scaled at about 75-80% of what they should be. I'm really 
surprised they work. I can only guess most people use 1200dpi.

Thermal labels are the way to go as they stick really well and resist 
water. They are also *cheap*. around 1-2 cents in bulk for 100x150 . 
Plastic envelope and laser printed label will cost 10-20c. A self 
adhesive laser label is getting on to 50c.

[toc] | [prev] | [next] | [standalone]

#268190 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/3/24 05:41, hw wrote:
> The QR-codes are sharp and easily scanable when printed in 600dpi.
> With the label printer you can't really tell if they're sharp or not.

As  mentioned in my previous post, thermal label printers are 203dpi, 
*not the 300 that the OP quoted.*

you can read the OP specs here which say 203. 
<https://www.amazon.com/gp/product/B08V28J3JS>.

Thermal label printers have no problems printing even long bar codes, QR codes, and data_matrix codes if the generator uses the correct dpi and the print process maintains the pixel mapping.

In my case my barcodes are 41 digits long (extreme GS1 !) and at 2 pixels per module (12 modules per digit) it is 123mm long which fits into a 150x100 thermal label

The data_matrix code (like a QRcode) for the same 41 digits is a 26x26 matrix which at 203dpi can have pixels of 8x8 dots in a field of 26x26mm. These are super easy for a thermal printer

[toc] | [prev] | [next] | [standalone]

#268197 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 11/3/24 07:34, hw wrote:
> Do you think that thermal transfer printers with 203dpi would be
> better suited to print QR codes than the 300dpi multi-mode printers?
>
> I'm not fond of thermal transfer at all.  Usually what is being
> printed that way fades rather quickly over time and is more slightly
> gray rather than black and so thin that it's hard to read even when
> freshly printed.  Perhaps better labels are available, but the labels
> must not get too expensive ...


Thermal transfer and thermal direct printers have the same resolution.

Thermal transfer printers are used for archival labels as they fade very 
little over time.

Direct thermal printers are intended for mailing applications where it 
doesn't matter if they fade after a few months.

Given that, I think a lot of commercial shippers use thermal transfer 
for mailing labels. Very few shippers use laser printed adhesive address 
label, nor non-adhesive in pockets or pouches.

To print a QR code or other 2D code on any thermal printer, the printer 
manufacturer will supply an application that generate the codes and 
prints them independently of the host printing system. These codes will 
scan perfectly.

It is possible to use document generation tools like latex and printing 
systems like CUPS to print a label, but pixel registration will be poor. 
The only practical option for this route is to print the code BIG

[toc] | [prev] | [next] | [standalone]

#268217 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 12/3/24 21:21, hw wrote:
>
> Even if they did that, it would be totally useless because it won't be
> able to automatically print labels from databases.

The manufacturer applications  usually allow you to print a list from a 
spreadsheet or text file.

>> It is possible to use document generation tools like latex and printing
>> systems like CUPS to print a label, but pixel registration will be poor.
> Why?  The manufacturer provided a CPUS printer driver without which
> printing wouldn't be possible at all.

Most custom barcodes programs run on windows and don't use CUPS.

Manufacturers can provide CUPS drivers as well, but the barcode 
application is usually only windows.

In my case I had to write my own CUPS driver as the manufacturer does 
not provide one.

Getting back to pixel registration, the latex CUPS route is very 
unlikely to work well. However a custom application that generates a 
pixel perfect bitmap that is printed at 100% scale through cups should work.

There are a number of programs that can do that, though I have not used 
them so far.

- zint

- GNU barcode

- BWIPP

also a possibility is

- qrencode

[toc] | [prev] | [next] | [standalone]

#268235 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 13/03/2024 02:50, jeremy ardley wrote:
> Getting back to pixel registration, the latex CUPS route is very 
> unlikely to work well.

TeX with MetaFont fonts worked well with low resolution dot matrix 
printers. Rasterized fonts may be generated for specified resolution. It 
should be still possible unless wide Unicode coverage is required.

I may be wrong, but I have impression that better support of modern 
vector fonts (TTF, OTF, etc.) in LuaTeX has other side. HurfBuz font 
library with priority to speed can not align characters to specified 
pixel grid. Likely nobody cares concerning font hints for low resolution 
devices.

Scale and position of images like QR codes should be adjusted to printer 
resolution.

More than a decade ago it was necessary to provide a document for 
archival purposes. I got a couple of complains: font with too thin lines 
and gray rather than black toner. The cartridge was refilled almost a 
dozen of times, but for routine documents quality was still good. 
CM-Super Type 1 font (converted from original Computer Modern with 
additions related to more scripts) really has hairlines. I configured 
metafont to increase minimal line width and generated a document with 
600dpi raster fonts using latex+dvips+ps2pdf instead of pdflatex. I went 
to a print shop nearby with hope to find there a printer filled with 
really black toner. The person there did not get the point why I was not 
satisfied looking into a test page from my document. It was blurry. 
Likely the page was scaled to printable area and dithering was applied. 
I preferred to go to another shop and got a stack of paper printed with 
proper quality. Either stuff there were a bit more experienced or 
default printer settings were more reasonable.

So it is not difficult to ruin efforts invested into print quality by 
inappropriate checkbox. The process is not fool-proof.

[toc] | [prev] | [next] | [standalone]

#268256 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 14/3/24 06:59, hw wrote:
>> Manufacturers can provide CUPS drivers as well, but the barcode
>> application is usually only windows.
>>
>> In my case I had to write my own CUPS driver as the manufacturer does
>> not provide one.
> How did you do that?

It is simply a C program that gets given some parameters and a bitmap by 
CUPS

The program processes the bitmap and frames it with printer commands to 
place the bitmap on the printer page.

CUPS abstracts the actual device interface (in my case USB). But in 
development I wrote the code to send commands directly to the USB device

>
>> Getting back to pixel registration, the latex CUPS route is very
>> unlikely to work well.
> It's working great here since years.  Barcodes are no problem, only qr
> codes can't be scanned.


This surprises me greatly. 2D codes have very large features compared to 
barcodes. They should be relatively immune to pixel quantization.

For reference on a 203 DPI (8 dots per mm) printer, a GS1-128 barcode 
takes up 12 modules per character. The minimum size of a module is 1 
pixel so 1 character is 12 pixels wide or 1.2mm on a 203 dpi printer.

Assuming a 40 character barcode at 1 pixel per module, it will span 48mm.

However it is very unusual to have 1 pixel per module. Instead at 2 
pixels per module the barcode is 96mm and at 3 pixels it will be 144mm

With the barcode you have no leeway in the pixel sizes. You must have it 
exact to scan.

In comparison, a QR code typically will have modules 8 pixels square and 
typically is 26x26 or 32x32 pixels. At 26x26  the printed code is 26mm 
square at 203dpi. You can afford to be out by a pixel at those dimensions.

If you have problems scanning QR codes at those sizes perhaps your QR 
codes are invalid to start with? If you print them out really large will 
they scan?

[toc] | [prev] | [next] | [standalone]

#268257 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 14/3/24 17:47, jeremy ardley wrote:
> For reference on a 203 DPI (8 dots per mm) printer, a GS1-128 barcode 
> takes up 12 modules per character. The minimum size of a module is 1 
> pixel so 1 character is 12 pixels wide or 1.2mm on a 203 dpi printer.
>
> Assuming a 40 character barcode at 1 pixel per module, it will span 48mm.
>
> However it is very unusual to have 1 pixel per module. Instead at 2 
> pixels per module the barcode is 96mm and at 3 pixels it will be 144mm


My error; The character spacing is 1.5mm at 203dpi. So 40 characters is 
60mm at 1 pixel per module, 120mm at 2 pixels per module, and 180mm at 3 
pixels per module. This means for a 40 character barcode you can at best 
print at 2 pixels per module on a typical 100x150m shipping label. This 
allows for no errors in quantization of pixel sizes and It's really hard 
to do with a printing system that does not start and continue with 
accurate pixel registration.

[toc] | [prev] | [next] | [standalone]

#268191 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

On 10/03/2024 04:41, hw wrote:
> \psbarcode{textblah foo}{height=0.6 width=0.6 eclevel=L}{qrcode}
> 
> That works for 600dpi laser printers.  When you print the QR-code with
> a 300dpi label printer you can't reliably scan it, not even when you
> make the QR-code 1x1" in size.
> 
> Perhaps that's not a reasonable size?

Perhaps height and width are chosen improperly. An image some percents 
smaller may be sharper.

- Find the dpi value in the specs of your printer
- Find number of pixels in QR code in QR specs (or just calculate them)
- Specify width and height so that the ration of 2 numbers above is a 
whole number.

Image may become a bit larger or a bit smaller.

[toc] | [prev] | [next] | [standalone]

#268199 — Re: printing QR-codes on labels with 300dpi label printers with LaTeX

Hi,

I haven't read the whole thread (sorry) but thought this might help.

hw <hw@adminart.net> wrote:

> When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
> Perhaps the pst-barcode package uses vector graphics?

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.

The ubiquitous, powerful and modern way to do vector graphics in LaTeX
is PGF/TiKZ[1], however this is not even necessary for QR codes, because
these are made of perfect monochrome rectangles, which TeX can draw
natively using its \hrule and \vrule primitives.

> 'pdfimages -list' doesn't show any images for a PDF with QR-codes
> created with pdflatex.

AFAIK, 'pdfimages' would extract “actual images” embedded in a PDF file
(e.g., PNG or JPG), however here pst-barcode presumably uses PostScript
or PDF primitives for drawing and filling polygons, which in your case
probably end up as PDF primitives. Hence, 'pdfimages' can't see these QR
codes (AFAIUI).

I've played with a different package for producing QR codes in LaTeX,
which uses the aforementioned \hrule and \vrule primitives: qrcode. Its
manual is here (follow the “Package documentation” link):

  https://ctan.org/pkg/qrcode

Here is a simple example you can compile with pdflatex:

\documentclass{article}
\usepackage{qrcode}

\pagestyle{empty}

\begin{document}

\noindent
% \qrset affects \qrcode commands in the current group. You can use it
% to factor out options used for several QR codes.
\qrset{nolinks, padding}% add padding to make sure the codes are “legal”/readable
\qrcode[version=1]{Hey Debian-user!}% Can't do version=1 with level=M or more
\qrcode[level=L, version=1]{Hey Debian-user!}% Less redundancy but is doable

\end{document}

Note the terminal output:

------------------------------------------------------------------------
<QR code requested for "Hey Debian-user!" in version 1-M.>
<Requested QR version '1' is too small for desired text.
Version increased to '2' to fit text.>
<Error-correction level increased from M to Q at no cost.>

<Copying the QR code for "Hey Debian-user!" in version 2-Q as previously calculated.>


<QR code requested for "Hey Debian-user!" in version 1-L.>

<Copying the QR code for "Hey Debian-user!" in version 1-L as previously calculated.>
------------------------------------------------------------------------

There are several quality levels allowing error correction (see the
manual): Low, Medium, Quality, and High. They correspond to 'level'
values L, M, Q, H. Default is M but if the chosen 'version' (which maps
to a specific number of modules) allows for a better level, qrcode
automatically upgrades to the best level possible for the chosen
'version' (which the above log demonstrates for the first QR code).

My example tries to print two QR codes with version=1, which means
21×21 modules (see below). Using the default level (M), this is not
possible for the specified text, therefore the first QR code is drawn as
a version=2 one (i.e., it has 25×25 modules). For the second QR code, I
explicitly ask for level=L which has the worst redundancy for error
correction; this allows "Hey Debian-user!" to be QR-encoded with
version=1, i.e. as a square of 21×21 modules.

The length of what you are encoding obviously dictates which quality
parameters you can afford, so you need to play with actual text for your
application. You can control the size of the QR code with e.g.
\qrcode[height=1cm]{...}. Since the modules are stuck to each other,
once you've determined an appropriate 'version' parameter, you can
easily choose a height that causes the modules to have the exact size
you want in the resulting PDF file (printer driver issues are out of my
league).

Regarding the 'version' parameter:

  version=1  → 21×21 modules
  version=2  → 25×25 modules
  version=3  → 29×29 modules
  ...
  version=40 → 177×177 modules

(each version step adds 4 to the number of modules in each direction)

So, you may want to play with text of yours and these parameters.
Examine the terminal output or log file to make sure the qrcode package
didn't have to increase the 'version' in order to encode the text you
specified. Note that in my example, the second QR code scanned with a
smartphone from a computer screen display seems to be significantly
harder to recognize than the first one (IOW, using level=L is probably a
bad idea even though it allows one to reduce the number of modules. But
with low printer resolution constraints, who knows?).

Hope this helps!

Regards

[1] https://ctan.org/pkg/pgf

-- 
Florent

[toc] | [prev] | [next] | [standalone]

#268221 — 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web