Progsbase was used to create a barcode component that at launch is available in 12 different programming languages. The barcode component is without dependencies except for the language constructs included in the progsbase system (which are in all 12 languages). This means that using the barcode component in a program in any of the languages simply means dropping a source code file into the source tree and compiling. No additional libraries are required.
The component includes everything it needs to produce a barcode image both in a double array of colors in RGBA or as a PNG.
Barcodes are widely used in many industries: They are using it in retail where each product has a barcode, it is used in shipping to track a parcel as it travels to its destination. It is used in warehousing where it tracks the inventory, it is used in packing, where a program tracks the contents of the pack as it is filled with its contents. These are just a few of the applications.
A barcode is an image. The image contains a sequence of black and white bars of the same width, called modules. Each module is read as a B or W. For example, two white bars and a black bar is read as WWB. These sequences encode characters or digits. The encoded information is sometimes written below the barcode in human readable text as a backup solution.
Thus, the creation of a barcode is a function that takes a sequence of characters as input and gives an image as output.
Little is required of a programming language to be able to do such a computation. It is clear that all modern languages are more than capable. Creating a barcode in any programming language should be as simple as calling a function with the barcode contents as input and getting the image of the barcode as output.
The signature of the function for generating a Code 128 barcode is as follows:
public static RGBABitmapImage GenerateBarcodeCode128(char  chars, double height)
The inputs are the array of character (to encode in the barcode) and the height of the resulting barcode, in pixels. The output is a simple structure containing rows and columns of pixel colors. The signatures of the functions for creating other barcodes are similar.
To get a PNG image, simply call one more function. It is also included in the component:
public static double  ConvertToPNG(RGBABitmapImage image)
This functions converts the RGBABitmapImage structure (with the array of colors) to a PNG image. The binary content of a PNG image is represented in progsbase as an array of numbers from 0 to 255. This array can simply be converted to an array of bytes and written to a file.
The barcode component supports eight different barcode symbologies at launch: EAN-13, EAN-8, UPC-A and UPC-E, commonly used in retail; and Code 128, Code 39, Standard/Industrial 2 of 5 and Interleaved 2 of 5, which are more general purpose barcodes.
Here is an EAN-13 barcode generated with the component. It is 37.29mm wide with a DPI of 600.
Inside the component are a number of computations.
The first category of computations compute the barcode codes. For some symbologies, such as Standard 2 of 5 or Code 39, this is a straight forward mapping. In others, such as Code 128, more complex algorithms are needed to compute which codes to use and which codes makes the most compact barcode.
The second category of computations are checksum computations. Most barcodes use checksums to increase the probability of a reading of the barcode being correct.
The third category of computations are the mapping to bar-sequences. These are mostly mappings.
The forth category of computations are graphics drawing and scaling. This includes bilinear interpolation and alpha blending.
The fifth category of computations are algorithms used in making a PNG. These include CRC-32 and Adler-32, used for error-checking, and DEFLATE, a compression algorithm.
As can be seen, there a many and varied computations in the component, but they are still only computations and compose to more and more complex computations, which generating a barcode image is.
The C version has 2730 lines of code taking up 66 kB. The code is very similar in size of the other programming languages.
If we compile the C version of the barcode component into an object file, strip it of debug-symbols, the whole component fits into 24 kB. The gzipped C code is a 10 kB download.
This code has no dependencies in any of the languages. It only requires a compiler for that language to build.
This is very small; the component only includes the code for doing its job and nothing else.
When a component correctly implements its computations and just includes the computations in the basic language constructs, such as the barcode component discussed here, it will keep working for a long time. As such, its an end-all-be-all barcode component for generating those eight supported symbologies. If you need to generate a barcode in one of the symbologies, then this component can do it.
As the programming language constructs used are the core building block of most languages, something they will continue to be for a very long time, the code will keep working for a very long time.
The worst case scenario is that in several decades from now, no one use the languages currently supported by progsbase - which is very unlikely. In that case, a new writer is needed to write the progsbase programs into the new programming languages. When such a writer has been made, which can be estimated to a few person days of work, then all progsbase components will work in this new language.
Thus, the longevity of the barcode component is very long and it will keep working exactly the same way it does today for a very long time.
A quick search online quickly reveals tens of barcode implementations. It is very likely the number of implementations reach the hundreds, if not thousands.
It should be quite clear that had effort been focused into making one barcode component with progsbase, then a single component would be scrutinized and tested thoroughly instead of hundreds being first developed separately and then scrutinized and tested separately.
Had the same component been used many places, in many different programming languages, so many would use the component and work with the single component that most bugs would soon be found and fixed. The component would achieve high quality and instead of having a development team rewrite something for the, e.g., 385th time, simply reuse a tried and tested component that has stood the test of time and which is also implemented with the constructs that are also tried and tested and has also stood the test of time.
It is easy to know the progsbase programming language completely. When developing a component with a language you understand completely, you can focus on solving the problem. You can know that what you implement is correct with respect to the programming language.
An experienced Java developer might know 80% of the programming language, an expert might know 95%, while a Java guru knows 98%. If you find these numbers too low, check out a few Java puzzlers online, and you will quickly see there is a lot of detail and surprises. Numbers for modern C++ is likely significantly lower (checkout e.g. this blog post by a C++ guru).
An expert or a guru will likely use their brilliant understanding of the language by creating some terse piece of code elegantly solving some sub-problem. Although this might save the expert a little time, it creates costs down the road when the not-so-expert developer comes to read, edit or fix some bug in it.
When a problem is solved in a language such as progsbase (which is a core part of the 12 languages supported), it is possible to understand each line of code even by someone directly out of programming school. This greatly increases the longevity of the component and lessens the cost of maintenance.
Adding a dependency to a project means including code and assets others have written. If this dependency is a 100 MB download of compiled machine code and data, it is difficult to rule out importing malicious code. At least it would be easy for someone to get their malicious code into a project this way.
For the Barcode component dicussed here, there are many barriers that make it much more difficult to include malicious code. First of all, the progsbase language only allows computational code and data manipulation code. Thus, if the code passes the progsbase analysis, it is most likely only computations and data manipulation.
Further, the code is open source and almost minimal. A developer or someone in quality assurance can read the code from start to finish. For the barcode component discussed in this article, it would not take long to certify that it does not include any security compromising code.
In summary, this article covers the industrial case of creating a timeless, lightweight component for generating barcodes.
The result is about 2700 lines of code in a language completely understandable by any developer.
It can be widely reused, at launch in 12 of the most common programming languages.
It will last a long time, as it has no dependencies except the most tried and tested parts of the most used programming languages.
It is easy to review the code to verify that the code is not a security threat.
It is very easy to use in any project in any of the supported programming languages: Simply add the source code to the project and compile. No further requireents.
This makes the component timeless and lightweight.
We would be more than happy to help you. Our opening hours are 9–15 (CET).
📞 (+47) 93 68 22 77
Nils Bays vei 50, 0876 Oslo, Norway