HTML label generator

Ever since we’ve been putting Holymate in bottles, we’ve started printing labels using a small dymo label printer, which would then add the ingredients, and other important information to the bottle. An example of these labels is shown below:

These labels were hardcoded, I originally designed them in gLabels, which worked fine, but was also a bit buggy in combination with my label printer (alignment/scale issues). When the need for printing dynamic labels, from a mobile device, started to become apparent due to a small tracking system; I switched to a small script PDF.js which had hardcoded label designs with dynamic information fields. This worked perfectly fine, but it did mean that the tracking system had some holymate-specific functionality programmed into the sourcecode. The MES system is otherwise completely generic, and doesn’t have any holymate-specific logic. In a real world you would probably use existing solutions such as Nicelabel or manually written ZPL’s.

A friend of me suggested using HTML to design labels, after I had been complaining about the lack of free-software alternatives to ZPL. HTML is a markup language, but its mostly meant for webpages, or other digital applications. Using it for real-world (printable) applications has creates some interesting problems. But it also very strong advantages: everyone involved knows it, and it allows for near unlimited customization of anything made using it (something that most other solutions would not be).

The good

There are a few very strong benefits for using HTML as a language for a label generator. I will point a few of them out below.

1. Previews
   A problem with ZPL is that there are no (good) free software solutions that can render a ZPL, which is usually done by a printer that supports it. There is an online API that can do it, but I am unwilling to use an external API, and in my experience this online API isn’t fully accurate. Rendering HTML however is very trivial in a web-environment; you’re viewing rendered HTML right now! Embedding dynamic HTML into a webpage does have some security implications however, which is why the browser has a specific element that is able to do that in a secure way, known as an iframe.

2. External resources
   HTML allows the user to create a layout, but it can also use external resources such as images, which are usually stored a separate files. But because I want the user to be able to create labels in a web-interface, which means that adding external resources would require a ton of additional work (buttons/popups/storage/life-cycle). But HTML has an escape hatch known as data uri’s. These allow embedding ‘external’ resources as base64 strings. This means that I do not need to deal with external resources at all, and that all label information can be stored in a single string. If this was not possible, I would need a way to upload/track/update/sync external files such as images, which would be a nightmare.

3. customization
   HTML allows near unlimited customization, if you can think of it, you can probably create it. This might be much more difficult using other platforms which haven’t had as many years as HTML to grow out their features.

The bad

HTML isn’t meant for printed applications, and that causes some problems which are highlighted below

1. Real-world units are a joke
   When working with real world, printable designs, using a unit known as ‘pixels’ is not ideal, and something independent to the DPI, such as ‘mm’ would be much better. and HTML does support real-world units such as MM. Its just that these are useless because they ate not real-world units at all. The HTML spec instead assumes that a screen has a set DPI, which means that each web ‘millimetre’ is hard coupled to a set number of pixels… You can see in the HTML spec that “1mm = 1/10th of 1cm” which is great! but the definition for cm is… “1cm = 96px/2.54”… special.. Theres is ofcourse an exception for high DPI devices to make it even better!

2. Automatically creating printable formats is complex
   Getting HTML rendered onto the screen is easy, getting HTML rendered onto a PDF file is not. Your browser supports it by just pressing ‘ctrl+p’, but doing the same from javascript to create an in-memory PDF file is quite a bit more involved. There are a number of libraries that can somewhat do this, but its all finnicky (especially related to fonts). In the end I resorted to rending the html to a png (using html2canvas), and then creating a single-page pdf with said png full-screen. (using pdf-lib)

3. Getting data into an Iframe is somewhat horrible
   A label is not a label if it doesn’t contain dynamic data. But because the label is a separate iframe, for security reasons, it is not trivial to send data back and forth. You are required to use a postMessage interface, and its just all very ugly.

The result

HTML works fine after dealing with the pros/cons described above, and we are printing web-pages that end up on bottles. :) If you use the monaco editor together with an iframe preview, and write a bit of supporting code to generate pdf’s from an iframe, you basically created a label designer. Which is exactly what I did. The result looks like this:

And it works perfectly fine. I also added a few handy utilities for creating barcode data uri’s and entering a lot-id to get a preview for a specific lot. A printed version of a label for HolyMate Grapefruit (recipe to be published soon™️) is shown below (coloured grapefruit icon added afterwards):