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
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.
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.
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 🙂
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.