Date: Wed, 9 Apr 2003 08:04:19 -0400
Reply-To: Magnus Mengelbier <magnus.mengelbier@FERRING.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Magnus Mengelbier <magnus.mengelbier@FERRING.COM>
Subject: Re: Highly formatted PDF report output?
There are several roads to travel ... if you are looking to "highly
formatted" PDFs. I have been involved in a few projects during my IT-boom-
days where CR was used or was a potential solution.
We ended up using XML/XSL variations all times. For an example on the
control you can have... search for FO, ie Formatting Objects, PDF and for
an application called XT. What FO essentially does is let you have point
control of the positioning and formatting. We did a few applications that
produced dynamic reports for digital print quality - but it was hardcore
programming then. The systems still work as a charm I am told and the
programming is a whole lot easier today.
There are also a few variations today ... you can use SAS to do all logic
and simple output generation, automatically build a report document (for
example using an MS Word component), and then use a PDF printing
utility ...
what i am getting to is ... I believe you are chasing an expensive
consultant dream project if you want one application to do everything. I
will be corrected, but I believe you can cut any project by two-thirds by
just breaking it into smaller pieces.
My 5-cent solution would be something like...
- SAS to generate report components, ie tables and figures
- Master XML document with the titles, subtitles, "big texts", and
references to where and how to include report components.
- FO-style sheet
- push the components and document through a XML/XSL transformation (very
simplified for bervity) and I think you will find a report on the other end.
I do not think there is an easy way at the moment since you want a very
tightly controlled layout.
Good luck
Magnus
On Wed, 9 Apr 2003 01:42:15 +0100, SAS User
<sasuser@GUILDENSTERN.DYNDNS.ORG> wrote:
>Current processing here uses Crystal Reports to produce hundreds to
>thousands of output reports, which must then be split with a third party
>utility into sets of n reports, for some arbitrary n.
>
>SAS ODS has been raised and dropped as an option due to the formatting
>requirements of the reports. These are distributed to clients who have
>specific expectations as to presentation, and it is apparently too
>difficult to attain these results with SAS directly. While I'm inclined
>to believe this may be the case, I'd like to revisit this option as it
>would solve several current processing issues. Alternatively, markup
>systems such as LaTeX may be suitable. Other XML + stylesheet
>combinations are still too much a rat's nest to consider.
>
>
>The problem with the CR + additional slop solution is that it cannot be
>scripted -- neither utility allows pointing a report at a data source
>with an output file specification (or alternate vexations involving
>Visual Basic, OLE, or related proprietary nuisances) to produce output
>on demand. The result is a production process involving multiple manual
>interventions and inputs where none should be required.
>
>SAS would be the programmatic solution but produces inferior quality
>output (in our experience).
>
>
>
>With that preamble out of the way: does there exist a templating tool
>for SAS such that high-quality, highly-formatted PDF documents can be
>produced in a programmatic manner?
>
>
>
>While I'm on the soapbox, SI itself could do itself several strong
>favors (as usual). I'm not inclined to tell them this for my own
>benefit, so I'll pretend it's for mine. However my heart of hearts
>calls me a liar. From its long vacation from me at points far
>distant...
>
> - Put the goddamned SAS documentation online, without requiring
> registration, and allow third-party sites to host it. They will
> anyway. And you'll save yourself tech-support calls. I've taken to
> not answering 'L questions which require online docs research on my
> part, even if I do find a samizdat copy somewhere, and despite
> having done the research. If the Institute wants to shoot itself in
> the foot, it's proven itself quite adept over the years, and I see
> no need to endanger myself by entering the line of fire.
>
> - SUGI submission guidelines need revisiting for an age in which they
> rarely if ever reach paper.
>
> - Papers should be allowed to extend past the six and ten pages
> currently given. This is barely sufficient to introduce many
> topics (of course, there are many SUGI topics which barely need
> introduction...). A 15-20 page limit (note that's a limit, not
> a requirement, pipe down there in the back) would be a vast
> improvement.
> - The two-column format needs to be nixed -- it hinders online
> reading. I note that it most frequently is ignored by SI's own
> staff. The offenders are applauded. I'd strongly recommend a
> general boycott of this anachronism in future.
> - Code samples should be presented in natural, fixed-pitch,
> readable format. That means 80 columns courier or SAS Monospace
> (a remarkably readable font), folks. Note that 80 columns don't
> fit with the current two-column layout. Extensive code
> supplements should be available to authors as well, as
> appendices to the paper proper, when appropriate.
> - Full-page illustrations demonstrating graphics or online feature
> (application design, web interface, page layout) should be
> available when appropriate. Trying to discern features in a
> 2"x3" (108mm x 162mm to the civilized world) halftone at 600 dpi
> (before inkjet spread) is ridiculous. Of course, abusers of
> this option will be pilloried.
> - The online SUGI archives should be restructured to be readily
> usable offline. Browser plugins stink, they bastardize two
> application interfaces, and reduce usable screen real estate.
> Allow the document to be opened and browsed in a freestanding
> reader. These are contributed documents which increase the
> value of SAS, they should be made available as conveniently as
> possible.
> - Strong consideration should be made for nixing PDF altogether
> and presenting the Proceedings in standards-compliant HTML (I'll
> recommend against XHTML as the format is still too green to have
> settled comfortably and given rise to a robust, widely used, and
> widely understood toolbase).
>
> - Put the ODS developers' feet to the fire to produce an interactive
> report shell developer. SAS has its choice of tail-lights to chase
> here. Every piddlin' report generator for the past decade has had
> this: a layout view in which elements are dragged and dropped,
> formatting applied, and variables indicated. Get with the times.
> Hell, the 1990s would be a good start.
>
> - Fire the existing ODS marketing team. Two weeks of trolling through
> docs, SUGI presentations, SI descriptions of the tool, and it's
> still not clear what the capabilities of the system are (and other
> than breaking the bondage to monospace, mainframe, greenbar
> reporting, they are few, particularly for a 21st century
> application). SI shouldn't be getting its ass kicked by a two bit,
> pathetic, Windows-only, fully interactive report writer. It is.
> Shame.
>
>--
>Charming man. I wish I had a daughter so I could forbid her to marry one...
| 
