05-04-2016 04:14 AM
Simply put, no. The output is a picture of the rendered output. You could theoretically look at each pixel of the image, but I wouldn't recommend it. Get the original data.
05-04-2016 01:30 PM
Thank you for your reply.
Everytime we do theortically.
My intention is to do even that with a double programming.
As per your answer. The entire Graph what we see in RTF is a Image printed in it right?
So we wont be able to read any info from that. Is my understanding is correct.
Thanks & Regards,
Praveen Kumar J
05-04-2016 01:42 PM
It is possible to capture the data used to produce the graph (including the calculations) by using the ODS OUTPUT statement. Would that help you?
05-05-2016 04:20 AM
Correct. As others have mentioned below, you have three real options:
- Create your graphs using vector graphics, these are graphics with formula which are then rendered by the program. This however requires the validator to know how to program those formula which is not easy.
- Create graphs as normal, and use PDF compare or a simliar compare program - this however is really not great as tiny differences or page breaks can completely change it. So 80% fail rate on that.
- Third and final option, and the preferred one - at least in my field. Create a dataset store - you should be doing this for any validated output, i.e. Tables, Listings. In that store, put the final dataset before (or from) the output procedure. That dataset can then be validated by double programming. For the output file, well many differing views on that from manual review, to attempting to read in the RTF, to storing titles and footnotes separetly for validation etc.
The above of course is all symptomatic of trying to proce a process at the end of it. My industry appears to be starting to move away from this approach to an up front definition, metadata driven. Thus all the metadata is defined up front and the code generated from that. What this would mean is that the end result needs less validation, i.e. if two people supply the same metadata to a validated graph generator, then you can be pretty sure the output will be the same. More of a, this is what we want, define and document the whole thing, then generate from there and validate against that.
05-04-2016 02:18 PM
That was really helpful.
At the same I think my thoughts are working beyond imagination.
Now for an ex example we havent used ods output statement in PROC LOESS. Finally we will have only RTF or PDF files were GRAPH as its final output printed in it.
So is there a possiblity to read the data points from RTF's or PDF's Graph.
The criteria here is I have only final output RTF or PDF file with Graph output (I donot have any dataset from PROC LOESS or PROC PLOT procedures to perform compare). Now I need to programmatically QC it.
05-04-2016 03:45 PM
At best, you could get the drawing coordinates from any vector-based output (extracting these values from a PDF document or an EMF document (RTF) would have its own challenges). Even if you get those points, you would need to transform them to get them back the original data points, which would require you to know the oringinal data ranges and physical ranges of all axes (for numeric data). For discrete data, you would have to get the position of all discrete values on the axis and map all corresponding numeric axis points (transformed) to that discrete value. Group values would probably have to be retrieved from corresponding legends, and the visual attributes of the legend "chicklet" would have to be matched to the visual propoerties of each polygon/polyline so that you would know to add the group values to the data observations. This would be quite an interesting task :-)