php-general Digest 26 Mar 2013 14:04:43 -0000 Issue 8174
Topics (messages 320675 through 320689):
Re: target question
320675 by: Samuel Lopes Grigolato
320676 by: Jim Giner
320677 by: Paul M Foster
320678 by: Ford, Mike
320679 by: Stuart Dallas
320680 by: Paul M Foster
320681 by: Samuel Lopes Grigolato
320682 by: Jim Giner
320683 by: Jim Giner
320684 by: Lester Caine
320685 by: Matijn Woudt
320686 by: Gabriel Ricci
320687 by: Lester Caine
320688 by: Tommy Pham
320689 by: Jim Giner
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
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.com>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?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
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.com>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?
--
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?
--- End Message ---
--- Begin Message ---
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="_blank">My 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
--- End Message ---
--- Begin Message ---
> -----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
--- End Message ---
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
On Mon, Mar 25, 2013 at 04:37:50PM +0000, 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
--- End Message ---
--- Begin Message ---
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.com>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?
>>>
>>> --
>>> 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
>
--- End Message ---
--- Begin Message ---
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.com>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?
--
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.
--- End Message ---
--- Begin Message ---
In light of the apparent lack of any solution, I have embarked on
changing all my report choices to use multiple forms with different
target attribs as needed. For many of them not a big deal, but for
several it adds a degree of difficulty since I have to copy the values
of any input fields into each separate form by using hidden fields and
js called by the form during 'onsubmit'. Works but would be nicer if
the simple changing of the target was more reliable.
Thanks for reading.
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
profile<http://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
>
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Mon, Mar 25, 2013 at 10:21 AM, Jim Giner
<jim.gi...@albanyhandball.com> wrote:
> In light of the apparent lack of any solution, I have embarked on changing
> all my report choices to use multiple forms with different target attribs as
> needed. For many of them not a big deal, but for several it adds a degree
> of difficulty since I have to copy the values of any input fields into each
> separate form by using hidden fields and js called by the form during
> 'onsubmit'. Works but would be nicer if the simple changing of the target
> was more reliable.
>
> Thanks for reading.
>
What about
onclick='window.open("http://domain.com/path/to/generated/pdf";, "_blank")'
?
Regards,
Tommy
--- End Message ---
--- Begin Message ---
On 3/25/2013 5:45 PM, Tommy Pham wrote:
What about
onclick='window.open("http://domain.com/path/to/generated/pdf";, "_blank")'
?
Regards,
Tommy
Appreciate the attempt to help, but as I posted earlier I went around
and modified all my scripts to handle my 'target' problem by introducing
multiple form tags into my pages. So - problem eradicated.
Took about 5 hours to change a whole bunch of them but now it's
completely safe and solid. Learned a bit of how to make JS copy my
input tag values into some hidden ones in my 'other' forms prior to
submit which I hadn't done before. All in all a learning exp. For
those who haven't done it a key feature was embedding an entire
<form><input type='submit'></form> into a <td> element of a <table> and
using the js 'this.form' identifier to facilitate copying my other input
tag values into the about-to-be-submitted form.
--- End Message ---
