No style for print and projection media types

[DisabledLeopard]

While the print action is good - its very useful to be able to just print a page.

Modern / Modernised etc themes add link rel=stylesheet media=print href=moin_static...print.css this is not added for Solenoid but would be a fantastic inclusion (imho)

[Chris Croome (chriscroome)]

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?

[Tim-tool-man (tim-tool-man)]

> <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.

[Matthew Paul Thomas (mpt)]

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" />.

[Tim-tool-man (tim-tool-man)]

> 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.

[Bugzilla-gemal (bugzilla-gemal)]

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 ...?

[Dcone (dcone)]

to Rods to look at these issues

[Bzbarsky (bzbarsky)]

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.

[R-contact2009-awhlink-com (r-contact2009-awhlink-com)]

Removing "Dupeme" from status whiteboard.

[Ian-ithomas (ian-ithomas)]

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).

[Bzbarsky (bzbarsky)]

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.

[Ian-ithomas (ian-ithomas)]

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.

[Harvested-from-mozilla4 (harvested-from-mozilla4)]

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...

[R-contact2009-awhlink-com (r-contact2009-awhlink-com)]

All/all.

[Michel-irt (michel-irt)]

Created an attachment (id=123120)
Dynamically changes the page actually printet using rel=alternate

Shows an example on changing the page actually printet.
Works in IE6 on XP, should work in Mozilla too, but does not

[SteBo (stebo)]

*** Bug 234869 has been marked as a duplicate of this bug. ***

[Jochen Eisinger (jochen-penguin-breeder)]

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.

[Benjamin-mucci (benjamin-mucci)]

dup of Bug 51848 ?

[Philip-hachey-yahoo (philip-hachey-yahoo)]

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.

[DisabledLeopard (disabledleopard)]

While the print action is good - its very useful to be able to just print a page.

Modern / Modernised etc themes add link rel=stylesheet media=print href=moin_static...print.css this is not added for Solenoid but would be a fantastic inclusion (imho)

[Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs)]

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.

[L. David Baron (dbaron)]

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.

[DisabledLeopard (disabledleopard)]

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

[Display Name (user340562791542-deactivatedaccount)]

Why?

[DisabledLeopard (disabledleopard)]

why: so that users don't have to explicitly use the print action for printing a page, they can just print from what they're looking at - frustratingly the extra step is enough to cause issues for the user base I support.

[Display Name (user340562791542-deactivatedaccount)]

In IE7/8, the following line sent by Moin for all themes makes the print action be called automatically:

<link rel="Alternate" media="print" title="Visualizar Impressão" href="/MoinMoinBugs/MinusSignAsSearchTerm?action=print">

I have no idea why, but this doesn't work in Firefox. What are your browsers and theme version?

[Display Name (user340562791542-deactivatedaccount)]

Well, it doesn't work because nobody made it work: https://bugzilla.mozilla.org/show_bug.cgi?id=104618. I'm inclined to accept your request, but it would be nice if there was still a way to print the site as displayed in the screen.

[Display Name (user340562791542-deactivatedaccount)]

Leopard, can you please check if other browsers support this feature? I have tested IE7/8 and FF as I said, but I would like to know about Safari, Opera 9/10, Chrome 3/4, Konqueror etc. Thanks!

[DisabledLeopard (disabledleopard)]

bah to browser quirks - I'm using mostly firefox, everything from 2.0.0.11 - 3.7a.

Firefox does a good job of butchering up the displayed theme for printing anyway so for Firefox the print.css really is the only good options.

By butchering up, when I print/preview any doc the first page has the page header down to the link trail then blank, second page content starts rendering nicely - for a single page doc this is good - for long docs they get cut off at a fixed point at the top of the 3rd page.

[DisabledLeopard (disabledleopard)]

I'm only printing to PDF for these tests.

On Linux (Fedora 11)
Chrome 4: Doesn't appear to use Alternate - but does print from screen perfectly.
Opera 10: appears to do the same as Chrome, but also fills the last page with the dark background colour.
Konqueror 4.3.3: tried to print visible but didn't print the whole doc (missed that last 1/5th or so) and omitted all images and the header.
arora 0.10.2: basically same as Chrome, some more background colour / images

