Differences From BWIPP
For the vast majority of uses, bwipjs and BWIPP behave identically. For example, if you supply the same values in the bwipjs demo and the BWIPP online bar code generator, you will get the same image.
The primary differences are with fonts and background color.
bwipjs uses embedded versions of the OCR-A and OCR-B fonts. Barcodes and the OCR fonts are like chocolate and hazelnut; they were meant to go together. Unfortunately, most PostScript environments do not provide the OCR fonts and must fallback to Courier, Helvetica, and other less-than-ideal typefaces.
The following two images show the differences in typeface. The image below was rendered by bwipjs:
And the next image was rendered using BWIPP with Ghostscript:
The font functionality is implemented with the following logic:
- OCR-B is used as the default font for all barcodes.
- OCR-A is used for the extra text on the ISBN, ISMN and ISSN symbols.
These defaults can be overridden using BWIPP options.
The fonts are known to the PostScript emulation as OCR-A and OCR-B.
For example, to switch the font to OCR-A, you would specify the option:
textfont=OCR-A
For the text above the barcode on the ISBN, ISMN, and ISSN symbols, the font
can be changed using isbntextfont, ismntextfont, and issntextfont,
respectively.
The code in demo.html shows how to load your own fonts into bwipjs. See
Preloading Fonts Into FreeType
and Loading Fonts During Runtime
for descriptions of the two techniques.
The online barcode generator pre-loads the Inconsolata font, which can be seen using the option:
textfont=Inconsolata
For example, we can render an alternate version of the ISBN barcodes shown above with the Inconsolata font using the BWIPP options:
includetext guardwhitespace textfont=Inconsolata isbntextfont=Inconsolata isbntextsize=11
A second difference between BWIPP and bwipjs rendering occurs with the
backgroundcolor option. The BWIPP implementation of background color is a bit
inconsistent. For some bar code types, the background color extends into the
human readable text, and for others, it does not. bwipjs
does not implement BWIPP's background color handling (it is commented out in the PostScript rendering logic).
Instead, the front-end interfaces explicitly override the option and extend
the background color to cover the entire image, including all human readable text.
The first/left image in each pair is from BWIPP using ghostscript, the second from bwipjs.
By default, if the backgroundcolor option is not specified, bwipjs renders the
image with a transparent background.
There is a minor incompatibility between the parse and parsefnc options. When specifying both options,
you must protect carets used to prefix the parsefnc sequences from the parse option. For example,
your bar code requires both parse parsefnc as options and the text contains:
^FNC1^027BV01^027
The leading caret of the ^FNC1 sequence will be mis-processed by the parse option and cause a runtime
error. The BWIPP-compatible solution is to replace the caret in the ^FNC1 sequence with the parse compatible
sequence:
^094FNC1^027BV01^027
94 is the ASCII value for caret. bwipjs avoids this issue by processing the parse option prior to BWIPP
code execution, and uses the JavaScript RegExp /\^\d\d\d/ to only convert entities that are meant to be converted.
The conversion will also throw an error if the value represented by the three digits is greater than 255.
One additional benefit from this approach is the parse logic in the BWIPP code (which appears multiple times) is
removed prior to cross-compiling, reducing code size.
The three BWIPP renderers renlinear, renmatrix and renmaximatrix have been replaced by versions customized
for bwipjs. Specifically, all three previously used postscript eval semantics to convert a color string in either
rrggbb or ccmmyykk format to its binary form. Supporting this option required specialized code to be
added to bwipjs. By replacing the evals (and the setanycolor function bodies) with an internal setcolor
operator, a considerable amount of code was eliminated (with a minor improvement in performance as well).
As mentioned above, the backgroundcolor option was also eliminated from the three renderers, reducing code size
by a small margin.
The renmatrix renderer is based on an older version of BWIPP. The older version used the postscript imagemask
operator to render the 2D patterns. This was fine for bwipjs as the implementation simply scaled each pixel in
the mask proportionally.
Other users of BWIPP had problems with imagemask as their postscript environments would use an image scaling
algorithm that produced "fuzzy" images. The latter version in BWIPP draws each "dot" in the 2D bar codes as
distinct graphics paths followed by a fill, which caused a major performance hit in bwipjs.
The most significant change by far is in the renmaximatrix code. This renderer is completely custom to bwipjs.
The original renderer drew hexagons and circles to render the maxicode symbol. This required a significant amount
of supporting code that was only used by this one renderer. And to be perfectly honest, the code did a lousy job
drawing those hexagons and circles. To draw them with high precision would require an amount of code totally out
of proportion to need.
But since bwipjs has the freetype library already integrated and it is capable of high resolution rendering, it was a simple matter to augment one of the embedded OCR fonts (OCR-B specifically) with two extra glyphs, one that renders a hexagon, and another that renders the "bulls eye" finder pattern.