Closed graphicore closed 3 years ago
graphicore
commented
3 years ago Alright, I think this is it.
I'm now calculating all checksums!
I am even calculating checksum of UPC-E short input, by expanding it to the UPC-A form first! Initially, I thought that calculation was not possible in GSUB, but then I realized that the short form can be expanded into UPC-A without knowing the checksum. And calculating the UPC-A checksum was already implemented. -> nice!
davelab6
commented
3 years ago For the case where EAN-13 BB = 12 input digits and UPC-A AA = 12 input digits, I suggest the 12 digits without a "marker" character prepended or appended is EAN-13, and then to get UPC-A you type 123456789012upca or upca123456789012.
graphicore
commented
3 years ago Adding a marker to get the longer AA forms would be backwards compatible to the current behaviour, but it's not implemented.
u is unused, but p, c and aare already used for the "compatible" and "fallback" encodings, that's not necessarily a problem, but I'd prefer to avoid this kind of double use, also, one marker char should suffice.
A marker for BB could look like: 001234567890x or 001234567890? which may be more intuitive and also may integrate nicer into the current implementation.
I'm not convinced that the font needs both input methods, especially when one is a compromise. Currently, because we calculate it, If you need to enter a wrong checksum, maybe going via the fallback encoding is good enough?
The main question is IMHO if input will rather come with checksum attached or not.
Note, the current version of the table above looks more like this:
# Column AA: with explicit check sum
# Column BB: calculating the checksum (last digit) on the fly
# reduces input length by 1.
#
# COMBINATIONS AA BB
# -------------------- --------
# EAN-13 + addOn-5 18 17
# UPC-A + addOn-5 17 16
# (X + UPC-E + addOn-5 17 16)
# EAN-13 + addOn-2 15 14
# UPC-A + addOn-2 14 13
# (X + UPC-E + addOn-2 14 13)
# EAN-13 13 12
# UPC-A 12 11
# (X + UPC-E 12 11)
# (x + UPC-E + addOn-5 12 11)
# (x + UPC-E + addOn-2 9 8)
# EAN-8 8 7
# (x + UPC-E 7 6)
Many changes. This version is feature complete (despite maybe see below)!
@davelab6 After having mastered how to calculate the 5 digit add-on checksum, I think I can also calculate the checksums for the main barcodes. The only problem I see could be limits in how much OpenType can take. It would be a pity running into something like that after putting time into it. However, so far this stuff works really well.
The reason I did not implement this yet is that it would conflict with the current input method, so we can't have both methods co-existing with plain digits as input. Here's a table of what is implemented:
(from
app/lib/builder/ean13.js)A collision of input methods would be e.g.:
EAN-13 BB = 12 input digitsandUPC-A AA = 12 input digitsFor UPC-E I'm already using markers "X/x" to mark the following digits as UPC-E, something like that would be possible.
We should decide how to do it now, because going back would be bad for existing usages, a break of contract.
Also in this PR: the WIP beginning of two tools for manual, chars not GSUB based, encoding:
compatible: use this font like https://grandzebu.net/informatique/codbar-en/ean13.htm this can only create a limited sub-set of the possible barcodes/layouts but is fully compatible with the grandzebu font.fallback: a superset ofcompatiblebut implemented using harfbuzz shaping to get the unicodes of the resulting glyphs. This is can access all glyphs in the font and create the same barcodes without GSUB features.