Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Pretty output on paper - how best to do it?

by EvdB (Deacon)
on Mar 11, 2002 at 11:32 UTC ( #150856=perlquestion: print w/replies, xml ) Need Help??

EvdB has asked for the wisdom of the Perl Monks concerning the following question:

I'm putting together an administration system for a school and I need to generate a whole load of paper output - how best should I do this?

The system has a web front end but printing out HTML pages won't cut it. The paper output must be elegant and repeatable. It will range from forms for corrections and update information through to end of year reports on the children.

Preferably the output will be as PDFs - this makes them nice and easy to handle - which can then be printed by the user through their browsers. There will also be a need for some mass printing directly from the server. I have played with using HTML (not controllable enough), LaTeX (slightly awkward due to production of files etc) and with PDFLib (very slow to create the code but blissful to work with once done).

In summary I want something which will create pretty controllable output on paper without too much hassle with writing the code to create it. Does anyone have any suggestions, has anyone solved this problem already?

  • Comment on Pretty output on paper - how best to do it?

Replies are listed 'Best First'.
Re: Pretty output on paper - how best to do it?
by cjf (Parson) on Mar 11, 2002 at 11:49 UTC

    If you're considering creating PDFs then PDF::API2 is definately worth a look at.

Re: Pretty output on paper - how best to do it?
by webadept (Pilgrim) on Mar 11, 2002 at 12:08 UTC
    cjf mentioned the PDF::API2 mod, and I'll second that. Working with the PDF libraries,.. all of them are slow, but the PDF::API2 seems to be faster. This is like saying the tortise is faster than the sea turtle on land, but its worth the look and effort to get it working.

    The only thing I might say with regards the LaTeX is the PDF's, once created are nicer on the user side to archive and save, and thus available down the road when they ask for the copy again. Also its easyer for users to save their own copies and such. Saving is good as well, because you don't have to re-create them, just sever them the archived copy.

    Luck to you.

    Glenn H. (which was mentioned) isn't slow, as it's a thin XS layer over C code. is an OO layer over that, and is fast too (as it's a fairly thin but intuitive layer).

      But do beware of the license, which will require purchasing for commercial public web work, despite the fact that you have the source code (it's not "open source").

Re: Pretty output on paper - how best to do it?
by Tardis (Pilgrim) on Mar 11, 2002 at 11:50 UTC
    Could you please explain:

    slightly awkward due to production of files etc

    We use LaTeX extensively, producing automated documents from templates that are printed to a postscript printer. The results are very professional. Not as easy to create as a Word document perhaps, but the results and versatility are worth your initial pain.

    Via standard PS and LaTeX tools, you can easily convert a LaTeX document into PDF as well, or even plain text.

      All right, I was looking for a problem with LaTeX, which happens to be a system that I admire greatly. The files I meant are partly the .aux, .log etc but also having to create a .tex file to process. It is not as nice as keeping it all in memory and there is a bit of cleanup involved too.

      All said LaTeX may well be the way I go although I will of course take a good look at all ideas offered here.

        I understand your concern, having a bunch of files lying around is not quite as elegant.

        However such a 'problem' is ripe for abstraction into a module. Create some methods to create, store and fetch pdf files, and hide all that LaTeX magic externally.

        Even better, make the file generation work for you. The .dvi file that LaTeX generates can be used again and again. Do some simple date checks of your source file against that of the .dvi file and you effectively have an efficient cache.

        We use such a thing here in a billing system. Statements are generated and stored on the disk. The .tex, .txt and .ps files are all stored. When someone wants to reprint or reshow the statement, it fetches the appropriate .txt or .ps file. If it doesn't exist, it regenerates them from the .tex file.

        In that way, whenever we are short on disk space (or if we want to minimize the amount of files we are moving from machine to machine during a hardware upgrade :-), we just nuke everything but the .tex files, and everything still works, if more slowly.

      Not very Perl related; but when I use LaTeX the fonts always come out looking very, uh, LaTeXish. What am I doing wrong?

       - ask

      ask bjoern hansen,   !try; do();
Re: Pretty output on paper - how best to do it?
by Jerry (Scribe) on Mar 11, 2002 at 17:14 UTC
    RTF Files are pretty easy to create, and can be opened in any word processor, windows, mac, linux, or unix. They carry a distinct difference from PDF in being easily editable by end users, whereas PDF authoring is usually left to technical staff or automation.

    If this sounds like what you need, try RTF::Document, found at

    Or here's a code sample of a basic rtf if you prefer to RYO.

    {\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset +0 Arial;}{\f1\fnil\fcharset2 Symbol;}} \viewkind4\uc1\pard\b\f0\fs28 Edwards School\b0\fs40\par \fs20 Grade Report\par \par Blah - Blah\par \pard{\pntext\f1\'B7\tab}{\*\pn\pnlvlblt\pnf1\pnindent0{\pntxtb\'B7}}\ +fi-720\li720 yaketty\par {\pntext\f1\'B7\tab}scmaketty\par {\pntext\f1\'B7\tab}placketty\par }

    "In my line of work, I don't invent many wheels. I just custom fit wheels already in place."

      The problem with RTF is certain parts of it are open to interpretation by the client that opens them. Widow and Orphan control being just one aspect, font control being another. This means that you can't absolutely 100% guarantee the look of the output. PDF doesn't suffer from that problem, luckily, however you are right that in general you can't edit a PDF.
Re: Pretty output on paper - how best to do it?
by Matts (Deacon) on Mar 11, 2002 at 13:59 UTC
    If you're looking at PDFLib, make sure you use my OO wrapper, as it's much easier to use than the core shipped with pdflib.

    However have you also considered using XSL FO? You could use a system() callout to create the PDF's, either to Apache's FOP, or to PassiveTeX, and the results are very nice, and XSL FO is reasonably easy to work with.

    Finally another option is to use HTMLDoc which also produces really nice results.

Re: Pretty output on paper - how best to do it?
by Stegalex (Chaplain) on Mar 11, 2002 at 15:52 UTC
    I did this but the solution is not pretty. What I did is to run the HTML through html2ps which produces poscript and then I ran the postscript through ps2pdf. May not be the best solution, but at the time it was the best I could come up with. Good luck! I like chicken.
Re: Pretty output on paper - how best to do it?
by $name (Pilgrim) on Mar 11, 2002 at 21:48 UTC
    I've used PDF::Create with some success for company envelopes and time sheets that are backended by pgsql database that way all your docs stay formatted the way you ant them
Re: Pretty output on paper - how best to do it?
by EvdB (Deacon) on Mar 12, 2002 at 10:03 UTC

    Thank you all for your comments on my post.

    In my particular situation I wanted to create PDFs from data in a database, so editing the resulted PDFs is not an issue. The idea of creating rich text files though is a good one and I'll probably use it for other parts of the system.

    The three main options seem to be produce PDFs directly from the code, produce .tex files and process them with LaTeX, or turn html inte PDFs using something like htmldoc.

    I think that what I will do is produce PDFs by translating HTML. The logic for this is that I have to create the HTML anyway for when I display data on the web browser so it seems silly not to simply use the same layouts on the paper. If there is then a situation where doing this is innapropriate then churning out tex files seems a good bet - it very nicely separates the logic and the layout.

    Finally I will produce PDFs directly from the code in only very rare situations, for example where I need the greatest control over where text or graphics appears on the page. This will be so specialised that t will be worth the effort of cooking up the code.

    My situation is probably quite unique in that I need to produce may different types of paper output and so cannot invest too much time on each one. If I was just producing a single output, say a bill or a certificate then much more time could be justified.

    Thank you again for all your input.

Re: Pretty output on paper - how best to do it?
by erikharrison (Deacon) on Mar 11, 2002 at 20:03 UTC

    What kind of files are we talking here? When we say "pretty" do we mean, organized and readable? Because it might be that good ol' print formats would be what you're looking for. However, I would assume that the responces that everyone is giving mean otherwise.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://150856]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2020-05-29 14:33 GMT
Find Nodes?
    Voting Booth?
    If programming languages were movie genres, Perl would be:

    Results (169 votes). Check out past polls.