Personally, I would look at anything that can do absolute positioning (HTML with CSS, SVG, maybe LaTeX?, ...), and then create a template containing the fields for each of the 10 adhesive labels. Filling this template is then easy.

In the past I had good success with using HTML and mm units in CSS to position and size elements, but I've used a browser to print the HTML.

For SVG, you can use Inkscape to print to PDF or directly print the template.

In the past I had good success with using HTML and mm units in CSS to position and size elements, but I've used a browser to print the HTML.

Thanks Corion

I'd overlooked mm in CSS...I shall give that a go.

Using a browser to print the labels is actually preferable here. The data is accessed via a browser so using PDF or SVG formats would mean downloading a file and printing that, which is, of course, an extra step.

If you're going down that route, DNA Lounge Sign Generator, Wherein wrapping text remains the hardest problem in computer science..

I have a similar requirement. We print to A4 sets (8 labels per sheet) and do so via a simple script (fewer than 100 lines), no modules. The script reads in the address info, merges it and produces output in LaTeX. This is then converted to PostScript (by a makefile) and a viewer auto-launched for sanity checking before sending to the printer.

I've been using the same system for 20 years without issue. No doubt it could be made fancier but we have no need for that.

Publish the script here? Though in a perfect world for Bod's application, it would be standalone so it could run off a web server for remote people to download/print.

I hope that such remote access would be suitably secure, since it's got people's PII in it!

Sure, here you go. In my defence, this was written 20 years ago ;-)

#!/usr/bin/perl

use strict;
use warnings;

my ($ll, $numadd, @add);
my @labpos = (2, 3, 6, 8, 7, 5, 4, 1);

print "How many addresses? ";
chomp ($numadd = <>);
die 'Bad data' if ($numadd !~ /^[0-9]+$/);
print "How many labels left? ";
chomp ($ll = <>);
die 'Bad data' if ($ll !~ /^[0-9]+$/);

my $text = '\documentclass[10pt]{article}
\usepackage{epsf}

% was 23mm
\setlength{\oddsidemargin}{-20.5mm}
\setlength{\textwidth}{201.7mm}
\setlength{\topmargin}{-24.5mm}
\setlength{\textheight}{278mm}
\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt}
\pagestyle{empty}
\begin{document}
\setlength{\unitlength}{1mm}

\begin{picture}(99.1,67.7)
%%addlab1%%
\end{picture}%
\hspace{3.5mm}%
\begin{picture}(99.1,67.7)
%%addlab2%%
\end{picture}

\begin{picture}(99.1,67.7)
%%addlab3%%
\end{picture}%
\hspace{3.5mm}%
\begin{picture}(99.1,67.7)
%%addlab4%%
\end{picture}

\begin{picture}(99.1,67.7)
%%addlab5%%
\end{picture}%
\hspace{3.5mm}%
\begin{picture}(99.1,67.7)
%%addlab6%%
\end{picture}

\begin{picture}(99.1,67.7)
%%addlab7%%
\end{picture}%
\hspace{3.5mm}%
\begin{picture}(99.1,67.7)
%%addlab8%%
\end{picture}

\end{document}';
my $this = '
  \put(5,40){\parbox{80mm}{\Large \bf % was Large
%%addr%%
  }}
  \epsfxsize=15mm
  \put(81,47){\epsfbox{logo.eps}}
  \put(3,7){\scriptsize \sf If undelivered, please return to:}
  \put(3,4){\scriptsize \sf Hippo Enterprises PLC, PO Box 999,
  Ungulatesville, XL99 9XL}
';

for my $i (0 .. $numadd - 1) {
    $add[$i] = '';
    print "Enter address $i (terminate with .)\n";
    while ($_ = <>) {
        last if /^\./;
        $add[$i] .= $_;
    }
    $_ = $this;
    $_ =~ s/%%addr%%/$add[$i]/;
    $text =~ s/%\%addlab$labpos[8-$ll+$i]%%/$_/;
}

open OUT, '>address.tex' or die 'Cannot open outfile';
print OUT $text;
close OUT;

system ('make');
[download]

And the Makefile is just the standard

go:    address.ps
    gv address.ps

address.ps:    address.dvi
    dvips -o address.ps address.dvi

address.dvi:    address.tex
    latex address.tex
[download]

When entering the addresses, they will need to include the \\ for LaTeX line breaks. Add your own code for this in the Perl if you want that handled by the script instead.

Why the Makefile? Well, occasionally something happens which the preview shows to be a problem. Most often you can simply manually edit address.tex and re-run the make command from the shell rather than re-processing the whole thing from scratch. YMMV.

In case it isn't clear, the "How many labels left?" prompt is referring to the number of unused labels remaining on the sheet of 8. Since you're also wondering what @labpos is all about, that's because if you just use up a few labels on a sheet in the normal order of left-to-right, top-to-bottom, the label sheets we use are thin enough once the labels have peeled off the backing that the printer starts having problems feeding them through. Thus my engineered fix is to use them up in a staggered/chequered pattern.

If anyone did want to turn this into a web-based system, it would be easy enough. But then there would really be no point to the Makefile.

Hope this is useful to somebody.

---

🦛

I hope that such remote access would be suitably secure, since it's got people's PII in it!

Yes...most definitely...

The "remote people" are directors and employees with their own login and 2FA. The scripts to access the database reside above the webroot and all database calls are sanitised ^*. Plus, everyone accessing has undergone data protection training. We take data security seriously.

We have also started regularly penetration testing an environment that we've created for this purpose. The code is identical to our production site except that notification emails are turned off and we connect to the production database with an account with only SELECT permissions. We use ZAP for penetration testing.

^* I'm looking forward to the talk from LanX on this topic as we might be able to do even better.

There are dedicated label printers, accepting a roll of label media. Labels may be pre-cut or are cut by the printer. Usually, these printers use thermo-transfer, creating very robust labels. The printers usually emulate a legacy "Zebra" printer, and/or have their own manufacturer-specific printer language. Printer drivers for CUPS usually exist, so do drivers for Windows. But most times, your application generates a print job in the printer's language, without a printer driver.

I've worked with Zebra printers on a previous job, the Zebras can easily run several kilometers of labels without showing any signs of wear. You just have to clean then every now and then (paper leaves dust behind). I think that even cheaper printers for small office / home office should be able to handle more labels than you will ever need to print. The only part that may wear out is the thermal print head, depending on the quality of the labels.

Label printers come in different sizes, the smaller ones for address labels and the like are relatively cheap compared to the big Zebras that can print A5 sized labels.

Yes, those printers do not print on A4 media. But because they don't, neither the printer nor any software have to remember which labels have been peeled off and which are still usable.

Alexander

There are dedicated label printers

I've worked with label printers in the past. It would be a good solution.

However, the specification is A4 because more than one person has to print off the labels in different locations. I don't really want to invest in lots of label printers when everyone who will print them off already has an A4 printer and knows how to use it. If this was high volume, that might change, but it isn't.

If you're OK going online, I used the online app at avery.com when I printed out the name badges for TPRC 2023 in Toronto. It generates a PDF from a CSV file. it works beautifully -- all you do is enter the stock number of the Avery product you're using, and It Just Works.

If the online app could also create a .docx file, the really horrible approach ™ would be to take this .docx, and gut the XML in it into a template that is then filled by the templating system of your choice.

Alternatively, maybe it is possible to open the generated PDF in OpenOffice without disturbing the margins and spacing too much and then edit that XML there into a template.

This is a wonderfully evil idea. I heartily concur, and await further news about this despicable act. :D

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

docx is "just" zipped XML, so use your document as a template and type in placeholders for the address details.

If you choose the identifiers for the placeholders uniquely enough, a regex will suffice, to fill in the data after unzipping.

I think this is the easiest and safest "migration path" from your old process. ;)

(I know it's a hack, but it worked for me)

HTH :)

Update

Using unique <IDENTIFIERS> in the word editor should be fine. This can't collide with XML code because <> are escaped to HTML entities. Of course your regex must replace &lt;IDENTIFIERS&gt; then.

This has also the advantage that you can sanity check if placeholders were misspelled or new ones missed.

If I were you I would also fill the placeholders to the visual maximum size.

<_____IDENTIFIERS_____>

Like that you can catch overlong address data.

This works reasonably well. I've done something similar (Excel / OOffice spreadsheet) pulling the XML guts out, turning that into a TToolkit input file with a companion processing script. Users would run the template through the script with a CSV file of the actual data to create their report which the processor proceeds to zip the substituted template file back into a new zip / sxc / xlsx output file as the finished product.

The cake is a lie.
The cake is a lie.
The cake is a lie.

My intention was to have a stable process were the "template designer" is using word/libreoffice/etc as a visual editor.

I just tested my "concept" with LibreOffice, it's doing the job, except....

... sometimes intermittent <w:...> tags are injected into the placeholder, especially where the underscores are.

I have to manually mark them and choose "remove formatting" from the menu. I suppose it's word-break information.

(I can of course also correct it on the source level.)

So a manual correction is still necessary, if the translator throws errors.

HTH :)

Disclaimer: didn't try any other apps like MS Word or Google docs.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

UPDATE

here a sample of phantom tags included for a placeholder <___TEST___>

&lt;</w:t>
</w:r>
<w:r>
<w:rPr>
</w:rPr>
<w:t>
___TEST___&gt;
[download]

For anything that has to do with printing I always use LaTeX - since 34 years ago when I first entered the Sun computer lab at my alma mater and saw many happy hippies rendering LaTeX into postscript in reverse polish notation. I have never looked at anything else. Paraphrasing Fellini, "It's easier to be faithful to LaTeX than it is to a ...".

So, I would follow the advice of fellow monks and prepare the labels using LaTeX. My experience is that LaTeX is quite good at packing content in a single page in order to save paper. But it also supports various paper sizes. I am pretty sure there are many packages supporting creating labels. I know there is a package for beer bottle labels.

The crucial step in automating this process fully is by using templates. That is, templated LaTeX documents. The added bonus here is that, in this way, you keep View, Model and Controller separated.

I guess Libre/Open-Office also support some form of templates which one can, additionally, programmatically render into printer-ready documents. So, you can go this way, especially if there is a CPAN module for this.

Shamelessly, I will plug a module I have published LaTeX::Easy::Templates. It makes it fairly easy to supply a Perl Data Structure containing your data (e.g. an array of addresses) plus a LaTeX template file (in-memory or on-disk) and produce a PDF document.

Edit: I have posted a tutorial on how to print the labels using LaTeX::Easy::Templates here: Using LaTeX templates to typeset, use-case: printing labels

bw, bliako

I do a lot of printing (point of sales stuff). Generally, i to all the layouting ("printing") on a PNG of the correct pixel size, then send that off to a printer. Either directly as PNG when using CUPS, or converting it to printer specific encoding (ESC/POS for thermal receipt printers; ZPL for Zebra-compatible label printers).

As for specific implementations, i can't really recommend any. This is (for me, i've been doing this a long time) such a standard problem that i just usually write the few lines of code required by hand. Basically, you make the 5 strings, calculate where you want to position it in the PNG and you're done. If you want to go that route: I like to use GD