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 depolyed 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 its simplest form, the syntax should be : <barcode [-]>CODE</barcode>
  • "[-]" 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"

Once all barcode mode information has been supplied (and many 2D or Linear barcodes that have fixed checkdigit systems will not need to supply any more than mode information, the barcode contents must be provided.




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

Once all of the barcode properties have been coded, the barcode itself must be specified.

This sounds simple, but it is not. Barcodes can contain as little as 6 to 12 digits, or as much as 8 kb of text or binary data.





Rules for coding must be precise and unambigous

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"  Renderer failure, all else fine.

x
 x
 x
 x
 x
x
 ?
 ?
 ?
 x
x


x
x
 ?
 ?
 ?
 x
x
 x
 x
 x
 x







References

Markup languages
 Barcodes
 Error Correction
 Encoding


Created by : Max Power // Created : 5 August 2010 // Last update : 13 August 2010