xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woodhouse, Graeme" <Graeme.Woodho...@proquest.co.uk>
Subject RE: Large PDF's files fail to stream correctly
Date Mon, 07 Apr 2008 14:41:15 GMT
Hi Jeremias,

Your right - having no problems with smaller PDF's.

I think it all has to do with the setup I have with tomcat connecting to apache and the way
data chunks are sent. This is a long standing problem in my company - I'm amazed it isn't
a well known problem.

Thanks for your links, I've tried what has been suggested there. Including setting the contentLength
and mime type.

                        resp.setContentType("application/pdf");
                        resp.setHeader("Content-disposition", "filename=List.pdf");
                        resp.setContentLength(Integer.MAX_VALUE);

setting the content length to the exact size of the pdf doesn't work either, I tried :( (using
a static file)

Graeme Woodhouse
Software Engineer
ProQuest

Direct-Line:              +44 (0) 1223 271 264
Fax:                         +44 (0) 1223 215 513

-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: 07 April 2008 14:09
To: fop-users@xmlgraphics.apache.org
Subject: Re: Large PDF's files fail to stream correctly

Have you checked the various servlet-related entries in the FAQ?
http://xmlgraphics.apache.org/fop/faq.html

Furthermore, there's a page on servlet in a FOP-context that may help
you:
http://xmlgraphics.apache.org/fop/stable/servlets.html

I think the key points are that the MIME type is correct and that the
PDF file size is set (as done in the example servlet [1]) on the servlet
response. Otherwise, the PDF plug-in in the browser may not work as
expected. There are also some possible problems concerning encrypted
HTTP. This has been discussed at length on this mailing list in the past
(search the archives if applicable, most of it should be documented on
the website, though).

[1] http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/servlet/FopServlet.java?view=markup

The mail subject suggests that you don't have any problems for smaller
PDFs. Is that the case?

On 07.04.2008 10:33:33 Woodhouse, Graeme wrote:
> Hi Daniel,
>
> Thanks for your help - as a bit of a test I tried the following two scenarios:
>
> I set the response size to Integer.MAX_VALUE. Which didn't work :(
>
> I also tried first saving the output to a file - waiting until the file was complete,
then streaming the file to the browser through the response. Which didn't work :(.
>
> Your right that I could temporarily link to the file I created and then delete the file
after but your right about the security access. Its not something that we could do as the
pdf's contain sensitive information + direct access to the server isn't really an option as
it bypasses the rest of the security we have in place.
>
> I don't suppose you or anyone else on the list know of any other way to get round this?
>
>
>
> Graeme Woodhouse
> Software Engineer
> ProQuest
>
> Direct-Line:              +44 (0) 1223 271 264
> Fax:                         +44 (0) 1223 215 513
>
>
> -----Original Message-----
> From: Daniel Appelt [mailto:daniel.appelt@gmail.com]
> Sent: 04 April 2008 18:43
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Large PDF's files fail to stream correctly
>
> Hi Graeme,
>
> in general, you do not know in advance how long the rendering with FOP
> will take. For large files it is not unlikely that the browser times
> out or finishes fetching the PDF file in an unfinished state.
> A possible pseudo-streaming solution could be to let FOP save the file
> on the server, and use a website with an AJAX script on the client
> side that regularly checks the state of the file. If file size isn't
> changing between two or more consecutive checks, it might be assumed
> that FOP has finished rendering the file and you could redirect the
> browser to the respective URL or show it as a link. Of course, this
> might still be problematic with regards to security...
>
> Cheers,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>



Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message