[reportlab-users] ANNOUNCE: Client-server PDF creation with xtopdf and ReportLab and Python and XML-RPC

[Vasudev Ram]

On Mon, Oct 5, 2009 at 1:09 AM, Bill Janssen <janssen at parc.com> wrote:


> Vasudev,

>

>

Bill,

First, thanks for your feedback.

Could you say a bit more about the problem you are trying to solve?

>


I did not say anywhere (i.e., in any of my blog posts or this post to the
reportlab-users mailing list, about PDFXMLRPC) that I was trying to solve
any problem.

The fact is, I was not (trying to solve some problem). I simply wrote
PDFXMLRPC for fun. Did it initially as a rough version, a while back when I
was playing around with XML-RPC in Python, sometime after first writing
xtopdf. (So I happened to think of combining xtopdf with XML-RPC, in Python.
Also wrote a Ruby client for it, like the Python client, at that time, again
for fun and learning). Then recently I was looking through some of my old
code fragments and thought of cleaning up the code some, and releasing it as
open source software. That's all.

Not all software is written to solve an existing problem. Many people write
some of their software just for fun, and some of those people release some
of it to the world. Obviously you know all this - it's common knowledge,
which is why I'm a bit surprised by your question.




> Here are some of the questions that popped into my mind when I read your

> note.

>

> Why is it hard to convert text to PDF?



I did not say anywhere that it is hard to convert text into PDF.

Obviously there are many easy ways to do it (and not just the way you
mention below, that uses enscript and ps2pdf; thanks for mentioning that,
BTW - I did not know about it, about that pipeline and enscript at least,
though I knew of the existence of ps2pdf. Learnt something new and useful
today :). There are many (free and paid, open source or closed source)
command-line tools, GUI tools, etc. for PDF creation for both Linux and
Windows - Mac and other OS's too, I'm guess. There are also many SDKs /
libraries for different OS's, for PDF creation. I'm aware of several of
them: iText (Java), PDF::Writer and Prawn (Ruby), ReportLab (Python),
libharu (C), PDFTron, JPedal, PDFSharp (.NET), iTextShart (.NET), ... I
could go on. There are PDF printer drivers for Windows. Mac OS X has easy
ways to convert any or almost any content to PDF (so I've heard / read.)




> I just run GNU enscript into

> ps2pdf from GNU Ghostscript to do this -- no server required:

>

>

Nor did I say anywhere that a server is required for PDF creation from text
(or from any other format). However, a server (and a corresponding client,
may be _useful_ in certain cases, though, as I said above, I didn't write
PDFXMLRPC because I thought it was needed or would be useful - just did it
for fun).


 enscript -o- -M Letter foo.txt | ps2pdf - foo.pdf

>

> And, if a server is for some reason useful, why is it better to have a

> dedicated client, and drag XML-RPC into this?



I don't really like to keep repeating "I did not say ... " etc.; but again,
I did not say it is better to have a dedicated client either. Just did it
that way, and I recognize the validity of other approaches. Nor am I trying
to "drag XML-RPC" into this. I just happen to like XML-RPC, so I used it.
Nothing wrong with that.

If anyone has any issues with my approach (of having a server in the first
place, of having a dedicated client, of using XML-RPC, etc., that's fine
with me. I have not asked anyone to use PDFXMLRPC. People are free not to
use it. Again, obvious stuff ...




> Why not just use an HTTP

> server framework (say, SimpleHTTPServer), and let users just POST their

> text to the server and get back the PDF as the reply value?  Be more

> useful for programs that way, and users don't have to install clients.

>

> Bill

>

>

Though, as said earlier, I did not specifically choose XML-RPC (and
therefore a dedicated client) over the HTTP server + POST approach you
mention above (though I did think of some such approach, though using
BaseHTTPServer, not SimpleHTTPServer, and may implement that in future as
well), I do feel think that there can be cases where the XML-RPC approach
may be preferable to the HTTP server + POST approach. One simple case (a
non-technical reason) may be where your project is already using XML-RPC
extensively, for lots of things (services), and you (or more likely your
project manager) may not want to mess up things (meaning, really, not
confuse less experienced developers) by introducing another "paradigm" (of
REST / HTTP / POST, though I'm not sure it's large enough to merit the name
paradigm) apart from XML-RPC as a means of inter-process communication.
Though that's not a purely technical reason, those who have worked in
industry, as opposed to the academic world, know that there are often (even
maybe more often) non-technical (business, political) reasons that often
sway project decisions - whether such reasons are right or wrong. And those
reasons can also sometimes be the right reasons / right decisions - for the
success of the project. No one can say arbitrarily with any justification,
that all non-technical reasons (for taking a technical decision in a
project) are wrong. And I have actually worked on projects like that.

Another reason, a technical one this time, for possible use of XML-RPC for
this application, including the use of a client, can be if the text data is
coming in, in parts, over a period of time, for example because it is being
produced in parts over time, for any reason whatsoever. Could be coming in
over a socket from the producer, in bursts, with gaps. In that case, the
POST / REST approach might not be a good one, since (AFAIK), that approach
would result in your getting a PDF file for each chunk of text you send to
the server, since REST is stateless. Then you have the problem of joining
all those PDF files into one PDF file - which is possible, with tools like
pdftk, but more cumbersome. Instead, with the XML-RPC approach, you can just
keep sending those pieces of text as you get them, to the server, and the
server will keep writing them to the PDF Canvas of ReportLab, and nothing
will be sent back till you do your close() call, after which you will get
back your entire PDF with the combined content of all the text chunks you
had sent, at intervals. All this would be in the context of one long-held
open connection between the server and the client.
(Might have to do something about ensuring the connection doesn't time-out -
I have to check that - set a socket option, maybe.)

A few final points:

I do agree that not having to install a client is a benefit. But not all use
cases need that benefit or have it as a problem to install a client (despite
a lot of talk by a lot of people about the web being the only platform,
etc.) Also, not needing to install a client (in the REST / POST approach -
though in fact you do need a client - either a browser or curl or some
such), or using the enscript / postscript approach (AFAIK) implies a
"monolithic" approach, i.e. where you just run existing standalone programs
to do the text to PDF conversion. What about cases where you want to do that
conversion as part of some other work, i.e. a larger program? Or do it
repeatedly, in a loop, with varying parameters - e.g. customer invoices, but
with the logic parameterized by some runtime conditions / data ? And I even
mentioned such use cases in my original post - which Carl Karsten above,
BTW, thought was a good idea / well described. IMO he was referring partly
to those use cases - which come under the "callable / programmable" category
I mentioned. In these cases - where the conversion is wanted as part of some
larger process - the XML-RPC and programmable approach may be more
appropriate. Note: since the main method used for the conversion is
writeLine() (see the server and client code), you can sprinkle calls to
writeLine throughout your larger program (which would be your client) as
needed (doing other things in between those calls), and get the desired
result.

Wow, long reply .. :)

Once again, I appreciate your feedback and questions. It's stimulating to
get questions and have to defend one's decisions, whether one is proved
right or wrong or both. In any case one learns something ...

Best,
Vasudev
---
Dancing Bison Enterprises
Biz: www.dancingbison.com
Google Profile: http://is.gd/tWe3
Blog: jugad2.blogspot.com
xtopdf: fast and easy PDF creation: www.dancingbison.com/products.html
Twitter: @vasudevram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091005/f5a3ddc7/attachment-0001.html>