• 100% direct PostScript. Platform, OS and language independent.

  • A set of PostScript “named resources” that allow you to insert a barcode in the page markup as simply as:

0 0 moveto (Hello world) (version=4) /qrcode /uk.co.terryburton.bwipp findresource exec
  • Executed wholly in a PostScript printer, pre-processor/RIP (GhostScript, Distiller, Jaws, Harlequin), document management system (CUPS) or printer filter driver.

  • Your application need only emit ASCII text. No need to link to any libraries, perform pre-processing, etc. Ideal for use with both modern and legacy reporting languages.

  • Support for ~100 barcode symbologies.

  • Free software. MIT/X Licence: Permissive, non-copyleft.

  • Not a “turn-key solution” but a developer resource akin to a library. Your developers integrate it rather than run it directly.

  • Cleanroom development of all code. No IP issues.

BWIPP was not the first implementation of a pure PostScript barcode...

"The barcode ... has been programmed entirely in PostScript, thus the features are absolutely accurate to the resolution of the output device. The code is broken into 16 "digits", each of which begins with a thick bar; the digit's value is determined by the distance to the next thick bar and the number/placement of thin bars encountered within this span. An 8-bar "comb" pattern has been appended to the edges of the main barcode to provide good resolution reaching beyond the edges of the basic code ... It was originally printed across a full page using a Linotronic 200 printer with 1200 DPI resolution, and photographically reduced by a factor of 7 (down to 24 x 24 mm) onto a conventional 7-mil high-contrast negative, which was back-illuminated using LED's and a condenser lens."

Paradiso, J. (1994) "Testing and Development of Extended Range Straightness Monitor Systems,"

GEM [Muon Detector] Collaboration Report (SSCL), GEM-TN-93-331.

Original PS: https://github.com/bwipp/postscriptbarcode/tree/master/contrib/history/gem-muon-detector

Background

 

  • Began June 2004 by Terry Burton who continues as the principal developer.

  • Was a small bit of code (to scratch an itch) to include Code 39 symbols in LaTeX-based invoices, logistics notes, etc.

  • In June 2004 placed 150 lines of code on personal website in case useful to others, but expected it to be vapourware.

  • By end of 2004 had 100s of users on the mailing list and support for ~10 symbologies.

  • Numerous valuable contributions over time however supporters tend to come and go  solve their problem then move on. Difficult to build an active community around such a specialised project.

  • Large direct and indirect user community: Growing, despite PostScript use otherwise waning.

  • Several integrators: Regular new use cases, e.g. cross-compile to JavaScript. Motivated to tackle the PS language barrier due to the extensive features, maturity and stability of the code base.

  • Tiny developer community: Succession is an unsolved problem.

  • Actively developed and supported since its inception but has always been maintained as a “spare time” project in the hope that it will be useful to the AIDC community. Very many late nights!

Commit Punchcard

