A unified "Barcode" tag for HTML 5, Math-ML or SVG




Abstract

A barcode tag is needed for HTML, either in the form of an introduced HTML 5 tag -- or otherwise via an introduced tag in SVG or Math-ML. The standard XML or SGML syntax rules for tag creation should be followed, with minor adjustments.

No current markup language has any formal support for barcodes, in spite of the low complexity in encoding and displaying them.

As barcodes do involve math, Math-ML would be the best candidate for adopting the tag. However, as graphic display is involved SVG would also be the best candidate. Therefore this proposal is for a joint SVG + Math-ML adoption of this tag.

Any barcode markup and display standard that becomes deployed on web browsers and HTML word processors should be revised every 2 or 3 years.



Where the technology is today

The current "state of the art" is to have all of the barcode generation done at the webserver at the website. This is not fair to website owners, as each time bar codes are required for some industrial purpose, a back end (Java, PHP, ...) library must be acquired and implemented.

Barcodes can be difficult and expensive for websites to adopt, when the browsers that visit the website have access to all the computational machinery they need to generate barcodes rich in data in under 100ms of CPU time.

To cope with the vast number of bar codes that have been formally adopted as standards, a mechanism is needed that will accommodate most possibilities of barcode encoding. This sounds simple, but barcodes are extremely variable and this is no easy task.

It is assumed that any implementation of this machinery at the web browser level must be done with a codebase that is in the public domain and open source. Complexity reduction is vital, but it may take up to 5 years to perfect the technology.



Ancillary problems

Barcodes are as a rule rectangular, and as a rule must be displayed as images. Math Markup Language can get by without graphic representation due to the special nature of math markup programs -- but this logic does not apply to barcodes.

It is assumed that the web browser should allow the user to specify some minimal parameters for barcode generation. This could be fit in with settings that apply to SVG or Math Markup Language where needed. Subpixel rendering, and anti-aliasing should not be allowed.



Syntax
  • "[-]" in the above syntax designates mode and encoding information, it would not show up in the normal syntax.
  • CODE here specifies the actual contents of the barcode. For barcodes that permit coding of ancillary data, this data should not be placed here -- but should be in the encoding information area.
  • Bar codes have the following properties, but not universally : Checkdigit, Checksum, Error Correction Mode, Error Correction Type, Ancillary Content.
  • The barcode syntax, should as general principal -- not encode any more than 2 kb of data or text.
  • The barcode syntax should work only with standard low complexity barcodes -- so no coding or barcodes that are in colour or proprietary.
  • To cope with different screen or printer conditions, it may be permitted to add "polarity=-1" to reverse the barcode's default black on white display mode. Using the polarity tag must mean that any other colour tag must be ignored.
  • It may be permitted to display the barcodes in other screen colours other than black or white. The standard xml or html oriented 24 bit colour semantics that apply to text display must be reused here with no alteration. At this point in time there is no formal support for the practice, but if it is adopted it must be the same syntax as text colour coding.





The following table is not complete, but must act as a guide to syntax formalization.So within the "[-]"
  • within mode="{}"
  • within ecc="{{}}"
  • within ecm="*" (syntax varies with barcode type)
  • within addon="+"


Coding notes
  • Designator should not exceed 8 characters, these characters being capitalized alpha or numbers with no spaces.
  • Error Correction Type, if fixed for a barcode should not be generated in the valid syntax for that barcode.
  • Error Correction Mode should work in terms of percents. This syntax is only permitted for use in 2D matrix barcodes.
  • For Aztec, Datamatrix, ... and similar 2D matrix bar codes but no other codes : the dimension must be specified after the 2 letter alpha designator for this class of barcodes. If the user wants automatic generation based on the size of the data "##" must proceed the 2 letter designation like this : DM##, AZ## ... etc.
  • Polar based bar codes should have P as the initial letter in their type designator for clarity.

Barcode Name
Type
Designator
Error Correction Type
Error Correction Mode
Ancillary Content
Example







Zero-compressed UPC-E
Linear
UPCE


None.
mode="UPCE"
Universal Product Code
Linear
EAN12
Fixed checkdigit.
No ecc mode. None. mode="EAN12"
International Article Number Linear
EAN13
Fixed checkdigit.
No ecc mode. None.
mode="EAN13"
Codabar
Linear
CODA
No checkdigit.
No ecc mode.
None.

Modified Plessey
Linear
MPC
4 ECC types
mod 10, 11, 1010, ...
None
mode="MPC"







Postal barcodes






CPC Binary Barcode
Linear
CPC
None.
None.
None.
mode="CPC"
Intelligent Mail barcode
Linear
IMB
None.
None.
None.
mode="IMB"







2D Matrix barcodes






Datamatrix
2D
DM##
Variable.
Reed-Solomon. Varies (102 - 1442).
mode="DM10"
Aztec Code
2D
AZ##
Variable.
Reed-Solomon.
Varies (152 - 1512).
mode="AZ15"
QR Code
2D
QR##
Variable, 4 modes.
Reed-Solomon. Varies.
mode="QR##"







Polar coordinate barcodes






MaxiCode
Polar
PMC
Reed-Solomon. Modeless.
6 Fixed record types.
mode="PMC"







Other






High Capacity Color Barcode
2D-mod
HCCB
Reed-Solomon. Modeless.
Record type varies.
 mode="HCCB"







Contents of CODE <barcode [-]>CODE</barcode>)





Rules for coding must be precise and unambiguous


Linear barcodes
  • For simple fixed length "digit only" or "mixed alpha numeric" bar codes simple ASCII-7 (capitalized Alpha only) text must be enforced. This rule should apply to Linear bar codes of less than 36 characters in length.
  • No spaces should be permitted in "short" Linear barcodes.


2D Matrix or 2D Stacked barcodes
  • No spaces should be permitted. 
  • Human readability should not be permitted, these are not Linear barcodes. The WYSIWYG editor should provide a user interface to specify the content of the barcode.
  • Coding should be in Base 32. Base 64 may be widely used on the web, but not here.
  • Coding should always be in binary, coded to Base 32.
  • The ECC mode or ancillary content information should tell the barcode display system what is being coded.





Coping with website or user coding errors

It is inevitable that a website barcode syntax generation system will make mistakes. Is is also possible for users, and word processor authors to make mistakes in the coding of the necessary syntax to enable this barcode syntax to work. So a simple and unambiguous graphic should be used to indicate an error has been made.

The graphic should adapt in form to the barcode being generated. This is up to the system implementers to figure out how to do this.

The blank space should be filled with
  1. "S Y N" unknown syntax error. 
  2. "E C C" for Error Correction Code or Error Correction Mode errors.
  3. "T Y P" type error (generally Upper or Lower case incursions), this could cover a lot of token syntax errors too.
  4. "L L L" CODE content too long or short for barcode type.
  5. "D A T" Data to be encoded is the wrong data type for the barcode specified.
  6. "Z Z Z"  Rending system failure, all else fine.

x
x
x
x
x
x
?
?
?
x
x
?
?
?
x
x
?
?
?
x
x
x
x
x
x







References Barcodes Error Correction Encoding




Created by
Initial idea
Created
Last update

Version
Revision state


Max Power
14 May 2009
05 August 2010
22 May 2014 (spelling)
0.95b
Final