Problem printing popup pages.

G

gb

Hi All,

Ive created a popup page using 'var openWindow = window.open("new","pop")'

And added content using openWindow.document.write(" "); statements. But now
I would like to be able to print this page?

openWindow.document.write("<a href='#'
onClick='self.close()'>Close<\/a><\/p>")

This closes the page but these lines below only print the parent page not
the popup child window.

openWindow.document.write("<a href='#'
onClick='self.print()'>Print<\/a><\/p>")
openWindow.document.write("<a href='#'
onClick='window.print()'>Print<\/a><\/p>")

Ive also been trying to write a function based on document.lastChild:

popupPrint()

var popUp = document.lastChild;
popUp.print();
}

But nothing works?

Any help appressiated i'm using IE5.5 if this has an effect?

Regards

gb
 
F

Fabian

gb hu kiteb:
Hi All,

Ive created a popup page using 'var openWindow =
window.open("new","pop")'

And added content using openWindow.document.write(" "); statements.
But now I would like to be able to print this page?

Why do you even assume that the machine viewing your web page has a
printer attached?
 
L

Lee Mundie

Hmmm, didn't think that was fair... 3 x three worded reasons:

User enhanced experience
Useability and accessibility
Human Centered Interfaces...

Should always assume that a person has peripherals attached and design to
cover... a printer being the most basic and common.

Regards

Lee
 
F

Fabian

Lee Mundie hu kiteb:
Hmmm, didn't think that was fair... 3 x three worded reasons:

User enhanced experience
Useability and accessibility
Human Centered Interfaces...

Should always assume that a person has peripherals attached and
design to cover... a printer being the most basic and common.

If someone has a printer, chances are they are able to print from the
web browser just fine using the normal browser interface. Why reinvent
something that already exists?

And if the browser was such that printing was not possible even assuming
a printer is attached, then surely javascript would also fail as a
solution?

I suppose the point is that you want to be able to print this window
while still having the usual window interface hidden. This is one of the
big reasons popup windows are hated - the interface is often hidden. But
there is still control-P, or the best solution - no popups, or, if you
must have popups, don't hide the interface.
 
L

Lasse Reichstein Nielsen

Please don't top post.
<a href="javascript:eek:nClick=window.print()">print</a> should work.

The "onClick=" is not needed, and in fact does nothing except create
a new global variable.

You should not use javascript:-URLs. I recommend using a button
<input type="button" value="Print!" onclick="window.print()">
If you insist on using a link, give it a meaningful href, but use
the onclick handler for Javascript:
<a href="YouNeedJavascript.html" onclick="window.print();return false;">
Print!</a>

(in "YouNeedJavascript.html" you explain why your page only works well
with Javascript enabled).

Even if you write the a-element with Javascript, you should use the
onclick attribute. It doesn't have the potential, often unexpected,
side effects of javascript:-URLs (like clearing the page if the
Javascript expression doesn't evaluate to undefined).

/L
 
M

Michael Winter

Lee Mundie wrote on 22 Nov 2003:
Hmmm, didn't think that was fair... 3 x three worded reasons:

User enhanced experience
Useability and accessibility
Human Centered Interfaces...

Should always assume that a person has peripherals attached and
design to cover... a printer being the most basic and common.

But in this case, you don't need to cover such a need. If a user
wants to print a page, they can use their browser's 'Print' command.
That's what it's there for and what I look for - not whether the
author was "kind" enough to provide a button or link.

Mike

And don't top post.
 
D

DU

Michael said:
Lee Mundie wrote on 22 Nov 2003:




But in this case, you don't need to cover such a need. If a user
wants to print a page, they can use their browser's 'Print' command.
That's what it's there for and what I look for - not whether the
author was "kind" enough to provide a button or link.

Mike

And don't top post.

I agree with the above. Nevertheless, there could be several reasons to
create a custom stylesheet for printing.

1- remove webpage background color
2- display url values (hypertext links) and not text of links in the
printed form
3- control page break
4- control font size

So far, no one in this thread mentioned that.

CSS Design: Going to Print
http://www.alistapart.com/articles/goingtoprint/

DU
 
D

DU

Fabian said:
Lee Mundie hu kiteb:




If someone has a printer, chances are they are able to print from the
web browser just fine using the normal browser interface. Why reinvent
something that already exists?

Printer friendly version of a document or a document selection might be
a reason to create a custom stylesheet for printing though.
And if the browser was such that printing was not possible even assuming
a printer is attached, then surely javascript would also fail as a
solution?

I suppose the point is that you want to be able to print this window
while still having the usual window interface hidden. This is one of the
big reasons popup windows are hated - the interface is often hidden. But
there is still control-P, or the best solution - no popups, or, if you
must have popups, don't hide the interface.

Printing a selection of a document can be difficult or not working
(e.g.: Opera 7.x). Highlighting abs. positioned elements in MSIE 6 for
windows is difficult, e.g. a column in a 3 column webpage document.

I agree overall with what you say. I just see a few precise, specific
instances where printing from a requested popup might be needed or might
be a responsible webdesign decision.

DU
 
L

Lasse Reichstein Nielsen

DU said:
Michael Winter wrote: .... ....
I agree with the above. Nevertheless, there could be several reasons
to create a custom stylesheet for printing.

Sure, but that doesn't require a new print button. Just add the
stylesheet with media="print", and it is only used for printing.

/L
 
F

Fabian

DU hu kiteb:

I agree with the above. Nevertheless, there could be several reasons
to create a custom stylesheet for printing.

1- remove webpage background color

I think all the major web browsers, those that are able to display
backgrounds anyway, include a built in option to strip background
colours when printing.
2- display url values (hypertext links) and not text of links in the
printed form

I wasn't aware stylesheets alone could do this.
3- control page break
4- control font size

Since you have no way of knowing what paper size they are using, or how
good the guy's eyesight is, forcing page breaks or font size is a VERY
bad idea.
 
D

Dr John Stockton

JRS: In article <[email protected]>,
seen in Lee Mundie
<[email protected]> posted at Sat, 22 Nov 2003 22:40:38 :-

If you read the newsgroup FAQ, you can find out how responses should be
formatted; if you heed this, people will not feel the need to write
"Please don't top-post", "Please don't over-quote", etc.; and will be
more likely to answer what you want.
Hmmm, didn't think that was fair... 3 x three worded reasons:

User enhanced experience
Useability and accessibility
Human Centered Interfaces...

Should always assume that a person has peripherals attached and design to
cover... a printer being the most basic and common.

If you are dealing with a Company Intranet, you may be entitled to
assume that the material *must* be printed, and that a printer *will* be
connected. Even then, will it necessarily have the right sort of paper?

I have a printer connected, but not turned on; and I would not want you
to be able to choose to waste my ink and paper.

Printing without explicit user assent from a Web page should be
impossible.
 
D

DU

Fabian said:
DU hu kiteb:





I think all the major web browsers, those that are able to display
backgrounds anyway, include a built in option to strip background
colours when printing.

Correct.



I wasn't aware stylesheets alone could do this.

a:link:after { content: " (" attr(href) ") "; }
Since you have no way of knowing what paper size they are using, or how
good the guy's eyesight is, forcing page breaks or font size is a VERY
bad idea.

For font size, you may be right. The user can still override the
author's suggested font-size value with the browsers' page setup (Print
preview in MSIE 6) printing options. I checked NS 7.1, Mozilla 1.5, MSIE
6 for windows and Opera 7.23 and they all allow users to scale the font
size in %percentage of the author's font-size. I did not test this though.

Regarding page break, I was thinking about all the page media style
properties. These are quite useful. Let's say you have a big table (or a
big element like an image) and you do not want it to be broken on 2
pages: then page-break-before is useful. Currently, Opera 7.x, NS 7.x
and Mozilla 1.3+ support page-break-before.

http://www.westciv.com/style_master/academy/browser_support/printing.html

Such style sheet is still an author stylesheet. Users can still control
a few properties via page setup or print preview dialog boxes. I must
say I need to test all this.

I think everyone who replied that there was no need for javascript to
print a page was correct. I just think it was more according to the
spirit of usability to suggest to the original poster to work on
creating a custom stylesheet for printing.

DU
 
F

Fabian

DU hu kiteb:
a:link:after { content: " (" attr(href) ") "; }

I just tested this; it doesn't appear to work, or does it only have the
expected effect when printing to a printer, and not to a screen? Where
is the reference for this? I agree this would be VERY useful if it
consistently worked across environments.
 
D

DU

Fabian said:
DU hu kiteb:




I just tested this; it doesn't appear to work, or does it only have the
expected effect when printing to a printer, and not to a screen?

You should see the link values in the print preview window.

Where
is the reference for this?

See
http://www.alistapart.com/articles/goingtoprint/

I agree this would be VERY useful if it
consistently worked across environments.


The following documents are valid, validated, tested (printed) and
working for Mozilla 1.5, K-meleon 0.8 (build 844), NS 7.1, Opera 7.23.
Opera 7.23 had the best printed rendering (no extra blank spaces like
Mozilla does). MSIE 6 for windows did not render the link values at all.

DU

----------------------

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html lang="en-us">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Style-Type" content="text/css">
<meta http-equiv="Content-Script-Type" content="text/javascript">

<title>Testing custom print stylesheet</title>

<link rel="stylesheet" type="text/css" href="print.css" media="print">

</head>

<body>

<p>A few sites to visit:</p>

<ul>
<li><a href="http://www.lajzar.co.uk">Fabian's site</a></li>
<li><a
href="http://www.westciv.com/style_master/academy/browser_support/printing.html">Browser
support for CSS2 properties in media print</a></li>
<li><a href="http://www.alistapart.com/articles/goingtoprint/">CSS
Design: Going to Print</a></li>
<li><a href="http://validator.w3.org/">W3C HTML validation</a></li>
<li><a href="http://checkie.orange-soft.com/index.htm">Multi-validator
plug-in for MSIE (Spanish)</a></li>
</ul>

</body></html>



print.css
 
L

Lasse Reichstein Nielsen

Fabian said:
DU hu kiteb:


I just tested this; it doesn't appear to work, or does it only have the
expected effect when printing to a printer, and not to a screen?

The part you quoted can work at any time. If it is wrapped in a
@media print { ...}
or included with
<link rel="stylesheet" media="print" ...>
then it only affects the printed media.

That line alone only puts content after unvisited links. Add an
a:visited:after selector to also match visited links.
Where is the reference for this?
<URL:http://www.w3.org/TR/CSS2/generate.html#before-after-content>
I agree this would be VERY useful if it consistently worked across
environments.

It's CSS 2, so most likely, IE doesn't support it. Modern browsers
do. After all, CSS 2 has been a recommendation since May 1998.

/L
 
G

gb

From: "Lee Mundie" <[email protected]>
Newsgroups: comp.lang.javascript
Sent: Saturday, November 22, 2003 10:22 PM
Subject: Re: Problem printing popup pages.

<a href="javascript:eek:nClick=window.print()">print</a> should work.
Regards
Lee

Lee,

Problem is that it does'ent. This prints the original page not the popup
page. Even though this has been included in the new window using
document.write(). Is this a browser issue?

Giles

"
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top