BWIPP Symbology Evolution

  • June 2004: Initial release with support for Code 39.

  • Mid-late 2004: Satisfied community requests for EAN-13, EAN-8, UPC-A, UPC-E, ISBN, 2 of 5, ITF, Code 128 (UCC/EAN-128), Codabar, USPS POSTNET 4-state.

  • 2005: “ISBN-13”, EAN-2/5 (add ons), Code 93, Code 11, MSI, Plessey (UK), Royal Mail 4-state (RM4SCC), USPS FIM, AusPost, Royal TNT Post (KIX).

  • 2006: USPS OneCode (Intelligent Mail), Reduced Space Symbology (GS1 DataBar) family, Pharmacode.

  • 2007: MaxiCode.

  • 2008: Sponsored 2D barcodes: PDF417, Data Matrix, Aztec Code, QR Code (including Micro QR Code).

  • 2009: Code cleanup, fixes, optimisations, ...

  • 2010: Telepen, Two-track Pharmacode, BC412, PosiCode, Channel Code.

  • Late 2010: “Helpers” and “application standards”: ISSN, ISMN, Code 32 (Italian Pharma), PZN, Code 39/93 Extended. GS1 symbols (GS1-128,  ITF-14, GS1-14, SSCC-18), HIBC symbols, Deutsche Post Leitcode/Identcode.

  • 2011: MicroPDF417, GS1 Composite symbols. Some mostly historic value symbols: Code One (Ted William’s first 2D code), Code 49, Code 16K, Codablock F.

  • Mid 2014: Optimised high-level encoding to ensure minimal symbol size for given input.

  • 3 July 2014: Dedicated following the sad passing of Craig Harmon (co-founder of JTC 1/SC 31) whose son Matthew has been a longstanding supporter of this project.

  • Late 2014: Convenience encoders: Micro QR Code, Telepen Numeric, 2 of 5 (Industrial, IATA, Matrix, Matrix, COOP, Datalogic), Compact PDF417, Aztec Runes.

  • 2016: Data Matrix Rectangular Extension (DMRE). Han Xin.

  • Roadmap: DotCode, UltraCode, Dotted Data Matrix. Who's interested in these?

What is the PostScript Language?

  • Much more than a page description language.

  • Turing complete programming language focussed on vector-based printed output.

  • Stack-based, akin to Forth. Program is streamed to and “consumed” by the printer. Instructions modify the graphics state and are discarded after execution.



What is the PostScript Language?

Very rich language (over 400 operators) with usual plethora of features:
 

  • Stack manipulation: dup, pop, exch, index, roll, copy, mark, cleartomark

  • Maths: add, sub, mul, div, idiv, mod, abs, neg, sin, exp, ln, floor, srand, rand

  • Boolean: true, false, eq, ne, gt, lt, ge, le, not, and, or, xor

  • strings: string, ( … ), < ... >, length, getinterval, putinterval, search, token

  • arrays: array, [ … ], astore, aload, length, getinterval, putinterval, copy, forall

  • dictionaries (hashes): dict, << … >>, known, where, get, put, begin, end, def, currentdict

  • Control: if, loop, for, forall, repeat, exit

  • Exception handling: stop, stopped

  • Drawing: newpath, currentpoint, moveto, lineto, curveto, closepath, stroke, fill, image

  • Fonts: findfont, scalefont, setfont, show, stringwidth

  • Graphical state: gsave, grestore, translate, scale, rotate, transform, dtransform

  • File IO: file, closefile, readstring, writestring, flush, %stdout, %stderr, run

  • Named resources (libraries): defineresource, findresource

PostScript language features useful for barcoding

  • “Exiting the job server loop” provides ability for state (procedures, structures, etc) to gain persistence across jobs, e.g. have a “print job” that places barcode generation routines into the VM so that they are available for all subsequent jobs (until power cycle).

  • “Named Resources” provide ability for procedures to be packaged and stored on printer/document-manager’s disk (and cached by printer) to gain persistence across power cycles. Enhance base capabilities of the printer using only software, i.e. “No barcode font chips required™”

  • “Forms” feature can cache expensive-to-RIP graphical components enabling lightweight Variable Data Printing (VDP). Render any intensive imagery then execute PostScript procedures over variable data (e.g. GTINs) supplied continuously at the tail of the datastream to create differing content with which to finalise the output (e.g. overlay barcodes onto a complex background). RIP once at fixed cost and print many variants essentially for free without the need for overlay printing.

A Nested PostScript Forms Example

Each fern logo is a single form (F) consisting of an expensive to compute (~750 ms) fractal.

Each rectangular label is a form (L) that includes the fern logo F and accompanying text.

Each page outline is a form (P) consisting of a watermark instance of F and a grid of L.

Complete pages are created by plotting form P and overlaying the variable data barcodes.

Printing takes <1 sec for first page then 30 ms. Would be >10 secs without a form cache.

