Re: [PHP] target question
Have you tried to set a Content-Disposition header in the PHP script that
creates the PDF, asking the browser to attach the download? This way you
don't even need a new window.
Example from php.net/manual:
// It will be called downloaded.pdf
header('Content-Disposition: attachment; filename=downloaded.pdf');
On Mon, Mar 25, 2013 at 11:01 AM, Jim Giner jim.gi...@albanyhandball.comwrote:
target as in the form attribute
In my appl devl I utilize an extra window when my current form is asked to
generate a pdf report. Works well since that way the user can generate one
report into a new window, read it, close it, and still have the reports
menu in front of him/her and generate a 2nd report.
I'm experiencing a problem tho and I'm guessing it's associated with ie9
or FPDF. In my reports menu form, when I click on a button that will
generate a pdf, I alter the form's target to create a new window. This
used to work last fall, but since then I have a new laptop running ie9, not
8. The target changing js logic is working as far as I can see (alerts in
my js) but the effect is not there. Instead of a new window, the pdf opens
up in the same window where the menu was and so when the user does a back
he ends up going up one too many levels and has to re-request the reports
menu.
Didn't have this much trouble originally setting this up as I'm having now
trying to debug this. I'm using the FPDF extension/class to generate my
pdfs - made no recent changes there. Also my concept works very well still
in a simple html document that has only two buttons on it which I created
today to test a theory. That is - maybe it's not just IE9, but FPDF.
Anyone have any experience in this area?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On 3/25/2013 10:13 AM, Samuel Lopes Grigolato wrote:
Have you tried to set a Content-Disposition header in the PHP script that
creates the PDF, asking the browser to attach the download? This way you
don't even need a new window.
Example from php.net/manual:
// It will be called downloaded.pdf
header('Content-Disposition: attachment; filename=downloaded.pdf');
On Mon, Mar 25, 2013 at 11:01 AM, Jim Giner jim.gi...@albanyhandball.comwrote:
target as in the form attribute
In my appl devl I utilize an extra window when my current form is asked to
generate a pdf report. Works well since that way the user can generate one
report into a new window, read it, close it, and still have the reports
menu in front of him/her and generate a 2nd report.
I'm experiencing a problem tho and I'm guessing it's associated with ie9
or FPDF. In my reports menu form, when I click on a button that will
generate a pdf, I alter the form's target to create a new window. This
used to work last fall, but since then I have a new laptop running ie9, not
8. The target changing js logic is working as far as I can see (alerts in
my js) but the effect is not there. Instead of a new window, the pdf opens
up in the same window where the menu was and so when the user does a back
he ends up going up one too many levels and has to re-request the reports
menu.
Didn't have this much trouble originally setting this up as I'm having now
trying to debug this. I'm using the FPDF extension/class to generate my
pdfs - made no recent changes there. Also my concept works very well still
in a simple html document that has only two buttons on it which I created
today to test a theory. That is - maybe it's not just IE9, but FPDF.
Anyone have any experience in this area?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
And what happens to my original menu window?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On Mon, Mar 25, 2013 at 10:01:03AM -0400, Jim Giner wrote: target as in the form attribute In my appl devl I utilize an extra window when my current form is asked to generate a pdf report. Works well since that way the user can generate one report into a new window, read it, close it, and still have the reports menu in front of him/her and generate a 2nd report. I'm experiencing a problem tho and I'm guessing it's associated with ie9 or FPDF. In my reports menu form, when I click on a button that will generate a pdf, I alter the form's target to create a new window. This used to work last fall, but since then I have a new laptop running ie9, not 8. The target changing js logic is working as far as I can see (alerts in my js) but the effect is not there. Instead of a new window, the pdf opens up in the same window where the menu was and so when the user does a back he ends up going up one too many levels and has to re-request the reports menu. Didn't have this much trouble originally setting this up as I'm having now trying to debug this. I'm using the FPDF extension/class to generate my pdfs - made no recent changes there. Also my concept works very well still in a simple html document that has only two buttons on it which I created today to test a theory. That is - maybe it's not just IE9, but FPDF. Anyone have any experience in this area? This behavior of the browser actually conforms to the standard as far as I know. The target attribute is attached only to the a tag, according to w3schools.com. It may work when you use it with a form tag, it doesn't surprise me if IE doesn't honor it (of course, nothing IE does would surprise me). In any case, using it with the form tag appears to be non-standard usage, which may or may not be supported by individual browsers. I handle this situation differently. My generator code (also using FPDF) dumps the PDF in a PDF directory. Then I provide a link elsewhere with an Adobe Acrobat logo which, when clicked, opens the PDF in a separate window, using the aforementioned a href=example.com/pdfs/something.pdf target=_blankMy PDF/a paradigm. In any case, I doubt very much FPDF has anything to do with this. It just dumps its creation to wherever you tell it. The browser determines what helper application it will use to open it when it downloads the content. Whether to open a separate window/tab is determined by the HTML the browser is looking at when it makes the content request. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] target question
-Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: 25 March 2013 16:09 This behavior of the browser actually conforms to the standard as far as I know. The target attribute is attached only to the a tag, according to w3schools.com Actually, the W3C HTML 4.01 Recommendation says: target = frame-target [CI] This attribute specifies the name of a frame where a document is to be opened. By assigning a name to a frame via the name attribute, authors can refer to it as the target of links defined by other elements. The target attribute may be set for elements that create links (A, LINK), image maps (AREA), and forms (FORM). In the current HTML5 draft, target is explicitly a permitted attribute of the form tag -- although I believe it was originally marked as deprecated. None of this really addresses the OP's problem, however, about which I have very little clue. Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On 25 Mar 2013, at 16:35, Ford, Mike m.f...@leedsmet.ac.uk wrote: -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: 25 March 2013 16:09 This behavior of the browser actually conforms to the standard as far as I know. The target attribute is attached only to the a tag, according to w3schools.com Actually, the W3C HTML 4.01 Recommendation says: target = frame-target [CI] This attribute specifies the name of a frame where a document is to be opened. By assigning a name to a frame via the name attribute, authors can refer to it as the target of links defined by other elements. The target attribute may be set for elements that create links (A, LINK), image maps (AREA), and forms (FORM). In the current HTML5 draft, target is explicitly a permitted attribute of the form tag -- although I believe it was originally marked as deprecated. Indeed. In fact w3schools.com is known to be a very unreliable source of information these days. My advice would be to avoid it at all costs! http://w3fools.com/ -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On Mon, Mar 25, 2013 at 04:37:50PM +, Stuart Dallas wrote: On 25 Mar 2013, at 16:35, Ford, Mike m.f...@leedsmet.ac.uk wrote: -Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: 25 March 2013 16:09 This behavior of the browser actually conforms to the standard as far as I know. The target attribute is attached only to the a tag, according to w3schools.com Actually, the W3C HTML 4.01 Recommendation says: target = frame-target [CI] This attribute specifies the name of a frame where a document is to be opened. By assigning a name to a frame via the name attribute, authors can refer to it as the target of links defined by other elements. The target attribute may be set for elements that create links (A, LINK), image maps (AREA), and forms (FORM). In the current HTML5 draft, target is explicitly a permitted attribute of the form tag -- although I believe it was originally marked as deprecated. Indeed. In fact w3schools.com is known to be a very unreliable source of information these days. My advice would be to avoid it at all costs! http://w3fools.com/ Interesting. I wasn't aware of this. Thanks for the info. Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
With the header Content-Disposition: attachment the browser will
offer the response as a regular file download (with save/open
options). Your original page (menu) will remain intact.
Please note that this solution will not present the PDF directly to
the user (as it would with a popup window), instead he will need to
open the downloaded file in his computer.
On Mon, Mar 25, 2013 at 12:23 PM, Jim Giner
jim.gi...@albanyhandball.com wrote:
On 3/25/2013 10:13 AM, Samuel Lopes Grigolato wrote:
Have you tried to set a Content-Disposition header in the PHP script that
creates the PDF, asking the browser to attach the download? This way you
don't even need a new window.
Example from php.net/manual:
// It will be called downloaded.pdf
header('Content-Disposition: attachment; filename=downloaded.pdf');
On Mon, Mar 25, 2013 at 11:01 AM, Jim Giner
jim.gi...@albanyhandball.comwrote:
target as in the form attribute
In my appl devl I utilize an extra window when my current form is asked
to
generate a pdf report. Works well since that way the user can generate
one
report into a new window, read it, close it, and still have the reports
menu in front of him/her and generate a 2nd report.
I'm experiencing a problem tho and I'm guessing it's associated with ie9
or FPDF. In my reports menu form, when I click on a button that will
generate a pdf, I alter the form's target to create a new window. This
used to work last fall, but since then I have a new laptop running ie9,
not
8. The target changing js logic is working as far as I can see (alerts
in
my js) but the effect is not there. Instead of a new window, the pdf
opens
up in the same window where the menu was and so when the user does a back
he ends up going up one too many levels and has to re-request the reports
menu.
Didn't have this much trouble originally setting this up as I'm having
now
trying to debug this. I'm using the FPDF extension/class to generate my
pdfs - made no recent changes there. Also my concept works very well
still
in a simple html document that has only two buttons on it which I created
today to test a theory. That is - maybe it's not just IE9, but FPDF.
Anyone have any experience in this area?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
And what happens to my original menu window?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On 3/25/2013 1:12 PM, Samuel Lopes Grigolato wrote:
With the header Content-Disposition: attachment the browser will
offer the response as a regular file download (with save/open
options). Your original page (menu) will remain intact.
Please note that this solution will not present the PDF directly to
the user (as it would with a popup window), instead he will need to
open the downloaded file in his computer.
On Mon, Mar 25, 2013 at 12:23 PM, Jim Giner
jim.gi...@albanyhandball.com wrote:
On 3/25/2013 10:13 AM, Samuel Lopes Grigolato wrote:
Have you tried to set a Content-Disposition header in the PHP script that
creates the PDF, asking the browser to attach the download? This way you
don't even need a new window.
Example from php.net/manual:
// It will be called downloaded.pdf
header('Content-Disposition: attachment; filename=downloaded.pdf');
On Mon, Mar 25, 2013 at 11:01 AM, Jim Giner
jim.gi...@albanyhandball.comwrote:
target as in the form attribute
In my appl devl I utilize an extra window when my current form is asked
to
generate a pdf report. Works well since that way the user can generate
one
report into a new window, read it, close it, and still have the reports
menu in front of him/her and generate a 2nd report.
I'm experiencing a problem tho and I'm guessing it's associated with ie9
or FPDF. In my reports menu form, when I click on a button that will
generate a pdf, I alter the form's target to create a new window. This
used to work last fall, but since then I have a new laptop running ie9,
not
8. The target changing js logic is working as far as I can see (alerts
in
my js) but the effect is not there. Instead of a new window, the pdf
opens
up in the same window where the menu was and so when the user does a back
he ends up going up one too many levels and has to re-request the reports
menu.
Didn't have this much trouble originally setting this up as I'm having
now
trying to debug this. I'm using the FPDF extension/class to generate my
pdfs - made no recent changes there. Also my concept works very well
still
in a simple html document that has only two buttons on it which I created
today to test a theory. That is - maybe it's not just IE9, but FPDF.
Anyone have any experience in this area?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
And what happens to my original menu window?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Thanks for the pointer - but not what I'm looking to do. Trying to make
it effortless for the user so having to go and open a pdf would be
another pia.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
Jim Giner wrote: Thanks for the pointer - but not what I'm looking to do. Trying to make it effortless for the user so having to go and open a pdf would be another pia. Actually it IS worth pointing out that how the browser handles a pdf file is very much controlled by the browser itself? Opening in a browser page only works if there is a suitable plugin, so what *I* get is the option to save file or open in a third party app as I don't currently have any plugins loaded for pdf. We use pdf's for agendas and minutes, but I have yet to find a reliable way to display them as a pop-up or opening in a separate page even using 'target'. The compromise I came up with is to open them in a flash player as in http://northwaypc.org.uk/fisheye/image/1030 -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] target question
On Mon, Mar 25, 2013 at 7:11 PM, Lester Caine les...@lsces.co.uk wrote: Jim Giner wrote: Thanks for the pointer - but not what I'm looking to do. Trying to make it effortless for the user so having to go and open a pdf would be another pia. Actually it IS worth pointing out that how the browser handles a pdf file is very much controlled by the browser itself? Opening in a browser page only works if there is a suitable plugin, so what *I* get is the option to save file or open in a third party app as I don't currently have any plugins loaded for pdf. We use pdf's for agendas and minutes, but I have yet to find a reliable way to display them as a pop-up or opening in a separate page even using 'target'. The compromise I came up with is to open them in a flash player as in http://northwaypc.org.uk/**fisheye/image/1030http://northwaypc.org.uk/fisheye/image/1030 Please, don't advise flash to anyone. It's outdated, and is not gonna be supported for a long time anymore. iOS never supported, and Android does also not support since Jelly Bean I think. I checked your solution, and on my 1920x1080 screen, it shows the pdf quite small. I can zoom, but the bounding box does not get bigger, which means I have scroll the page from left to right to view it. In a native solution it would show the PDF as wide as my screen is, which makes it normally readable. I don't see what the problem is with showing a pdf in a pop up or new tab/window, it should work just as any other. Can u perhaps show us a simple code that does not work? (under 50 lines of code, if possible). Regards, Matijn
Re: [PHP] target question
I agree with Matjin in this one, Flash is not a good solution in this case, in fact, Flash is not a good solution in a lot of cases lately, but handling PDFs in the browser can be tricky sometimes. I remember that some time ago I had to build a system that prints a PDF after it is loaded from the server, without any user interaction, and there is no way to do that using only HTML/JS due to security restrictions of course. The solution I came up with was to create a java printer application that also open a local (tiny) http server, and the browser call this java application (ajax) sending the URL of the PDF, the java application downloads the document and prints it directly. The only downside is that the user need to open this printer application. Best regards. Att. Gabriel Ricci Website http://gabrielricci.github.com Follow @gabrielricci http://www.twitter.com/gabrielricci Facebook profile http://www.facebook.com/gabrielricci2, GitHub profilehttp://www.github.com/gabrielricci/ http://code.google.com/p/syslibjs/ On Mon, Mar 25, 2013 at 3:25 PM, Matijn Woudt tijn...@gmail.com wrote: On Mon, Mar 25, 2013 at 7:11 PM, Lester Caine les...@lsces.co.uk wrote: Jim Giner wrote: Thanks for the pointer - but not what I'm looking to do. Trying to make it effortless for the user so having to go and open a pdf would be another pia. Actually it IS worth pointing out that how the browser handles a pdf file is very much controlled by the browser itself? Opening in a browser page only works if there is a suitable plugin, so what *I* get is the option to save file or open in a third party app as I don't currently have any plugins loaded for pdf. We use pdf's for agendas and minutes, but I have yet to find a reliable way to display them as a pop-up or opening in a separate page even using 'target'. The compromise I came up with is to open them in a flash player as in http://northwaypc.org.uk/**fisheye/image/1030 http://northwaypc.org.uk/fisheye/image/1030 Please, don't advise flash to anyone. It's outdated, and is not gonna be supported for a long time anymore. iOS never supported, and Android does also not support since Jelly Bean I think. I checked your solution, and on my 1920x1080 screen, it shows the pdf quite small. I can zoom, but the bounding box does not get bigger, which means I have scroll the page from left to right to view it. In a native solution it would show the PDF as wide as my screen is, which makes it normally readable. I don't see what the problem is with showing a pdf in a pop up or new tab/window, it should work just as any other. Can u perhaps show us a simple code that does not work? (under 50 lines of code, if possible). Regards, Matijn
Re: [PHP] target question
Matijn Woudt wrote: I don't see what the problem is with showing a pdf in a pop up or new tab/window, it should work just as any other. Can u perhaps show us a simple code that does not work? (under 50 lines of code, if possible). There is no problem getting it to appear as a pop-up or in a new tab. The problem is that you have no idea exactly how the browser IS displaying it to a user. I quite agree that flash now needs replacing but 5 years ago it was a workable solution. Replacing that with another viewer would be nice nowadays,but there is nothing suitable? The point here was to allow the pdf to be wrapped with other links, and managing selection of things such as filtering terms for a report which is then output as a pdf makes sense. The report can also be printed if required, something which is not practical directly from an html page. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
