My question is for QR Code support on the ZOS platform. We have legacy systems that produce many printed documents and mailings. I have been tasked with the challenge of developing a called routine that can receive a 200 byte string of variable data and return the encoded data for a QR Code. I’ve walk through a series of mathematical calculation required to encode the data in the algorithm for printing with a barcode font.
I wondered if someone has already tackled this task on the mainframe.
I am looking for short cuts on the mathematical encoding portion in COBOL. I have seen several applications out there that were designed for other platforms and other languages. Has anyone experimented with creating QR Codes on the Mainframe or know of any dynamic processes that can handle the calculation portion of the encoding?
Related
We are using R/exams to create tests in Canvas and TestVision.
We have other forms and other software to perform written exams.
I know R/exams has a great NOPS feature and was wondering:
What software is used to autograde the NOPS forms?
Can that software also evaluate string questions?
Now it looks that the NOPS form doesn't make it easy for software to read parts. Ideally the software would be adapted so adapted NOPS forms (changes in blue) could read more easily Student Name, and string questions:
NOPS format
The NOPS forms have not been designed by us but they follow the format that our university has been using. We simply mimicked their format because we initially just generated the PDF files ourselves but used the commercial scanning software of our university.
Scanning
However, over the years we have written our own scanner implementation in R in exams::nops_scan(). The basic approach is to convert PDF pages to PNG images, read these into R, convert them to black and white pixel matrices, find the scanner markings in the corners, and then extract just the boxes relative to these markings. The boxes either contain printed digits in a fixed font for which a simple decision tree yields a reliable classification - or the boxes are empty/filled vs. checked which can also be classified reasonably reliably. The result is stored in a simple text format that was again not developed by us but to be fully compatible with the commercial system that our university used.
Grading
Based on the scan results the function exams::nops_eval() computes points and grades. Various evaluation strategies can be plugged in and starting from version 2.4-0 the reports generated by the function can be customized.
Extension to OCR
At the moment no OCR (optical character recognition) is used, except for the simple task of recognizing printed numbers in a fixed font. But no hand-written characters or digits are ever evaluated automatically. I had played around with this a little bit using tesseract but the results were not reliable enough for our purposes.
The string questions that are currently supported are intended for open-ended questions. Hence students get a reasonable amount of space to write something down. The teacher can then grade the answer sheet manually, again by ticking boxes only, which can be read rather reliably. The scanned images of the full sheet are included in the report for the students so that they can also see any hand-written feedback/corrections included in the answer form.
Tutorial
A hands-on guide to using the NOPS approach is available at: http://www.R-exams.org/tutorials/exams2nops/
Misc
Unfortunately, the system is not implemented in a very modular fashion. The reasons for this were two-fold: (1) We followed very closely the given format our university had been using. (2) The bulk of the implementation was written under a lot of time pressure (see the anecdote below). So while the features you propose would be nice to have, they are unlikely to fit well into the current setup. If you would want to have a stab at this, I would recommend to write a modular new implementation, just using the bits and pieces from the existing code that are useful enough.
Anecdote: Scanning of about 400-500 exam sheets had failed on the university system due to a mistake of the copy shop that had printed the sheets. It was mid-July, everybody was on vacation already including myself. So I sat on my parents porch for two days to write the scanner tool and evaluate the exams that the students were waiting for.
There are some great libraries out there for deserializing binary formats. I really like the declarative approach by kaitai and nom's approach which is using Rust.
However, I am not aware of any good approaches to serialize binary formats.
For example, you often have the case that you have to write your message length right into the message header, but actually you do not know your exact message length at this point because it depends on many fields which are downstream from the header. And you sometimes also have to deal with padding alignment which can be cumbersome.
Do you know any solutions for problems like these?
Please take a look at ASN.1 which has solved this problem many years ago, and is still continuing to be widely used in critical infrastructure in many different industries. It is independent of programming language and machine architecture so you can set up communication whether one peer is using C on a little-endian machine and the other is using Java or C# on a big-endian machine. Structure padding issues are easily handed by good quality tools for ASN.1. A good list of tools (both free and commercial) is available at the ASN.1 Tools page of the ITU-T ASN.1 Project.
I will be getting two different types of real time data continuously through serial ports. I have to process the data in real time and display it on screen in real time. I want to write a program, so that I can process the data and display it on the screen with good interface. Also, I will be getting one more set of data through NI USB 6343.
Which programming language is good, so that I can display all three sets of data in a single screen?
The .NET languages have a SerialPort class that is fairly easy to use. So, if you're on a Windows machine I would consider picking either Visual Basic or C#. They are both as easy to use as one another when it comes to serial-ports, you will just have to decide what language you like better. Coming from the C world (as I've read in your comment) you will probably be more comfortable with the syntax of C#.
Check out this MSDN example of how to receive data over a serial-port in C#.
I am trying to develop an application that will use tickets given the user the ability to validate them. I am wondering why I should choose Aztec barcode as many many companies have already chosen that instead of QR-Codes. What are the pros of the Aztec barcodes?
I good comparison I have found so far is:
http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx
and here: http://en.wikipedia.org/wiki/Aztec_Code
on Usage section you can see that is used quite often.
Although Aztec Codes are more compact and tunable, there is poor support for them among open, non-proprietary software. I would still use QR Codes for now, which have very mature software support on a wide variety of platforms.
If space is at a premium for you, and you do not care for users to be able to read or generate your codes with their own software or on a wide variety of devices, then Aztec would be a better choice. Aztec codes do not require a surrounding margin, allow for very finely tunable error correction level, and have a tighter encoding optimized for a wider range of message texts.
For example, the Aztec codec has a mode specialized for encoding lowercase letters, so it could encode most of this question answer with only 5 bits per character. The QR codec is only optimized for uppercase URLs, and must store lowercase letters as full 8-bit binary data. A QR code containing this text would have to encode about 160% as much data as an Aztec code -- and then it needs a margin space too.
QR codes require more space than Aztec codes but have freely available software supporting them.
Aztec codes can store more information, but there is poor free support for them. They can be harder to read and generate efficiently, right now.
On an Android phone, Google's "Barcode Scanner" application will scan an Aztec code after a longer delay than a QR code, and the user has to manually enable Aztec code scanning in the application preferences.
Similarly the free barcode generator package "zint" will produce Aztec codes, but has a handful of bugs, and does not make full use of the codec to optimize their size as small as possible. Its generation of QR codes, on the other hand, is bulletproof.
I share the frustration with the comparative incompleteness of FLOSS support for encoding and decoding Aztec Code, expressed in #fuzzyTew's answer.
There is much more open-source code for encoding and decoding QR, compared to Aztec, and it is more feature-complete and thoroughly tested.
That's a shame, because Aztec Code is in several ways superior to QR. As described in #fuzzyTew's answer…
Aztec doesn't require a “quiet zone” of white space around the symbol, while QR does.
Aztec offers continuously-tunable error correction levels, whereas QR code offers only a few discrete levels.
Aztec offers substantially higher density than QR, for typical applications consisting mostly-to-entirely of standard ASCII text.
Compared to Aztec, QR is particularly inefficient for encoding lowercase Latin letters (8 bits/char) compared to Aztec (5 bits/char).
The largest QR size, 177×177 blocks, can store 2953 bytes in binary mode with Low error correction (~7%), while the largest Aztec size, 151×151 blocks, can store 2318 bytes in binary mode with equivalent 7% error correction. At that size, Aztec requires ~9.83 blocks/byte, while QR requires ~10.61.
Much of the open-source support for Aztec is based on ZXing. That includes the Android Barcode Scanner app, and many online encoders and decoders.
Until recently, ZXing's Aztec Code implementation did not correctly support the encoding or decoding of non-Latin1 characters. (QR, Aztec, PDF417, and Data Matrix all use ECI to support other character encodings.)
Recently I've started doing something about it:
I added support for correctly decoding non-Latin1 characters from Aztec in ZXing.
I added support for correctly encoding non-Latin1 character sets to Aztec in ZXing.
I also added support for encoding non-Latin1 character sets in the Python aztec_code_generator module.
The point of all this is: There's not actually a ton of work to be done to get open-source Aztec encoders/detectors/decoders of a high quality.
I'm looking for an thorough explanation of how data is encoded into qr codes. The explanation should be specific enough that one could encode a qr code manually (as by drawing)
The complete specificion is available from ISO, as ISO/IEC 18004:2006. It is not free. You can find some partial information on the internet, but not enough to create an encoding process. If you really need the detail, buy the spec.
I can tell you that the process is far too complex to carry out by hand -- the Reed-Solomon error correction calculation alone would take days and you'd not get it right :)
zxing has a complete QR code encoder implementation which may show you enough of how the process is carried out for your purpose.