Menu
▾
▴
#306 Feature Requests
It would be better if Zint provide us with these features given below:
- Using different fonts for barcode text.
- Increasing or decreasing character spacing between barcode text.
- Creating text as captions at the top of 1 Dimensional barcodes.
- Placing an image at the centre of a QR Code.
Related
Hi Fahim,
Thank you for your interest in the Zint project and for your comment regarding features you would like to see. The features you have requested are all ones which have been discussed before either here on SourceForge or in the mailing list, so apologies that this will be a long answer to your request, but thank you for this opportunity to give a full answer about where Zint fits in relation to such requirements.
For context let me first set out the "mission" of the Zint project as I see it which is:
(a) To make available, in a free and open source manner, a tool to convert data into a machine-readable barcode symbol represented as an image in a file.
(b) To support as many methods of encoding that data as possible. In other words, to support as many symbologies as possible, bringing them together in one solution.
(c) To act as a record, in code form, for how such data encoding should be implemented. This requires compliance with standards, whether internationally recognised or merely as established by the creator of the symbology, as well as adherance to best practice if any has been agreed in the industry.
(d) In accordance with the Unix philosophy the above is considered 'one job' and anything beyond this is therefore beyond the scope of the project.
The intended use of Zint is that it allows the user to create any barcode symbol, which should then be passed to other software for further processing before being output to physical media. For the sake of argument let us call this other software the 'label maker', but could be a DTP package, web script or any number of other things as needed. This means that considerations such as the size and position of the symbol once printed and any associated text, borders and any consideration which is not the machine-readable portion of the barcode symbol should be handled by the label maker and not Zint. Having said this, sometimes only simple requirements are needed or are part of the standard, and for this reason simple implementations of common requirements, like borders on ITF-14, text for UPC/EAN and reverse colours of QR Code, are provided by Zint and extended to all symbologies supported. As per point (d), however, a line has to be drawn somewhere about what should be included and what should not.
Please also be aware that this project is maintained by volunteers and, at least at the time of writing, does not receive any financial income to support development. In practice this means that it is in our interests to limit the complexity of the project to what can feasibly be supported, bug-fixed and otherwise maintained.
Relating this back to your requests, the first three relate to human readable text:
Placing an image on top of a QR code is a strange phenomenon which I strongly discourage. Firstly it is not standard compliant, and so therefore is not included in Zint in pursuance of point (c) of the "mission" set out above. More than that, however, it is actually a mutilation of the symbol. What I mean by this is that when you place an image over a QR code you are actually covering up or removing some of the data from the symbol. The reason this does not usually cause problems for the end user is because QR codes contain robust methods for recovering data after the symbol has been damaged. Relying on these methods for recovering the data mean greater processor overheads for the barcode reader and also reduce the ability of the reader to cope with any further degradation of the symbol.
As an analogy imagine of you were making a DVD rather than a barcode. I'm sure it would be possible to scratch a pattern into the surface of the DVD which contains the data and, depending on the amount of scratching and the pattern used, still be able to extract the data enough to watch the content. If, however, you were to accidentally drop that DVD and scratch it further you are more likely to reach the point where the DVD is no longer readable. We usually protect DVDs and try to prevent scratching, so it's odd that QR codes are deliberately 'pre-damaged' in this way.
If you are asked to create a QR code with an image in the center I would encourage you to ask why this is considered important and if the person asking for it is aware that this makes the symbol less likely to work as intended.
If you are not convinced by this argument, however, and still want to place an image over a portion of any barcode symbol then I would suggest that this is also something which should be handled by the 'label maker' as previously mentioned, which should also give you much more control over the size, shape and position of the image than would be practical within Zint.
So, in summary: (1) is partially implemented already, (2) is unlikely, (3) may be included in the future and (4) is actively discouraged.
I hope this all makes sense. I appreciate that you were probably not expecting such a lengthy response to your request, but I thank you for allowing me to put all of this in one place for the benefit of others.
Robin.
Last edit: Robin Stuart 2024-01-11
Thank for the extensive explanation and tight, logical reasoning (which is sometimes lacking with devs). I will say that there is an increasing use case for "branded" QR codes (i.e. codes having a small portion dedicated to whatever the creator of the code wishes to place there, like a logo), as many deceptive services like qr-code-generator.com offer (they should be sued for their unfair business practices, in my opinion).
Anyway, why is this important? There are at least two reasons.
1) As QR codes have become more ubiquitous, quickly identifying or differentiating between codes for a user becomes important from the user's standpoint. Visual graphic-based information that is part of the otherwise machine-only code helps facilitate QR code identification and association by the human brain. We are visual creatures and rely on past experience to identify new information in our environment, such as encountering a sign with multiple QR codes. For my own use case, I have had at least three QR codes on a single 8.5x11 sheet of paper, all of which are in close proximity to one another (it is undesirable/infeasible to have them spaced apart). While there is adjacent text explaining which codes do what, the human process of selecting from among those codes that look indistinguishable is slow. That leads to poor user experience. Humans process visual information differently than machines: contextual cues based on prior experiences (i.e. brand recognition) to distinguish between otherwise indistinguishable codes increases both speed of acquisition and confidence in the ultimate selection. The speed that a human being can distinguish between three closely-placed codes is vastly increased when associated with a corresponding visual (human understandable) element, like a logo.
2) Another reason why so many are asking about logos and graphics directly part-and-parcel with the QR code itself is marketing and branding from the creator's standpoint. There is no doubting the power of brand recognition, and logo-type brands rather than alphanumeric text. This is especially important for QR codes because a user, in scanning the code, looks directly at it (not the adjacent text) to ensure their camera focuses on the code. That means their eyeballs are looking for critical seconds directly at a brand as it's being scanned. That is immense value to many who deploy QR codes in their businesses. I would wager to say most business already do this or would want to do this if they could.
It is unfortunate if co-located graphical "whitespace" has not become part of any standard yet, but it should and might well in the future. While I don't expect the Zint devs to accommodate something currently out of spec, I thought this explanation might help illuminate why the "graphic-on-top" is being implemented by many paid-for services: there's real demand for that functionality.
In the meantime, I'll have to learn more about error correction and perhaps play with code generation to accomplish the desired result--even if nonstandard.
An interesting use case that I ran across recently which blurs the line between "standard" and "non-standard" is the Swiss QR Code, which requires that a Swiss cross be placed over the QR Code: https://www.six-group.com/dam/download/banking-services/standardization/qr-bill/ig-qr-bill-v2.2-en.pdf
Indeed, Swiss QR Code prioritises brand identification above data integrity, which is questionable given the use case.
It requires that symbols be scaled to a fixed size irrespective of the version of the QR Code symbol that is generated (module count) or the DPI of the printer. This requirement precludes grid-fitting (nudging the module size to an integer multiple of the printer's dot pitch). It is telling that the examples symbols provided by the specification are low-resolution, anti-aliased bitmaps.
It does not give any consideration to practises such as padding to a fixed version, nor opportunistically raising the error correction level when doing so, which could make the scheme somewhat more robust.
The form of a QR Code, but not an ISO 18004 QR Code!
Daniel,
the Swiss cross was the Swiss payment code.
They tried to get it as CEN standard and to get this, the cross was removed.
In addition, the copyright Owner of QR-Code (Denso Wave) constantly
stops QR-code creators which are not normative, for example by including
an image.
Take care,
Harald
Am 28.06.2024 um 17:39 schrieb Daniel Gredler:
Related
Tickets: #306
Griffin, thank you for your post on this topic - you make a good case for the use of visual identifiers to accompany machine-readable code, and I am convinced by your argument that there is a need for this functionality. As annoying as it seems to me that people use QR Codes in this way I can see that there is a reason why they do so.
My counter-argument, however, is that, for the reasons I previously stated, QR Code is not the way to do it. Although QR Codes are pretty clever, they are also now 30 years old, and were not designed with this type of use in mind. What is needed is a new symbology which incorporates this usage into the specification - and indeed there already is at least one example of how it could be done in the form of the Apple App Clip.
Of course I say this not having any idea how the App Clip symbol works - for example whether they are capable of holding actual data or just a lookup key like HCCB or CueCat did. They seem to be fixed-size but I see no reason why a solution could not be created that expands in size in a similar way to Aztec Code. Unfortunately, as Apple are notoriously secretive and litigious, I suspect we may never know how these work - but they at least show what is possible.
Having said this I appreciate that you, like most of us, are probably in a position where you just need something which works and you need it today... not some ideal solution which may catch on sometime in the future.
As a side note I notice that some sites refer to the App Clip symbol as the "App Clip QR Code" which, I am sure, must really irritate the folks at Denso Wave.
Thanks again for your well-considered argument.
Robin.