W3C home > Mailing lists > Public > www-xsl-fo@w3.org > March 2007

RE: Is this stuff ready for prime time?

From: Howard, Chris <HowardC@prpa.org>
Date: Mon, 5 Mar 2007 12:06:20 -0700
Message-ID: <1305E9F69BC3CE49ABCDC8E00492F702017A8E55@titan.internal.prpa.org>
To: <www-xsl-fo@w3.org>


Thanks to all who have responded to my question.

Being a one-man-band, my priorities may be somewhat different
than those of a big document production operation.

My customers who get paper documents (their utility bill) don't
really care.  Some customers are sophisticated enough to be interested
in electronic document formats, for those I am already producing a
bill in XML format of my own specification.  We are slowly moving toward
more and more online self-service facilities.  I can see where multiple
output formats would be a good thing.  At the moment we use the
individual
PCL printer files with SwiftView PCL viewer to allow our customer
service
call-center people to look at an image of the bill.  PDF would be nice
for
the bill image part and for over-the-web or email bill presentation when
we
get to that.

Then there is the bill-designer/graphic artist/bureaucracy customer
layer.
It would be useful for me to have a flexible system where the
bill-designer
decision makers could actually do the layout themselves.  But with the 
Perl-->PCL approach there is a lot of give and take finding a format
that
they like.  We generally don't change the bill layout very often.  But
it wouldn't bother me to move that whole activity away from my plate.
It's my general understanding that they want the bill to look a certain
way...  not like HTML where different browsers render things
differently,
more like PDF where it is presented to the customer service rep the
same way the end customer would have seen it on a piece of paper.
I'm hoping with increase in different presentation media this will
soften.

I consider the logic parts of data reduction/combination to be separate
from the bill layout/presentation.  The current system has both rolled
into one monolithic program.  That part I definitely don't like.

I'm told we could use Docucorp tools or something like that to
accomplish
all of this.  But there just isn't the money for it.  They can get me
to muck around in the Perl code... I don't think they will see the need
to spend lots of money for alternatives unless/until other issues
press the need.  So this shift would be mostly for my benefit.

It sounds like the horsepower of the tools is not a problem.  That's
good to know.

I will investigate the training aspect.  I really don't have a lot of
time to learn this.  So, if it is fraught with pitfalls and potholes,
it won't happen.  I hate to start down that road if I'm just wasting my
time.... which is why your responses have been very helpful.

Thanks!

Chris
Received on Monday, 5 March 2007 19:05:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:06:14 GMT