You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2000/12/22 15:09:28 UTC
IE bug whith FOP-produced PDFs : another solution
Hi cocooners,
There is periodically a thread on this list about "PDF files produced by
FOP do not display in Internet Explorer". The Cocoon FAQ explains the
bug and gives some hints at
http://xml.apache.org/cocoon/faqs.html#faq-iepdfbug
I found yet another solution : by adding a "Content-Disposition" header
in the servlet response (thanks to Matthew Smith for the hint), IE
considers the file extension of this header instead of the one of the
request.
So try adding the following in your XSP :
<xsp:logic>
response.addHeader("Content-Disposition", "attachment;
filename=foo.pdf");
</xsp:logic>
and IE will display your PDF !
The only drawback is that IE shows the "save or open" dialog and
displays the document in a separate window.
Netscape's behaviour is not affected and it uses the Acrobat plugin as
usual.
I tested it with IE 5.0 / Netscape 4.7.
Cheers,
--
Sylvain Wallez
Anyware Technologies
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ulrich Mayring a écrit :
>
> Sylvain Wallez wrote:
> >
> > You're right. response.addHeader is meant for headers with multiple
> > values, which is not the case here.
>
> Did I say "thank you for the fix" on behalf of our whole support team?
> :)
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
I think no ;-) but that's no problem.
Now I guess this trick was useful. Hey folks, how can I have it added to
the FAQ ?
--
Sylvain Wallez
Anyware Technologies
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Ulrich Mayring <ul...@denic.de>.
Sylvain Wallez wrote:
>
> You're right. response.addHeader is meant for headers with multiple
> values, which is not the case here.
Did I say "thank you for the fix" on behalf of our whole support team?
:)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ulrich Mayring a écrit :
>
> Sylvain Wallez wrote:
> >
> > The Content-Disposition header is used to suggest a more appropriate
> > filename to the browser than the filename part of the request address
> > (see RFC 2616, section 19.5.1).
>
> > + response.addHeader("Content-Disposition", "attachment;
> > filename=bar.pdf");
>
> I suggest to use response.setHeader instead, because addHeader doesn't
> exist in JSDK2.1 or below and thus won't run with JServ.
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
You're right. response.addHeader is meant for headers with multiple
values, which is not the case here.
--
Sylvain Wallez
Anyware Technologies
RE: IE bug whith FOP-produced PDFs - again -sigh-
Posted by Torsten Curdt <tc...@dff.st>.
Thanks for your efforts man! You are absolutely right!
We tried it with all our IE versions (5-5.5 with/without
ServicePack). Always the same behavior.
Now what.. put white text in background to make it bigger?! ;)
(Maybe we are lucky and the final content is enough)
Would be interesting at which size it wraps to working.
I remember the initial problem was the undefined
Content-Length, right?!
--
Torsten
> -----Original Message-----
> From: Peter Jacobs [mailto:peter.jacobs@advalvas.be]
> Sent: Tuesday, January 16, 2001 11:34 AM
> To: cocoon-users@xml.apache.org
> Subject: RE: IE bug whith FOP-produced PDFs - again -sigh-
>
>
> My suggestion probably didn't work for you, so I checked it again.
> Indeed, with some files I get the same symptoms: no display first
> time, but
> OK after a refresh.
>
> After some experimenting, it seems to be a problem with the size of the
> resulting PDF:
> a small PDF does not work, a bigger PDF does.
>
> you can see an example at:
> http://www.mediamagie.com/cocoondemo/foptest/fixIE/test.htm
>
>
> HTH,
> Peter Jacobs
RE: IE bug whith FOP-produced PDFs - again -sigh-
Posted by Peter Jacobs <pe...@advalvas.be>.
My suggestion probably didn't work for you, so I checked it again.
Indeed, with some files I get the same symptoms: no display first time, but
OK after a refresh.
After some experimenting, it seems to be a problem with the size of the
resulting PDF:
a small PDF does not work, a bigger PDF does.
you can see an example at:
http://www.mediamagie.com/cocoondemo/foptest/fixIE/test.htm
HTH,
Peter Jacobs
-----Original Message-----
From: Peter Jacobs [mailto:peter.jacobs@advalvas.be]
Sent: maandag 15 januari 2001 17:47
To: cocoon-users@xml.apache.org
Subject: RE: IE bug whith FOP-produced PDFs - again -sigh-
maybe this works:
order.xml?media=pdf&fixIE=.pdf
HTH,
Peter Jacobs
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: maandag 15 januari 2001 17:22
To: cocoon-users@xml.apache.org
Subject: IE bug whith FOP-produced PDFs - again -sigh-
> > The Content-Disposition header is used to suggest a more appropriate
> > filename to the browser than the filename part of the request address
> > (see RFC 2616, section 19.5.1).
>
> > + response.addHeader("Content-Disposition", "attachment;
> > filename=bar.pdf");
>
> I suggest to use response.setHeader instead, because addHeader doesn't
> exist in JSDK2.1 or below and thus won't run with JServ.
...I thought we got it working. But #&* IE gives nothing but a blank
screen until we hit the reload button.
We tried:
1. order.xml?.pdf&media=pdf
-> blank screen
2. order.xml?media=pdf with
add/setHeader("Content-Disposition", "attachment;filename=order.pdf");
-> two popups for open/save
and also
add/setHeader("Content-Disposition", "inline;filename=order.pdf");
-> blank screen
3. We even mapped *.pdf to C1 and got
order.pdf?media=pdf
-> blank screen
(media=pdf creates the stylesheet PI as you might have assumed)
We're loosing all our hair.. ;)
I know this is a never ending thread...
..did we miss something?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: IE bug whith FOP-produced PDFs - again -sigh-
Posted by Peter Jacobs <pe...@advalvas.be>.
maybe this works:
order.xml?media=pdf&fixIE=.pdf
HTH,
Peter Jacobs
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: maandag 15 januari 2001 17:22
To: cocoon-users@xml.apache.org
Subject: IE bug whith FOP-produced PDFs - again -sigh-
> > The Content-Disposition header is used to suggest a more appropriate
> > filename to the browser than the filename part of the request address
> > (see RFC 2616, section 19.5.1).
>
> > + response.addHeader("Content-Disposition", "attachment;
> > filename=bar.pdf");
>
> I suggest to use response.setHeader instead, because addHeader doesn't
> exist in JSDK2.1 or below and thus won't run with JServ.
...I thought we got it working. But #&* IE gives nothing but a blank
screen until we hit the reload button.
We tried:
1. order.xml?.pdf&media=pdf
-> blank screen
2. order.xml?media=pdf with
add/setHeader("Content-Disposition", "attachment;filename=order.pdf");
-> two popups for open/save
and also
add/setHeader("Content-Disposition", "inline;filename=order.pdf");
-> blank screen
3. We even mapped *.pdf to C1 and got
order.pdf?media=pdf
-> blank screen
(media=pdf creates the stylesheet PI as you might have assumed)
We're loosing all our hair.. ;)
I know this is a never ending thread...
..did we miss something?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
IE bug whith FOP-produced PDFs - again -sigh-
Posted by Torsten Curdt <tc...@dff.st>.
> > The Content-Disposition header is used to suggest a more appropriate
> > filename to the browser than the filename part of the request address
> > (see RFC 2616, section 19.5.1).
>
> > + response.addHeader("Content-Disposition", "attachment;
> > filename=bar.pdf");
>
> I suggest to use response.setHeader instead, because addHeader doesn't
> exist in JSDK2.1 or below and thus won't run with JServ.
...I thought we got it working. But #&* IE gives nothing but a blank
screen until we hit the reload button.
We tried:
1. order.xml?.pdf&media=pdf
-> blank screen
2. order.xml?media=pdf with
add/setHeader("Content-Disposition", "attachment;filename=order.pdf");
-> two popups for open/save
and also
add/setHeader("Content-Disposition", "inline;filename=order.pdf");
-> blank screen
3. We even mapped *.pdf to C1 and got
order.pdf?media=pdf
-> blank screen
(media=pdf creates the stylesheet PI as you might have assumed)
We're loosing all our hair.. ;)
I know this is a never ending thread...
..did we miss something?
--
Torsten
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Ulrich Mayring <ul...@denic.de>.
Sylvain Wallez wrote:
>
> The Content-Disposition header is used to suggest a more appropriate
> filename to the browser than the filename part of the request address
> (see RFC 2616, section 19.5.1).
> + response.addHeader("Content-Disposition", "attachment;
> filename=bar.pdf");
I suggest to use response.setHeader instead, because addHeader doesn't
exist in JSDK2.1 or below and thus won't run with JServ.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ulrich Mayring a écrit :
>
> Sylvain Wallez wrote:
> >
> > So try adding the following in your XSP :
> > <xsp:logic>
> > response.addHeader("Content-Disposition", "attachment;
> > filename=foo.pdf");
> > </xsp:logic>
> > and IE will display your PDF !
>
> And what if my filename is foo.xml?
The Content-Disposition header is used to suggest a more appropriate
filename to the browser than the filename part of the request address
(see RFC 2616, section 19.5.1).
If the request filename is "foo.xml" and the header contains "bar.pdf",
IE will consider "bar.pdf" and use the "pdf" extension to determine the
file type.
To test the behaviour of this header, I patched the "test-fo.xml" file
in Cocoon 1.8 samples/fo as follows :
<?xml version="1.0"?>
+ <?cocoon-process type="xsp"?>
<?cocoon-format type="text/xslfo"?>
+ <xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core">
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">
+ <xsp:logic>
+ response.addHeader("Content-Disposition", "attachment;
filename=bar.pdf");
+ </xsp:logic>
<fo:layout-master-set>
...
</fo:root>
+ </xsp:page>
You can do it by yourself to test it further.
--
Sylvain Wallez
Anyware Technologies
Re: IE bug whith FOP-produced PDFs : another solution
Posted by Ulrich Mayring <ul...@denic.de>.
Sylvain Wallez wrote:
>
> So try adding the following in your XSP :
> <xsp:logic>
> response.addHeader("Content-Disposition", "attachment;
> filename=foo.pdf");
> </xsp:logic>
> and IE will display your PDF !
And what if my filename is foo.xml?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung