Open Bug 104618 Opened 23 years ago Updated 2 years ago

Printing should automatically use printer friendly alternate version (LINK)

Categories

(Core :: Printing: Output, enhancement)

Product:
Core
Component:
Printing: Output
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: tim, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

Dynamically changes the page actually printet using rel=alternate
833 bytes, text/html
Details 
The LINK element allows authors to specify alternate versions of the document. 
Of those alternates, some can be interpretted as being a printer friendly
versions.  Specifically if a page contains a link of the form:

<link rel="Alternate" media="Print" href="print.html" />
The referenced page can be interpretted as a printer friendly version of the
current page.  Mozilla should use this page for printing.  The UI needs to allow
the user to print the original page if they choose.  One way to accomplish this
would be to add a checkbox labeled "use Printer Friendly version" which would be
checked by default.  If no printer friendly version is available, the checkbox
and label would be disabled.

Also, if the LINK element contains an HREFLANG attribute, the language must
match the language of the current page.  So, for example, if we're browsing a
page in US English and it contains the following LINKs, we would use the second
LINK as the printer friendly version:

<link rel="Alternate" media="Print" hreflang="fr" 
    href="print.fr.html" />
<link rel="Alternate" media="Print" hreflang="en-US"
    href="print.html" />

If the LINK contains a TYPE attribute that we know is unsupported then we should
ignore that LINK and continue scanning other LINKs.  For instance:

<link rel="Alternate media="Print"
    type="application/ms-proprietary-printer-format" href="print.msppf" />

If no TYPE attribute is provided and mozilla requests the printer friendly
document, only to discover that the document is an unsupported type, then
Mozilla should automatically fall back to printing the original document.

In some cases, the printer friendly document may be a PostScript or PCL file
that can be sent directly to the printer.  In this case, Mozilla should bypass
it's own print engine and spool this file directly to the printer.  I'm
completely guessing how the internals of printing work, so please correct me if
this is not possible.
Blocks: 103053, 104586
Status: UNCONFIRMED → NEW
Ever confirmed: true
Should this also work for a link like this to a printer version:

 <a rel="alternate" media="print" type="text/html"
  href="print.html"
  title="Printer formated version of this page.">Printer Friendly</a>

ie. a rel attribute on a <a> element in the body in addition to working for
<link> elements in the head?
> <a rel="alternate" media="print" type="text/html"
>  href="print.html"
>  title="Printer formated version of this page.">Printer Friendly</a>

Probably no.

However, it was hotly debated whether to recognize REL attributes on A elements
in bug 87428.  I eventually disabled it because of performance reasons.  With
some fixes to the link toolbar that should improve performance (bug 102992) this
reason may become moot.

I thought there was an enhancement to check REL attributes on A elements when
building the link toolbar, but I can't find it.  One should be created if it
doesn't exist.  Then we can debate the issue in that bug instead of here. 
Whatever decision applies to the link toolbar should apply to this bug.
I think this is a dup. It's not related to the Links Bar; removing dependency.

Note that this behavior must be overridable, to guard against the case where 
annoying authors specify <link rel="alternate" media="print"
href="you-cant-copy-this-page-so-nyah-nyah-nyah.txt" />.
No longer blocks: 103053
Whiteboard: DUPEME
> It's not related to the Links Bar; removing dependency.

It is related, because "printer friendly" alternates will need to be omitted
from the Links Bar, just as stylesheets are now.  Restoring dependency.

> Note that this behavior must be overridable
...

Agreed.
Blocks: 103053
Target Milestone: --- → Future
if you go to http://gemal.dk/test/print.html and press Print or Print Preview
the page that should be printed/shown is http://gemal.dk/test/print.html?print=1

The pages are the same the print=1 is just added for testing.

is this really future? Also the preview stuff? Getting the URL specified in the
link media print url for print preview couldn't be soo hard ...?
URL: http://gemal.dk/test/print.html
to Rods to look at these issues
Assignee: dcone → rods
Note that printing prints the DOM, not a url.  So this will require architecture
work and such (fetching data from a URL, parsing into a DOM, printing the DOM,
but only in some cases).

I would say this is lower-priority for 1.0 than, say, getting print preview to
be usable.
Removing "Dupeme" from status whiteboard.
Whiteboard: DUPEME
This feature has been included in IE since version 4 (i think, it is definatly
in version 6). It is not supported in Netscape 4.

Relevant standards are at
http://www.w3.org/TR/html4/present/styles.html#adef-media (it is worth scrolling
up as well as down, but that is a good place to start).
Ian, stylesheet media have nothing to do with this bug.  Mozilla supports
stylesheet media. This bug is a request to get the resource pointed to by a
<link rel="alternate" media="print"> tag and print it when a page is printed. 
Nowhere do stylesheets enter that picture.
Sorry, I gave you the wrong url.

http://www.w3.org/TR/html4/types.html#type-media-descriptors
(my point was that this is in the standards, unlike a lot of LINK which is vague
in the standards).

But it does raise the question of what to do with a tag like:
<link rel="alternate stylesheet" media="print">

I couldn't see any reference to this in the standards, but it would seem
sensible to print the current document with this stylesheet if no suitable
printer friendly versions were found in other link tags.
It was suggested that this functionality could be overridden by the user.  Good
point.

Where I work, we offer PDFs of many documents and it would be really nice to
have those PDFs automatically *suggested* as the preferred printable alternative
when available.  However, they should not be forced on the user.  There must be
a way for the user to easily refuse this because not everyone wants a PDF (or
whatever format a given web site wants to suggest).  The auto-print function
would need a mechanism to degrade gracefully.

Perhaps some kind of confirm dialogue could be used to notify the user that we
are downloading a new page for printing?  Or if the download is rapid, maybe
just a visible notification on the print preview that this is a document other
than teh original HTML page.  On another level, maybe users can  specify in
their preferences which file formats they accept and refuse as auto-printable,
to reduce the number of confirm dialogues.

Just some thoughts...
All/all.
Blocks: 125824
OS: other → All
Shows an example on changing the page actually printet.
Works in IE6 on XP, should work in Mozilla too, but does not
*** Bug 234869 has been marked as a duplicate of this bug. ***
I'd suggest adding a checkbox "Use alternate document for printing" to the print
dialog, which is disabled when no such <link> is present, and checked as default
when such a link is present.

If the alternate document is text/html or whatever other type mozilla can
handle, the user has the normal options like preview etc.. 

If mozilla does not know what to do with such a file, all options but save to
file or send to printer are disabled. The user can then save the file and print
it with the appropriate application (maybe mozilla could also suggest executing
this application for the user) or the user's print subsystem has to care about
the type of file.
dup of Bug 51848 ?
Suggest following changes to this bug:

- It is *not* related to: 103053 or 104586 (Link toolbar).

- Consider that the priority of this bug may have increased as the use of dynamic content (both on the server and on the client) has become much more widespread.  Merely changing CSS for print media is often not enough and whole alternate versions of the pages or forms must be loaded instead when a user selects File=>Print.  This capability has also been in the W3C standards for some time now.
Assignee: rods → nobody
QA Contact: sujay → printing
I do not believe this bug should be fixed. When the user clicks "print", I believe they expect to print roughly the content that is currently in their browser, not some other content which could potentially be radically different. We (and all other modern browsers) already allow for different styling of print via @media CSS selectors.

Adding a checkbox to the print dialog is both difficult to do cross-platform and just asks the user to make a decision without the necessary context.

Recommend WONTFIX.
HTML4 says that the media attribute applies only to style sheets:
# This attribute specifies the intended destination medium for style information.
# It may be a single media descriptor or a comma-separated list. The default
# value for this attribute is "screen".
  --http://www.w3.org/TR/html4/present/styles.html#adef-media

Current HTML5 draft says:
# The media  attribute says which media the resource applies to. The value
# must be a valid media query. [MQ]
#
# If the link is a hyperlink then the media attribute is purely advisory, and
# describes for which media the document in question was designed.
#
# However, if the link is an external resource link, then the media attribute is
# prescriptive. The user agent must apply the external resource to views while
# their state match the listed media and the other relevant conditions apply,
# and must not apply them otherwise.
  --http://www.w3.org/TR/html5/semantics.html#attr-link-media

So this feature request isn't even backed by any specifications.
From the spec

# Link Types
# Alternative
# Designates substitute versions for the document in which the link occurs.
# When used together with the lang attribute, it implies a translated version 
# of the document. When used together with the media attribute, it implies 
# a version designed for a different medium (or media).
http://www.w3.org/TR/html4/types.html#type-links
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: