I’m writing a piece of software to generate and print nametags. The issue I’m having is that nametags need to be formatted the same, but have different values (ie. different names, titles), and can be on different sizes of paper.
So I need an efficient way to store a sort of ‘template’ that has certain formatting info (alignment, size and location relative to document’s dimensions) and has placeholders for values to be substituted in. Then, at runtime, I need to be able to provide the dimensions of the nametag and the field values, to return a printable document.
My current approach is to have a bunch of pre-written HTML documents which have tables and different sizes, and then substituting the cell values with the given information. The problem with this is that HTML tables are really limited on positioning and sizing of elements. Plus, I end up needing to write javascript to resize and translate elements to handle different sizes of paper and really long field values, which limits code reusability as everyone needs to have the same JS or the files will produce different nametags.
Is there a better way to do this? Is there a printable document type that uses relative sizing and positioning for elements, such that if the values are edited the formatting will be preserved?
I would write my own file type (probably an XML structure) but then anyone using these files would have to use additional code to read my document and turn it into something printable.
7
I’ve tried a few things in this area, all with limited but acceptable success.
- HTML + CSS. With proper formatting (no
px
, alwaysem
, CSS paged media rules, etc) you can achieve nice-enough results. You need to be sure you have proper fonts installed at the printing site, and most likely you’ll have various headers / footers added by the browser on the page. You won’t get pixel-perfect results, at least not in a stable way. OTOH you’ll get your page nicely adapt to various text lengths, you can inject reasonable formatting tags if your text is not always plain, etc. - OpenOffice template documents. Lay out a document, define named fields, define a macro to replace them, then run it programmatically. OOo does run in a headless mode (
-headless
), so you’ll get a sort of ‘template-processing and printing server’. Beats other solutions when you need user-editable templates and when you need to export MS Word.doc
files. Not a piece of cake to set up, though. E.g. if you print a lot, you’ll need to manage a queue for parallel requests yourself. - PostScript. Only works if you have a postscript printer (most consumer-grade cheap printers don’t support it), or are willing to use ghostscript for printing. I created a bare-bones document, saved (‘printed’) it as PostScript, then edited to taste, to allow simple text substitution. Works great when you have a lot of line graphics, like legal forms, and want pixel-perfect printouts, but you don’t get any automatic layout: if a text string does not fit in a box, it will protrude outside. (You can handle this in PS, but making this reliably is often painful, for you’ll need to move more page elements than you think.)
Choose your poison.
I’d not look at PDF: what you get is basically all the limitations of the Postscript approach with none of its (relative) transparency and malleability. You can easily transform PS to PDF using ghostscript, though.
Is there a printable document type that uses relative sizing and positioning for elements, such that if the values are edited the formatting will be preserved?
Yes: PostScript. It’s a Turing-complete programming language and at the same time a domain-specific language for document layout which can be handled directly by nearly all modern printers.
I wouldn’t use HTML, because the printing can be a mess.
A better solution is to build up a PDF. Most of the external libraries are good enough to build your nametags. However, a lot of them don’t allow the usage of templates.
What I did for projects:
1) (A quite old version) We had an rtf-File with special placeholders. That was the template. We replaced the placeholders with out data and printed the concatinated file via the standard-application for rtf. Why rtf? It was easy to handle.
2) There are some libraries to process ODF. The allowed us to write the templates in an WYSIWYG-Editor and then we told an headless Libreoffice to produce an PDF out of it. The PDF was printed out and stored for later use.
Another PDF-leveraging option could be to use a PDF form: this can be filled in via a code process (there are both software libraries and web APIs that do this) and then ‘flattened’ into a printable PDF.