Hi, Why don't using the pdf format ? It is the portable document format so can be wiewed either on Unix or windows side. It is easy to create, it can be compressed (more than a world format), it cannot be modified and has much more advantages.
Michel -----Message d'origine----- De: Chris Knipe [mailto:[EMAIL PROTECTED] Date: samedi 9 août 2003 23:36 À: Wiggins d'Anconia Cc: [EMAIL PROTECTED] Objet: Re: document creation. > > Please keep in mind where possible, I'd like to automatically print the > > invoices prior to archiving the hard documents. The documents is also quite > > complex layout wise, with allot of graphs (Images) and about 95% table > > based... Is HTML really the only alternative here?? I'm not sure whether > > printing HTML will be a very good idea... > > > > HTML is one option but not the only one. XML would be the naturally most > portable and upgradeable probably. Why store them as files in the first > place, why not just store them to a database? You can store them in any > number of possible ways, txt, csv, pdf, html, xml, or not at all, just > store their values and a template and generate them on the fly... Yes, obviously. It's pretty much standard telecoms stuff (notable the majority being detailed call logs). These are all stored via a database as they occur and yes, there are already web based interfaces to "lookup" usage and cost (bill) information. But that is only one side of the story, and the side of the story that does work. Obviously, I cannot simply put bills online (or email for that matter) and ensure that all clients actually receive a bill (Frankly, I may stand corrected but I think there is a law in my country which actually ensures that I must make all attempts possible to get invoices to clients on time). Some also prefer to have a hard copy for numerious reasons which falls out of the scope of this topic (Record keeping, TAX, etc)... The obvious solution, is to provide invoices both online and off. Now, online bills aren't a problem I made a nifty little PHP based app to pull the data and let it look pretty much in line to what I want my invoices to look like. This however is not a solution for a "printed" invoice that should be mailed. So basically, I need to create a second set of professional looking documents that can be printed and posted to my clients. It's as simple as that. And no, manually looking up 2000+ invoices a month on IE / Netscape and manually printing them is not a option (just in case it was questioned). Page breaks to my knowledge won't work on HTML-based documents in any case, instead if I go and do silly things like count lines which I feel really should NOT be neccessary. > Either way we won't be able to provide you the help without you first > setting explicitly what your goals are, and making an attempt yourself. Yes, print "whatever" does work and it does create output that can be sent to lpr so that it is printed and that I can post it. However, print "whatever" does not create a professional looking invoice that I or my company for that matter will feel comfortable sending to customers. Neither does it handle tables very well, nor images. Not to mention bolds, italics, underlines, or font sizes (I'm sure there's a whole list that I did not mention, but once again, it falls outside the scope of this topic IMHO)... Now a module that comes without documentations (notable, RTF::Document), you can hardly expect me to read non existent documentation. Apart from Win32::OLE and RTF::Document, what else is there that I can actually use (note my original question), to create decently looking documents to send to lpr. Once I know what I can possibly use to achieve this, I'd be more than happy to go and RTFM, provided that there actually is a FM to R. -- me -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
