VectQR.com is actually a compilation of different modules that when combined do amazing things. We are currently using Google App Engine to host our content and JQuery Mobile to enhance the experience.
At the heart of every qr code is bits and bytes, and for our system we needed a robust data storage solution that could work on a very granular level. For this we developed BitBuilder, which is like Java’s StringBuilder, but designed to handle bits instead. Typically we think and develop on the byte level, just imaging that any character on your keyboard can be represented as a single byte in most cases. But QR codes require working on the bit level. Because of byte limitations we developed a way to add bits and bytes to the BitBuilder and have it properly maintain data integrity. For example adding a bit and then a byte, results in 9 bits, but this the data is actually stored in 2 bytes. In these 2 bytes we only need to keep track of 9 bits. With BitBuilder we can grab and alter bytes, or individual bits without needing to get into complex algorithms.
Having bits is fine, but they need to mean something. We built our system with the many different available data types in mind, which include Numeric, Alphanumeric and Binary. Kanji has not been implemented at this time. With these basic types we are able to piece together codes that are smaller than typical. For example if only encoding numbers, then we can save space by using numeric instead of binary encoding. Currently our system internally can handle multiple data types, but the page available at VectQR.com is only sending binary data requests at this time. We have the system to convert requests to smaller chunks implemented at the client level, but the service is unable to interpret them.
After data has been processed, and converted into a single bit stream we need to position it on the grid which forms the base of the output. We took some extra time and made the grid smarter, so each cell knows its purpose and gives a little extra context during encoding. With extra knowledge we are able to run a simple path finding algorithm to efficiently place data, and have it react to changing conditions, such as running into protected space and how to proceed next.
We decoupled the export process from our main system to increase flexibility and offer more choices over time. Each exporter is built for a specific task, such as exporting excel data and can produce data within certain specifications. We implemented a few neat features for testing that have been released to the public, such as structure and data only exports, which alter the generated codes, by either removing or adding information. For example structure exports color cells differently to define their purpose, while data only removes the mask and exposes raw data, which is usefull for developers. Currently we are not offering an advanced image exporter, but plan to roll one out in some time.
- Excel 2003
We are currently hosting VectQR.com on Google App Engine, and use jQuery Mobile to format our webpages for desktop and mobile users.