Unlike many of my “journey” post series, I actually have to complete most of this. It’s not experimenting for the sake of experimenting. It’s a need which keeps coming around every year. Those of you who have read “The Minimum You Need to Know About Qt and Databases” ISBN-13: 978-0-9823580-5-4 have an inkling about this. Please allow a thumbnail sketch for those less well read.
Whenever I’m experimenting with/trying to learn some new tools there are two applications I write with them. The first is my now famous/infamous “Lottery Tracker” application and the second is some new version of Xpns-It (currently xpnsqt on SourceForge). Both applications cover general business requirements.
- Some kind of menu
- Data entry
- Data modification
- Data backup
- Printed columnar reports
That’s the core of business applications. From invoices to statements to quarterly reports, it all boils down to the ability to create decimal aligned reports on paper. Every requirement exists to support that end goal. As long as there are legal requirements to have things on paper the need for this type of system cannot go away. Be careful when signing up for “electronic statements.” Yes, it saves business millions as well as trees, but when there is a dispute or an IRS audit you are going to need physical paper. Saving them to disk and printing them out when needed is fine as long as you are backing your disk up. The day your drive fails, be it a spinning disk or solid state, will be the day before you need those statements.
The xpns-it application is where I enter and categorize business expenses. It generates a report much like you see here. This is called a control break report. Detail lines are sorted and grouped by category providing totals. I take the print out to my tax preparer and they plug the numbers into various tax forms. When I first started doing this they used a pen and paper forms. Today they use tax preparation software and file electronically for me. Most of you reading this probably can’t remember a time when the IRS required paper tax forms, but they did. When you have professionals prepare your taxes, all they want is a listing like this. They don’t want the output from some personal tax software which tries to fill out the forms for you.
My first cut at this program came long ago when I was teaching myself C. It was under DOS with a hokey little menu and it only generated the text file. I had to look at the text file in an editor then print it out. A later DOS version used Greenleaf DataWindows for the user interface and Greenleaf Database Library to store the data in XBASE files. I was learning both of these tools and using them in the real world so it made sense. It also made for a nicer application with a built in browser.
Back then I used tabs instead of spaces because “it was more efficient.” This was a lie those of us working in the PC world told ourselves. I was working in both worlds so I knew the lie. Tabs were only more efficient on terminals which had firmware to handle hard tab stops and those affordable dot matrix printers we had at home. The industry started referring to all of these as “line printers” but only the big printers in data centers were “line printers.” While it is true these dot matrix printers like the Star Micronics NX 2420 Rainbow in the image printed a line as the print head crawled along its track, the band and drum printers printed a line in just a few of hammer strikes.
No matter what printing technology you used, the default “font” was 10 CPI (characters per inch). It’s height was such that you could get 66 lines per page if the page was aligned perfectly. This was true for every business computer system. When you created a report file on IBM, DEC, Burroughs, PRIME, etc. it was always to those specifications. Narrow (8.5 inches) gave you only 80 characters per line because you couldn’t print edge to edge. Wide (about 14 inches) gave you 132 characters of printable space per line. Both gave you 66 lines because they allowed you to print at the very top edge and bottom edge of the sheet.
This was and still is the standard for business printing. Early postscript printers included their own version of a2ps (ASCII to Postscript) which would accept a standard report text file and render it on the printer using a built in 10 CPI font.
When working with preprinted forms like your year end W-2 or a paycheck we lived and died by our forms ruler. Higher end printers offered both the standard 6 lines per inch and a smaller 8 lines per inch. Even today, you have to be really good with your forms ruler when writing software which will print on a preprinted form. The 8 lines per inch setting was never used for financial reports. This was generally only used for a detail data dump type of report because it was just too hard on the eyes. See that blue lined rise in the middle of the forms ruler? That’s a magnification prism. I think the original reason for its existence was the 8 line per inch setting.
One of the myths continually being pushed onto the business world is that business and financial reports should “look fancy.” They should be all graphics and “cool” fonts like blogs and Web sites. No, they shouldn’t! Reports for business need to be highly readable and cleanly laid out. They exist to communicate information others need to do their job. Sometimes that’s your internal employees, other times it is bankers/big investors, and lastly it is Joe and Jane public researching stocks for their retirement account.
Here’s a good rule of thumb.
The fancier the financial report the higher the odds it is a scam. If there is stuff written in fonts you can’t read without your glasses, don’t buy it.
During the early years of IT, you could print in any color you wanted as long as it was black. You could have any color you wanted on your screen as long as it was green, amber, or gray because they only had the one color they came with. Hopefully you can see the tiny numbers running down the left side of the image of green bar paper. You could physically print 66 lines but you were supposed to only print a maximum of 57. Most shops have a PAGE_SIZE constant of either 50 or 55. You never wanted to print the last detail line on one page then the control total on the next. Most report programs used a detail line page break check like this:
if ((line_count + 7) > PAGE_SIZE
Some shops would use five, others seven. You generally had to have a minimum of two just to print the category total and another three for the next category heading.
The consistency of 10 CPI and 66 lines allowed COBOL to flourish.
It didn’t matter if your computer used ASCII which needed a Form Feed character or EBCIDIC using some “printer control channel” (I forget how it worked.) In COBOL you simply issued a WRITE command choosing either BEFORE or AFTER ADVANCING PAGE. How the page break happened you didn’t care about.
We physically defined every space on the line. Sometimes we even used good variable names. COBOL will outlive Java. It will outlive any of today’s trendy scripting languages because business will always need this and business is the money. It doesn’t matter what trendy Internet company you wish to name. They still have to file financial reports the SEC will accept and they still have to print pay stubs in a form the IRS allows.
Death and Taxes.
Remember that.
