Tom Duerbusch wrote:
>>So, I was wondering....in the 21st century, there must be a better
>>way. I'm thinking something that would take a base report, insert
>>"code" into it and print it. Take all that crap out of the
>>application program. I'm not tied to a PDF format. The bad part
>>about PDF output is you need a print server to print the output.
...and Thomas Denier replied:
>The groff text formatter is free, and included in many Linux
>distributions. The formatter is built around a macro processor,
>and the exact input syntax depends on the choice of macro package.
>The macro package I am most familiar with uses a line starting
>with '.P' to indicate a paragraph break and a line starting with
>'.H' to indicate a heading. If your application program was
>re-written to produce groff input, the reports would still contain
>formatting information, but this information would be stated in
>terms of document structure rather than printer internals.
This is a good suggestion, but I really don't think any ?roff-based language
qualifies as "21st century". After all, roff pre-dates the Internet. :-)
If you're going to rewrite the filter that converts your raw CICS output to a
printable form, I'd suggest marking it up with XML tags. XML is going to be
well-supported into the 21st century, and IMHO it gives you a lot more
flexibility than roff. I've used both for many years, and much prefer XML.
I'm going to get on my soapbox for a bit about this, and give you an earfull
about document management.
<rant subject="Document Management" level="abstract">
The key to having any flexibility with your documents is to separate the
markup from the presentation, and the best way to do that is to use "semantic
markup". That's markup that expresses the meaning of the text, which is
different from the structure or the representation. As an example,
representational markup might use two line-breaks to indicate a paragraph,
and structured markup would indicate the paragraph boundaries. But semantic
markup would describe the purpose of some text: a step within a procedure or
information about online devices, for example.
The value of doing that is that by encoding information about the purpose of
text, programs at various stages in the document preparation chain can make
decisions on how to structure and represent them for you. Also, you've made
a multi-purpose document that can be easily re-used, and targeted for
different audiences or media.
But why go to all that trouble? Well, it's not much trouble, you have to mark
it up somehow if you want anything other than mono-font text, perhaps
word-wrapped. You might as well do it in as general a way as possible, to
give you the most flexibility so you don't have to come back and re-visit
this again.
</rant>
As a practical matter, though, which approach you take depends on your
experience with markup languages. Roff is good if you know it, but as
someone who's been using it for a few decades I wouldn't recommend it. It is
too easy to slip back into writing representational markup, which then
restricts what you can do with it. I'm suggesting XML because it is
scalable: you can start by implementing some simple markup now, and other
folks can add more semantics later on if they need it. But doing this does
not require changing the entire document prep software chain, it usually only
requires extensions to XML stylesheets.
Of course, even if you do mark it up in roff, you can always run it through a
roff -> DocBook XML filter at some point if you need to.
If you do use XML, you can convert your document into just about any format.
The XML packages on Linux supply conversions to PDF, PostScript, HTML, RTF,
and probably roff and others. BTW: your printer probably wants PostScript,
and CUPS is set up to generate that from all sorts of input formats.
I'd recommend rewriting your markup insertion program to put in some subset of
DocBook XML to replace the PCL, then use something like OpenJADE to produce
the PDF or PostScript from it. Better yet, produce HTML, put that on a web
server and save some paper. :-)
All this may be overkill for what you really need to do, but I'm not sure what
your goals or limitations are here. It sounds like learning either roff or
XML will involve a learning curve for you, so we should figure out which one
is shorter. Contact me off-list if you want, I'll be glad to help you learn
this stuff.
- MacK.
-----
Edmund R. MacKenty
Software Architect
Rocket Software, Inc.
Newton, MA USA
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
