New Printing Options from RTF Charles Engelke Info Tech, Inc. Trnsport Users’ Group October 15, 2004

Overview Trnsport is about to get a new way to create reports –Still uses RTF –Produces “typeset” PDFs, not just text We’ll talk about –Why it happened –How it works –How it happened

Trnsport Reports Plain text files –Created with Report Template Facility (RTF) –Each licensee can customize in a supported way But users often request “pretty” reports –Like a Word document, or typeset –And plain text isn’t pretty Philippines DPWH requires pretty reports –Other licensees want to do it, too

Why Plain Text and RTF? Partly due to history –Mainframe software had limited options But also because it has great benefits –After migration to client/server, reporting architecture was kept –Provided very useful site customization facilities, maintainable and portable It does the core job very well

Some Users Chafe at Limitations They want nicer, richer printing –Font faces, styles, sizes –Page headers and footers –Cross references and tables of contents –Maybe graphics, too More than aesthetic reasons –Can increase clarity of information –Helps organize complex documents

What Can be Done About It? Change reporting architecture? –Say, to something like Crystal Reports –But would lose deep value of RTF –And would be a big undertaking Add an additional reporting architecture? –Increases complexity, hence development, support, maintenance, and deployment cost Use the existing architecture –And produce nicer printouts from text we can already generate

Desired Printing System

How Do We Get PDF from Text? Not a new problem at all Markup Tools from ’70s and ’80s –Runoff, troff; not very powerful or flexible More Modern Tools –TEX, LaTEX, DocBook SGML Proprietary Publishing Tools –Very expensive, not standardized HTML? –Good font control, but no page features –Estimator™ reporting experience was disappointing

Try XML Printing Tools Using DocBook XML for new RTF UG –Text file input and PDF output –(Also HTML, MS Help, other output available) Background material –Personal project to learn DocBook for software documentation –Notes at How about DocBook for Trnsport reports? XML file describes the document Publishing tools render the document

Sample DocBook File My Book 2003 Our Story So Far Once upon a time…

Real DocBook Examples The original XML fileoriginal XML And the rendered results in –A single HTML pagesingle HTML –Multiple linked HTML pagesMultiple linked HTML –Acrobat PDFPDF –Microsoft HTML HelpHTML Help –Microsoft Rich Text Format for WordRich Text Format

RTF to PDF via DocBook

First Try Step one was to hand-write a DocBook file to match a DPWH sample –Compare original with DocBook outputoriginalDocBook output Maybe close enough, but… –Little control over detailed formatting –Conversion was slow (30-60 seconds) –Tables didn’t render well (or at all with some batch tools) But this led to finding a better way

Second Try: Use the DocBook Infrastructure (without DocBook) Current DocBook XML to PDF conversion uses standard XML tools –XSLT converter (DocBook to XSL-FO) MSXML, Xalan, Saxon, many others available –XSL-FO processor (XSL-FO to PDF) Apache FOP, passivetex, RenderX XEP So, try skipping the first step –Have RTF generate XSL-FO directly instead of DocBook, then use XSL-FO tool to get PDF

RTF to PDF via XSL-FO

Results Were Very Encouraging Could create XSL-FO file that rendered PDF almost identical to the sample fileXSL-FO filePDFsample file –Down to different placement of “Sample” stamps on different pages! XSL-FO standard results in many XSL-FO processors being available –XEP worked best, but expensive. FOP worked well, is open source. Passivetex barely worked. Fast, accurate conversion –About 1 second with FOP or XEP

One Last Potential Refinement XSL-FO is very verbose –RTF template would be, too –So we defined a new XML dialect, and XSLT transforms to generate XSL-FO from it New XML dialect called pdfdoc –First version was called itidoc and very rough, but worked pretty well –Sample itidoc file and XSLT transform that creates the XSL-FO we sawitidoc fileXSLT transformXSL-FO we saw

Actual RTF to PDF via XSL-FO and XSLT

Next, Do This Inside Trnsport Turned out to fit into DPS architecture well –Created MakePDF.CMD file to convert XML (in OUTPUT.TXT file) to PDFMakePDF.CMD –Modified DPS jobexec.cmd to perform an optional post-processing step –Specified MakePDF.CMD in parameter file –Created RTF template to generate itidoc outputRTF template Only one actual change to existing code

Enhance Trnsport for This? Modify DPS and Batch Servers as shown in this example Modify installation to include FOP (which in turn needs Java) Add PDF viewer to clients Create a few XML RTF templates plus XSLT transforms to start things off

From Idea to Release in 2004 January –Idea to apply XML to Philippines DPWH requirement; developed proof of concept April –Presented to Trnsport Task Force –They asked “how much, and how fast”? June –Proposal delivered and approved; adds XML to PDF printing, three such reports (CES, LAS, SiteManager) December –Trnsport enhancement will be released

Example: New CES Program Summary Report List of all jobs in program with highlights Added CESPSUM process and template Process creates pdfdoc XML filepdfdoc New facility translates that to PDFPDF Available in demo room Still to do –PDF viewer in clients –Package, test, ship

Summary PDF reports coming to Trnsport this year –Based on XML using RTF The first step is not too big –And is happening now In the long term, many small enhancements will improve this more –Migrate more reports, add new ones –Enhance pdfdoc features –No large projects should be needed