I can test on Mac when I get home from work.

[Display Name (user340562791542-deactivatedaccount)]

Browsers using the alternate link will call ThePage?action=print which will send print.css to remove the header (logo, gotobar, editbar, page trail etc), footer, the sidebar, and the background. One simple way to check the browsers is having a sidebar: it should not be displayed in direct print view (without manually calling action=print), otherwise it means the browser is not applying the alternate link.

About Chrome 4: if it prints from screen perfectly, then why would it not be using the alternate? As far as I could understand, all these browsers are ignoring the alternate <link>, but please do the sidebar check to confirm.

[DisabledLeopard (disabledleopard)]

Chrome prints the SideBar. I just re-checked, Chrome's output isn't quite perfect either, it prints via the gnome printing system (same as firefox) but doesn't yet have options to print any background images or colours (though the background of the select list in the header is printed), I'm assuming those options are coming soon. But yeah looks like so far only IE is respecting the Alternate link.

[DisabledLeopard (disabledleopard)]

Mac OS X, tested Safari, Chrome & Firefox, none use alternate link for print.

[Display Name (user340562791542-deactivatedaccount)]

BTW, is the theme looking like this in Konqueror? http://launchpadlibrarian.net/34740924/Problem.png. More details in bug 464156.

[DisabledLeopard (disabledleopard)]

Yes, that overflow is still happening to konq.

[Display Name (user340562791542-deactivatedaccount)]

We need a patch :(

[Display Name (user340562791542-deactivatedaccount)]

Can you test this fix?

https://code.launchpad.net/~renatosilva/moin-solenoid/style-for-other-media

[Display Name (user340562791542-deactivatedaccount)]

Please see the linked branch for an updated url.

[Display Name (user340562791542-deactivatedaccount)]

I have tested the linked fix. The problem is that current print.css and projection.css are prepared to the output of action=print only, which unexpectedly is different from default action=show. Thus the look of media=projection (tested in Opera) and media=print are not totally ok: adaption to action=show is required. Such adaption may just make it look ok, or also make it look the same as print=action, which is harder, because you need to keep both looks in sync.

[DisabledLeopard (disabledleopard)]

I've [finally] had a chance to have a bit of a test. The changes you've made work well. I can totally understand the fine line you're wanting to tread between maximizing screen features with other media types when different browsers do things differently.

Firefox, Chrome, Safari and Opera are all playing nice for printing for me with some subtle differences between them all but its good - no header and all the content is rendered nicely for printing. Firefox and Opera both print like the sidebar is still occupying the left of the page so there's some extra white margin on the left. Chrome & Safari are both preserving the width of the body (as I see on screen anyway with boxed display) but the margins space it nicely - just leave rather wide left and right margins.

Thanks for the change - for quick / easy CTRL+P it's going to save me time!

I'm happy to test more / assist in further tweaking if you've got areas that need work too.

[Display Name (user340562791542-deactivatedaccount)]

Thanks for your feedback. I tested with FF and the font is smaller than print action, and irrc there was a blank space left in place of sidebar. In opera, fullscreen mode activates media=projection, but I can see the page footer block.

Considering this and what you said, I don't think these changes are accurate enough for releasing, so if you want to use them, you need to use the linked branch. Fortunately, it's not that hard to keep up-to-date with upstream: rather than rewriting a patch, you just need to merge the upstream changes.

The work needed now is, like I said, adapt the stylesheets to action=show. No blank area should be left for sidebar, and no footer should be displayed in media=projection, and the font size is supposed to be the same, etc. If you are familiar with Bazaar and CSS, you could copy the linked branch and work on it to fix these issues :)

[Display Name (user340562791542-deactivatedaccount)]

s/irrc/iirc

[Display Name (user340562791542-deactivatedaccount)]

Hi, I think I have finished the fix, direct printing should look like action=print now. Can you test it, please?

If you can't use Bazaar, I can attach the development version containing the fix here.

[John-p-baker (john-p-baker)]

*** Bug 545944 has been marked as a duplicate of this bug. ***