- From: Howard, Chris <HowardC@prpa.org>
- Date: Mon, 5 Mar 2007 12:06:20 -0700
- 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 UTC