XML and Pre-Printed Formsets

[ddyer]

I need to print the following invoice.xml data onto a standard
pre-printed invoice formset. Meaning a form that is pre-printed with
boxes, blocks and columns which identify where each data element must
print.

When displayed by a browser, this record appears nicely as an invoice
form, after being translated through an xsl style sheet (titles and
headings are displayed from the style sheet.) Ideally, I want to place
a button on this screen which will provide a way to print the displayed
invoice onto the pre-printed invoice formset.

invoice.xml
-<invoice id="178761" custid="1212" model="20">
<customer>MARITIME SHOPPING</customer>
<custad1>c/o MARINE FITTERS</custad1>
<custad2>31375 JOHNSON DR</custad2>
<custad3>SAN DIEGO</custad3>
<custad4>CA</custad4>
<custad5>91821</custad5>
<contact>Davy Jones</contact>
<phonbr>555-444-5555</phonbr>
<faxnbr>555-333-4321</faxnbr>
<ordate>06 Apr 2006</ordate>
<schedule>Early April</schedule>
- <lines>
- <line id="1">
<optdesc>Compass</optdesc>
<featid>ABC700</featid>
<feature>700 - 3in Compass</feature>
<qty>1</qty>
<price>$270</price>
<item>1231148</item>
</line>
- <line id="2">
<optdesc>Marine Radio</optdesc>
<featid>STND100</featid>
<feature>Standard Radio Transceiver Model 100</feature>
<qty>1</qty>
<price>$650</price>
<item>13802</item>
</line>
</lines>
<total>$920</total>
<dest>CALIFORNIA</dest>
<tax>73.60</tax>
<freight/>
<discount/>
<amount>$993.60</amount>
</invoice>

[Joe Kesselman]

In other words, you want to do very precise layout of what data appears
where on the printed page, right?

Sounds like a good job for XSLT to XSL-FO to a suitable renderer. (Or
XSLT to other page-layout language like LaTex to a renderer for that,
but then you're bridging out of the XML world.) The result's likely to
be a PDF which is what you'll actually print, unless you've got a
renderer that talks to printer drivers directly.

Fiddly detail, but straightforward. Not something that's likely to be a
button on a browser, though, unless you're willing to download a
considerable amount of code or browsers finally start supporting XSL-FO
(which would be nice but unfortunately I don't see it happening very
quickly).

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Joe Kesselman]

Joe Kesselman wrote:

Fiddly detail, but straightforward.

At least, straightforward on a printer you've calibrated for. Messy if
printer resolution and paper alignment and so on vary; then you need to
design an adjustment process into the system. (It's easier to print the
whole form with data inserted rather than to print into proper alignment
with a pre-printed form; if it's all coming from the computer everything
scales/shifts the same.)

In any case, what you do is treat the source XML as formatted data, and
run it through a "compilation" process to get it into a form that'll
print how/where you want it to. Exactly what the steps are depends on
what you're doing. As with any other kind of data formatting, there are
multiple reasonable ways to approach itt.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Peter Flynn]

Joe Kesselman wrote:

In other words, you want to do very precise layout of what data appears
where on the printed page, right?

Sounds like a good job for XSLT to XSL-FO to a suitable renderer. (Or
XSLT to other page-layout language like LaTeX to a renderer for that,
but then you're bridging out of the XML world.)
LaTeX is a common solution to this because it produces PDF very well.
The result's likely to
be a PDF which is what you'll actually print, unless you've got a
renderer that talks to printer drivers directly.
The big problem with sending people PDF (or letting them generate it
from a button) is that their local PDF-viewer which they use to print
with under MS-Windows is likely to have the "Scale to fit page" option
set, which will completely screw up all your spacing and measurement.
You need some way to ensure that it will get printed as-is, without
any smart-ass software intervening.
Fiddly detail, but straightforward. Not something that's likely to be a
button on a browser, though, unless you're willing to download a
considerable amount of code or browsers finally start supporting XSL-FO
(which would be nice but unfortunately I don't see it happening very
quickly).

This is one reason why using LaTeX may be an option. Provided your code
is robust enough (ie it will cope with any silly data the user has got
in the form, like control characters or backslashes), it's possible
to write a CGI script to run XSLT into LaTeX into PDF direct.

///Peter