PostScript imaging features useful for barcoding

  • Provides true vector output all the way to the RIP. Absolutely accurate to the native resolution of the output device. Directly draw lines and modules of a barcode symbol as paths not pixels.

  • PostScript can probe the “device space” (output device properties such as pitch, orientation) so that you can perform “grid fitting”, i.e. alignment of user space lines/modules to device space pixels to avoid grazing and ensure integer-multiple mapping for bars of differing widths.

  • For future colour barcodes we can directly specify colours in RGB, CMYK, HSB colour spaces and perform separations such as in the use of spot colour processes.

 

Alternatively…

  • You can avoid PostScript’s imaging system and just perform the symbol bitmap generation using BWIPP then an application can import the data structure directly for custom rendering.

Barcode Imaging Issues

Anti-aliasing:

  • Great for text
  • Horrendous for barcodes as these require hard edges.

Barcode Imaging Issues

 

"Graphics software used to create bar codes on pixel-based printers must scale each bar and space exactly to the pixel pitch of the printer being used. For edge to similar edge decodable symbologies like Code 128 the number of pixels comprising each symbol character must be a fixed and constant integer multiple of the number of modules in the symbol character.

 

General purpose printing software designed to support a wide range of printers should provide the user the capability of adjusting the X dimension and bar width growth or loss."

ISO/IEC 15417 (Code 128) and other specifications

Grid-fitting: Required not just for bars, also spaces.

Barcode Imaging Issues

 

"Graphics software used to create bar codes on pixel-based printers must scale each bar and space exactly to the pixel pitch of the printer being used. For edge to similar edge decodable symbologies like Code 128 the number of pixels comprising each symbol character must be a fixed and constant integer multiple of the number of modules in the symbol character.

 

General purpose printing software designed to support a wide range of printers should provide the user the capability of adjusting the X dimension and bar width growth or loss."

ISO/IEC 15417 (Code 128) and other specifications

Lo-res, grid-fitted. Scans perfectly.

Hi-res.

Lo-res, not grid-fitted. Not scannable due to pixel-grazing!

Zoomed images:

BWIPP Imaging Evolution

  • Linear renderer (1D barcodes: EAN-13, Code 39, ...)

    • stroke operator with setlinewidth.

  • Matrix renderer (2D barcodes: Data Matrix, QR Code, Han Xin, …)

    • 2004: image operator. Thwarted by anti-aliasing in viewers that treated it as a bitmap, i.e. fuzzy output when magnified on-screen.

    • 2008: imagemask “stencil” operator. A vector clipping mask. Initially better, but some applications became cleverer (i.e. worse!) over time, e.g. Preview application on Mac.

    • 2014: Filled, adjacent square paths. Problem solved but resulting image is composed of many individual image components.

    • 2016: Optimal number of filled polygon paths. Support for ink bleed compensation for matrix barcodes.

Ⓑ 2016

(30 polygons)

Ⓐ 2014

(226 squares)

Actual appearance

Project Hosting

  • 2004: Initially hosted code on personal website.

  • 2006: Moved hosting to Google Code.

  • 2013: Migrated to GitHub foreseeing the closure of Google Code.

    • Good news - more eyes on the commit diffs improves code review!

    • Bad news - GitHub recently stopped showing diffs of non-generated PS files (treats them as binary). Fewer eyes on… https://github.com/github/linguist/issues/2962. Please nudge this issue!

Release Tooling

  • Continuous Integration for all commits using Travis CI. (“Does it build and pass tests?”)

  • Automated Release (“Continuous Delivery”) using travis-github-release script. https://github.com/terryburton/travis-github-release. This uploads tarballs to GitHub Releases when a tag is pushed to GitHub.

  • Automated distribution packaging (deb, RPM, Arch) using OpenSuSE Build Service. http://goo.gl/422q5B

Documentation

  • Primary source is the GitHub wiki (Markdown format). Commit access available on request.

  • Automated conversion of Markdown to PDF via LaTeX using Pandoc to create documentation suitable for print. http://goo.gl/b4eidU

