Sample EAN-13 barcodes (at least)... aren't? about postscriptbarcode HOT 11 CLOSED

I've added a task list to your original comment and it will be addressed over time.

Thanks, I made a small correction — the example space is 952, not 925. 😁

from postscriptbarcode.

https://www.gs1.org/standards/gs1-style-guide/current-standard#2-Applicable-to-all-GS1-documentation+2-18-GS1-prefix-952-for-examples

from postscriptbarcode.

I wonder if it would be a good idea, and probably worth the effort, to replace the various 9 771473 968012 examples in the code/documentation with a code starting with 952 instead, just so that it's clearly and definitionally a "sample" code not actually valid for trade?

Now that we have well-estabilished example ranges for GS1 data, this makes sense.

Presumably, some (even most?) other barcode standards also block out some form of explicitly-invalid/sample codes within their code space.

If only...

So I also wonder (but have not looked into) whether postscriptbarcode's examples in those other formats fall within those reserved ranges, as well.

For the special-purpose ranges that are delegated to other agencies we have generally had to resort to using example numbers provided in published specifications because the official response has been that no such example ranges exist. For example, in the case of ISBNs there wasn't even a public database of prefix assignments to national agencies until recently.

GS1 themselves are more transparent with assignment, including providing sample ranges. However, it has been hard to care too much to convert things over whilst the examples in the General Specifications typically ignore the example ranges.

(If nothing else, hopefully some POS and inventory systems will have implemented enough of the GS1 standard that they'll reject any 952-prefix barcodes outright. Which might prevent more items using fake barcodes from entering the retail stream.)

I think this is the salient point as this provides an opportunity for cleanup of the supply chain at the point of entry, i.e. during initial processing of GS1 AI based data. The bar has been pretty low regarding data validiation, however efforts such as this are starting to improve things: https://www.linkedin.com/pulse/gs1-application-identifier-syntax-dictionary-terry-burton/

There are of course other number systems (e.g. HIBC) that we provide very basic support for, and then others (e.g. MH10.8,2) where users must perform their own encoding using the generic symbologies. Patches or relevant information welcome for those.

from postscriptbarcode.

I've added a task list to your original comment and it will be addressed over time.

from postscriptbarcode.

I've also addressed the sample.ps file with the following: 912bcba

from postscriptbarcode.

Great initiative, thank you !
HIBC reserves the LIC "A999" for test purposes. It is registed in the LIC data base as "HIBCC DEMO ACCOUNT".
Take care,
Harald

from postscriptbarcode.

Thanks @oehhar.

from postscriptbarcode.

the examples in the General Specifications typically ignore the example ranges.

You noticed that too, huh? I admit I found it completely bizarre.

from postscriptbarcode.

• upcacomposite
• upca
• upcecomposite
• upce

Not sure if those four are going to work — isn't a UPC code just an EAN-13 that starts with 0, with the leading 0 removed? There may be an example space for UPC, but I'm guessing it's not 952.

from postscriptbarcode.

Ooh, and right under, for UPC:

2.18.1 UPC prefix based example

When a UPC based example is required, GS1 US have made available the following, suppressible, GTIN-12: 012345000058

from postscriptbarcode.

Done.

from postscriptbarcode.