search

graphicore / librebarcode

Libre Barcode: barcode fonts for various barcode standards.
https://graphicore.github.io/librebarcode
SIL Open Font License 1.1
425 stars 25 forks source link

Add code ean13 #27

Closed graphicore closed 3 years ago

graphicore commented 3 years ago

Open for discussion.

graphicore commented 3 years ago

Attaching current state of the font. LibreBarcodeEAN13Text-Regular.zip

preview of EAN-13 and EAN-8 versions when you enter 13 or 8 numbers.

If you choose to enter random numbers, remember in both cases the last number is a checksum that should not be random, but calculated. UPC-A is basically EAN-13 when it starts with a 0, but the formatting (text below etc) is done a bit differently.

I used this for comparison (and to calculate the checksums): https://barcode.tec-it.com/en/EAN13 Though, calculating the checksum is not particularly hard.

It scans for me from screen using different scanner.

CC: @davelab6

davelab6 commented 3 years ago

Any one watching this repo care to take a look? Any feedback would be great!

thlinard commented 3 years ago

Minor comment: Maybe the glyph naming pattern could follow the AGL recommendation https://github.com/adobe-type-tools/agl-specification: eight.below rather than below.eight.

thlinard commented 3 years ago

Tested in:

graphicore commented 3 years ago

@thlinard would you test other versions, e.g. one that uses ccmp instead of calt in those apps?

thlinard commented 3 years ago

They work fine, but I compared to the codes generated by the Inkscape module, and I feel the codes are truncated.

If you have any examples to test, I can send you screenshots.

graphicore commented 3 years ago

@thlinard

Minor comment: Maybe the glyph naming pattern could follow the AGL recommendation https://github.com/adobe-type-tools/agl-specification: eight.below rather than below.eight.

My names are roughly structured from more generic to more specific. e.g. I now have a guard.normal.endTriggerAddOn where there are many guards one pattern called normal and then a special version of that endTriggerAddOn that is inserted when the barcode is allowed to be followed by an add-on bar code.

It looks to me like your suggestion would structure from more specific to more generic: endTriggerAddOn.normal.guard , more like a domain name is structured subdomain.domain.tld.

I think both are legitimate, in my head, personally, it feels like my approach helps me reading/thinking about the feature code structure. However, I could probably also adopt to the other style.

I just wonder what following the AGL recommendation does good for me and/or the project, as changing names and my thinking would require some effort and I see no immediate added value in it. Maybe some technical reason?

graphicore commented 3 years ago

Maybe some technical reason?

from https://github.com/adobe-type-tools/agl-specification:

The mapping is meant to convert a sequence of glyph names to plain text while preserving the underlying semantics. For example, the glyph name for ‘A’, the glyph name for ‘small capital A’, and the glyph name for a swash variant of ‘A’ will all be mapped to the same UV (Unicode Value). This is useful in copying text in some environments, and is also useful for doing text searches that will match all glyph names in the original string that correspond to ‘A’.

So, is this the old "copy from PDF" reason and will this allow to copy the numbers of a barcode from a PDF, despite of having many guard glyphs inter-weaved?

thlinard commented 3 years ago

So, is this the old "copy from PDF" reason and will this allow to copy the numbers of a barcode from a PDF, despite of having many guard glyphs inter-weaved?

Yes, in a PostScript file, and in a PDF file without ToUnicode mapping (https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/5411.ToUnicode.pdf), only the glyph names are preserved, without any Unicode mapping.

The AGL specification allows to reconstruct the Unicode mapping from the name of the glyphs. A PDF reader, like Adobe Acrobat, parses the glyph names and ignores anything after the first period in a name, and decomposes ligatures if an underscore is present. For example, this allows an "Th" swash ligature (glyph name: T_h.swsh) to be parsed as T U+0054 LATIN CAPITAL LETTER T and h U+0068 LATIN SMALL LETTER H. Of course, the shape of the glyph is lost (but this is fine with Unicode logic).

In the case of a barcode, this would allow to retrieve the digits entered.

davelab6 commented 3 years ago

It's unclear that the agl text extraction is still relevant in 2020. Adobe Type people said, forget about it

thlinard commented 3 years ago

It's unclear that the agl text extraction is still relevant in 2020. Adobe Type people said, forget about it

Well, no. For example, in InDesign, you create a PDF file by direct export. In this case, a ToUnicode mapping is created in the PDF file.

But an export in PostScript, later distilled in PDF, is still a legitimate workflow, so, unless the folks at Adobe Type are unfamiliar with the working environments fonts are used in, I'd like to know where they could say AGL text parsing was irrelevant today.

Edit: Oh, I see. The reference about AGL irrelevancy is about AGL vs. AGLFN (https://github.com/adobe-type-tools/agl-aglfn), not about the very principle of parsing glyph names.

Of course, AGLFN is the standard to follow, but it's irrelevant in the present case.

davelab6 commented 3 years ago

I believe it was @tphinney who said that workflow is now so obscure it isn't worth catering to :)

@graphicore please merge, tag a release, and PR to the GF central repo ASAP :)

thlinard commented 3 years ago

I believe it was @tphinney who said that workflow is now so obscure it isn't worth catering to :)

In the wishes of some people, no doubt, but not in the real world.

But, regarding AGL vs. AGLFN, no doubt that it's AGLFN which is to follow (but which says the same thing concerning the parsing of the names of glyphs).

tphinney commented 3 years ago

But an export in PostScript, later distilled in PDF

Note that this only ends up using glyph names instead of the cmap if BOTH these things are true:

That said, using AGLFN-style glyph names except reversing the glyph and the extension portions of the name seems … pretty wack for long-term use and maintenance. Everybody knows, and most people follow, the reverse standard—even most who allow the main portion of the name to diverge from AGLFN.

thlinard commented 3 years ago

That said, using AGLFN-style glyph names except reversing the glyph and the extension portions of the name seems … pretty wack for long-term use and maintenance. Everybody knows, and most people follow, the reverse standard—even most who allow the main portion of the name to diverge from AGLFN.

Yes, we agree. This is also what seemed wrong to me, even if the cases where it can become a problem aren't that many (it seemed to me that there are situations where a Type 42 can end up without cmap ... or my memory playing tricks on me?).

tphinney commented 3 years ago

That said, using AGLFN-style glyph names except reversing the glyph and the extension portions of the name seems … pretty wack for long-term use and maintenance. Everybody knows, and most people follow, the reverse standard—even most who allow the main portion of the name to diverge from AGLFN.

Yes, we agree. This is also what seemed wrong to me, even if the cases where it can become a problem aren't that many (it seemed to me that there are situations where a Type 42 can end up without cmap ... or my memory playing tricks on me?).

AFAIK the latter. Although, I could of course be wrong, too—as this is based on my memory of old lore from 20+ years ago. At one time it was important I know this area well, but it has been quite a while. ¯_(ツ)_/¯

graphicore commented 3 years ago

Ok, thanks for the discussion. I will make the glyph names comply better with common practice.

For now, I'm going to merge this PR and make an early release, because font needs to become available in the sandbox quickly.