Development Priorities

The author is in full-time employment and his days are busy doing non-barcoding things...

… but what about evenings and weekends?

  1. Critical bug fixes

  2. Features being sponsored *

  3. Integrating contributed code

  4. What the author finds interesting or fun

  5. Wish list items that people are shouting about

  6. Anything else (may never get done!)

* For core code the sponsor agrees to assign copyright to the author and all development will be released in the main corpus of code under the project’s current license.

User Support

  • Best efforts, community-based support. Code-centric.

  • Mailing list. Issue tracker.

  • On-going commercial support is not currently available.

  • If anyone would like to partner with the author to provide a business-centric commercial support service then feel free to get in touch. Demonstrated PostScript and barcoding proficiency is required.

Third-Party Frontends and Uses

Easy to use third-party “frontends” are available which package BWIPP as an application, plugin or more conventional development library.

 

  • LaTeX - pst-barcode module for PSTricks. Direct use within a TeX document.

  • BWIP-JS - Barcode Writer in Pure JavaScript. A cross-compilation of the PostScript into JavaScript and executed within a browser or hosted via a Node.js server.

  • Integration libraries for Python, Perl and Ruby languages.

  • SAP ABAP and Smart Forms driver.

  • Scribus barcode generator plugin. Directly generate barcodes within the DTP application.

  • Commercial Adobe InDesign plugins, e.g. Soft Horizons Chartbot, others under NDA.

  • Embedded within several models of high-end laser printers (more NDAs).

  • Is a test target for xpost2, a minimal PostScript interpreter.

Many other uses, both open source and commercial.

How to Help

  • Use it for fun and/or profit.

  • Tell people about it.

  • Understand the code.

    • Enjoy learning the PostScript language.

    • Deep dive into barcode encoding. Most reviewers agree that the implementations are the best that they've seen.

  • Fixes and other code contributions are most welcome, including improved documentation.

  • Develop against it. Test against it. Steal bits of the encoder implementations - just report any bugs that you find!

  • Sponsor a feature (see open issues: https://github.com/bwipp/postscriptbarcode/issues)

    • A useful symbology (Dotted Data Matrix, Ultracode...) Specifications and resource kits often cost in excess of £500 and may take several weeks of (spare time) development.

    • Imaging improvements (Upcoming renderer revamp: Grid fitting, evaluation of per-specification constraints.)

    • Anything else that you need.

Demos

Demo 1: Interactive session (like Turtle teaching language)

  • Stack exercises: pstack, pop, exch, 2 copy, index, roll, mark

  • Path construction: moveto, rlineto, curveto, newpath, closepath

  • Path impression: stroke, fill

  • Control: loops, ifelse

 

 

 

 

Demo materials available here: http://goo.gl/dth54z

Demo 2: Example of progressive drawing (fractal fern)

  • Programmatic construction of complex objects.

  • CTM, Matrix transformation

  • Blinken lights. Because we can!

 

 

 

 

 

 

Demo materials available here: http://goo.gl/dth54z

Demo 3: Simplified Code 39 code walkthrough

  • Invocation

  • Encoder named resource

  • Linear renderer named resource

 

 

 

 

 

 

Demo materials available here: http://goo.gl/dth54z

Demo 4: Use case - Variable Data Printing with barcodes

  • Inlining of “packaged” flavour of BWIPP.

  • Forms for efficiency (huge benefit from caching):

  • Supplying data continuously at the end of the stream. Unspecified length, data-driven run.

 

Demo materials available here: http://goo.gl/dth54z

ISBN 0-911261-12-5 (1997)

Comprehensive history.

Extensive symbology reference.

Biographies of key players.

ISBN 0-911261-07-9 (1994)

Symbologies and applications.

Technology considerations.

Deployment case studies.

Online Discussion and Learning Materials: