copyright 2007
by Ĝan Ŭesli Starling
I find it annoying to receive a report which has all of its useful conclusions sequestered into separate files in disparate formats such that one must juggle several windows in order to extract said report's essential content. I would very much prefer to view said info presented concisely and neatly within but a single on-screen window. Ideally I'd like to see: description first, conclusion second, supporting arguments and data nested hierarchically beneath those two. And if there be links strewn all about therein, so that I might hop back and forth at will, so much the better.
On such occasions as when I have presented my own documentation that way, requestors have recieved them gladly. In those cases I will have compiled the whole report into true electronic format, which is to say XML, not PDF. There will be an index.xml page and a directory report_files containing all the support documents, graphics, etc. If the report need be sent off site, then I just zip it up and attach to an e-mail with a note to unzip it anywhere and open the index.xml in any browser.
Why not PDF? Well... The way most people use PDF is to digitize paper docs for electronic storage. Personally, I hate receiving those as they are never truly convenient to peruse electonically. Viewing them on-screen at page width interrupts the vertical scroll with every page break. Annoying, that. Viewing them at page height wastes screen space and makes the font tiny. Hard to read, even more annoying yet. In this electronic age the whole idea of pages is antiquated, utterly non-sequitur. At home I don't even own a printer. Thus my preference for an endless vertical scroll. I write XML docs in just this fashion with countless embeded browsing links all self-generating care of the magic of XSLT. Ref: XML
Toward that end I seek to largely abandon any presentation format which is not viewable in any browser on any platform. This is a little script to help meet that goal by automating one of my editing steps. For simple data it permits one to forgoe any recourse to spreadsheets. Performing spreadsheet-like functions embeded within plain ASCII CSV input files it gives similarly plain ASCII CSV output importable into text editors, XML/HTML documents (like this one) and the like.
Suppose, for example, you have an existing spreadsheet form, one out on a factory floor someplace into which operators type results...or scribble results onto a printed version thereof. And suppose that your document looks someting like this...
# These are pseudo flow data from a hypothetical spray nozzle. # Data are deliberately contrived so as to fail certain of the test # conditions as an exercise of a parsing/munging script written in Perl. PSIG (UOS), 30 (dpm), 50 (dpm), 60, 80, 100, 120, 130, 170, 320, 400, 560, 170 Hyst 3% Limits Tight, >50, >70, <3, 4.5~7.5, record only, record only, record only, 154~165, 431~466, record only, 745~780, 97%~103% (170) Limits Slack, record, >80, <2, 4.0~8.0, record, ignore, skip, 150~169, 421~476, record only, 730~795, 95%~105% (170) Data So-so, 45, 50, 3.2, 7.1, 15.3, 16.8, 22.6, 159.6, 469.2, 586.2, 771.4, 159 Data Worse, 55, 75, 1.7, 7.7, 61.6, 64.9, 71.4, 184, 465.5, 573.3, 760.6, 184
Not exactly like that, but that general kind of layout where...
And say you want the each data set applied to each acceptance criteria. And say also that, for whatever reasons, you don't care to use an actual spreadsheet, but would prefer plain ASCII. That is the purpose of this script. The above data will give an output which looks like this...
Report generated by Perl script: 'J:/gus_perl/gus_calc_generic_pl/gus_calc_generic.pl' version 0.05 Input data read from: 'Psuedo_PPH_Flow_Record_0.csv' # These are pseudo flow data from the metering set of a spray nozzle PSIG (UOS), 30 (dpm), 50 (dpm), 60, 80, 100, 120, 130, 170, 320, 400, 560, 170 Hyst 3%, Combined Limits Tight, ? < 50, ? < 70, ? > 3, 4.5 < ? < 7.5, 'record only', 'record only', 'record only', 154 < ? < 165, 431 < ? < 466, 'record only', 745 < ? < 780, 97% < ? < 103%, Results Data So-so, 45, 50, 3.2, 7.1, 15.3, 16.8, 22.6, 159.6, (*) 469.2, 586.2, 771.4, 159, 1 FAILURE! Data Worse, (*) 55, (*) 75, (*)1.7, (*) 7.7, 61.6, 64.9, 71.4, (*) 184, 465.5, 573.3, 760.6, 184, 5 FAILURES! Limits Slack, 'record', ? < 80, ? > 2, 4.0 < ? < 8.0, 'record', 'ignore', 'skip', 150 < ? < 169, 421 < ? < 476, 'record only', 730 < ? < 795, 95% < ? < 105%, Results Data So-so, 45, 50, 3.2, 7.1, 15.3, 16.8, 22.6, 159.6, 469.2, 586.2, 771.4, 159, PASS Data Worse, 55, 75, (*)1.7, 7.7, 61.6, 64.9, 71.4, (*) 184, 465.5, 573.3, 760.6, 184, 2 FAILURES!
Below is precisely same table as above but rotated 90 degrees and re-grouped into sets by test range.
PSIG (UOS) Limits Tight, Data So-so, Data Worse
30 (dpm) ? < 50, 45, (*) 55
50 (dpm) ? < 70, 50, (*) 75
60 ? > 3, 3.2, (*) 1.7
80 4.5 < ? < 7.5, 7.1, (*) 7.7
100 'record only', 15.3, 61.6
120 'record only', 16.8, 64.9
130 'record only', 22.6, 71.4
170 154 < ? < 165, 159.6, (*) 184
320 431 < ? < 466, (*) 469.2, 465.5
400 'record only', 586.2, 573.3
560 745 < ? < 780, 771.4, 760.6
170 Hyst 3% 97% < ? < 103%, 159, 184
Combined Results, 1 FAILURE!, 5 FAILURES!
PSIG (UOS) Limits Slack, Data So-so, Data Worse,
30 (dpm) 'record', 45, 55,
50 (dpm) ? < 80, 50, 75,
60 ? > 2, 3.2, (*) 1.7,
80 4.0 < ? < 8.0, 7.1, 7.7,
100 'record', 15.3, 61.6,
120 'ignore', 16.8, 64.9,
130 'skip', 22.6, 71.4,
170 150 < ? < 169, 159.6, (*) 184,
320 421 < ? < 476, 469.2, 465.5,
400 'record only', 586.2, 573.3,
560 730 < ? < 795, 771.4, 760.6,
170 Hyst 3% 95% < ? < 105%, 159, 184,
Combined Results, PASS, 2 FAILURES!,
Note how it provides the results oriented two ways. First is the same orientation as given by the source file. Secondly it gives a 90-degree matrix rotation of that same table. Depending on how you prefer to present your results, choose either...or both.
Also note, when you open the actual ASCII output file, that the tables included there are even more redundant yet. The above two kinds of tables are presented each in formats, plain ASCII and HTML-ified. The latter format is identical to the former except for two distinctions:
<, > and &.>span< nodes having style attributes.This page being XML, I perforce must display only the escaped renditions.
My script gus_calc_generic.pl will process pure ASCII input tables and formulae very like spreadsheet, but with output to pure ASCII *.csv format. Although this script has no built-in GUI, a separate GUI is also provided in its own pair of download links.
Remember to edit the extension from *.txt to *.pl after downloading a Perl script. Likewise from *.txt to *.CSV after downloading a Tektroni CSV file. The *.txt extension is necessary to insure that the web server will present these files to you as plain ASCII when you click their download buttons.
Here are links relating to the command-line version of this script.
Script:
POD as HTML
Perl as TXT
Here is the separate GUI, written in Perl/Tk which will interface to (call and run on command) the above GUI-less Perl script. This is my new methodology for dealing with simple scripts, rather than build in a custom GUI for each.
Script:
POD as HTML
Perl as TXT
To test the above script (with or without its GUI) you will need at least one example test-criteria/test-data file. Here is a pair of such for you to play with.
Inputs:
CSV as TXT
CSV as TXT
This script has a Perl module dependency not yet on CPAN. Download it from here.
Module:
XML
Tk::EasyGUI