Re: Printer friendly pages

>>> I tested it under both Linux and Windoze, with Firefox 2, Opera 9 and
>>> IE7:
>>> it plain does not work with Javascript enabled: it opens an empty tab,
>>> and when opening the error console, it says that it did not find
>>> PrintThis(): I
>>> did not investigate, but I think the problem is that default.css is
>>> not loaded into the new tab/window when the javascript:printThis()
>>> link is clicked. In any case, it doesn't work as it is in the SVN
>>> right now.
>>
>> Yes, I can reproduce this. I must have broken it somewhere when I
>> implemented the non-javascript version, I'll investigate.
>>
>>> But now my question is: how a plugin is supposed to change the layout
>>> of the message before it is printed. I.e. what if you don't want the
>>> printed message to look exactly in the same way it is displayed (what
>>> if you want less header fields, for example ?...) ?
>>
>>> I vote strongly against this change, and kindly request to have it
>>> reverted.
>>
>> I genuinely think that would be a step in the wrong direction. This is
>> not "just another way to do it", it fully alligns with the goal of
>> separating code (what it does) and display (how it looks). Printer
>> friendly is definately just a means of presentation, not logic.
>
> That's not entirely true.  It is logical to me to say that you want
> the printed version to strip certain elements.  That's the whole point of
> having a printer friendly version in the first place - to make it more
> friendly to the eye when printed.  If some admins don't want tons of
> headers listed at the top of the printout, they are probably servicing the
> kind of end user who has no idea what headers mean nor should *have to*!
> They just want to see the From, Date and Body.  I
> just had a request the other day from someone to remove the oddly
> formatted attachments graph from the printer friendly page.  I think what
> Thierry is stating makes a lot of sense.

Wouldn't most persons expect a printed version of a page expect it to be
as close to the original as possible content-wise? I haven't looked at the
code of the page, but isn't it possible to allow configuration and/or
plugins to change what's shown when printing? If we don't have that we
should most likely add it - it would be useful for the standard page as
well. There's already a flag to indicate if the page is in printer mode or
not, and plugins should be able use that if they need to detect the mode.

>> CSS is the way to go
>> here, as it is when developing e.g. a mobile phone equivalent or one for
>>  people with bad eye sight.
>>
>> I understand your concerns, but I think the right solution is to find a
>> way to embed them within this framework rather than reverting it.
>>
>> If you want to display some fields differently or not at all, css is
>> your friend and will actually make it easier to do that, rather than to
>> hack away at the old printer friendly code. In fact, you can completely
>> revamp the print.css stylesheet so that printer friendly looks exactly
>> the way you want it to be, without intermingling with core code.
>
> Seems like that could be OK, as long as you have a large number of
> detailed class names so you can control the display of not just headers,
> but _certain_ headers as well as all the other page contents and elements.
> OTOH, this kind of request will be common enough that
> it should be achievable without the answer always being to just point
> newbie admins to the css file and hope they know how to change it.  I
> think it should be configurable, at the least in a plugin.  I haven't
> looked at the code, but it seems to me that if another page request *is*
> involved in getting the printer friendly page, then all we'd need to do is
> add a GET argument to the URI that flagged the page request as that for
> being printer friendly so a plugin could poke its nose into the code where
> headers are retrieved, etc.  That last part may need some work in terms of
> making the header and other elements customizable by pluigns.

We shouldn't remove functionality, so if we need it we should add it to
the current solution rather than split it up in two pages.

>> If you don't want to edit print.css but want all code to be confined to
>> your plugin purely, it is possible to add a custom css to the page
>> header with your media=print definitions.
>
> You mean hook into something like generic_header and add a css page?
> What if the SM one is loaded as well, who wins?

The one loaded last - that's why they call it "cascading".

> The plugin would
> ideally have to create the css file *on the fly* based on the plugin
> configuration.  This defeats css caching and could create a problem in
> that sense, if creating it on the fly is even possible.

Wouldn't a CSS created on the fly (and I'm not even sure it has to be done
like that) be just as possible to cache? The same formatting rules are
likely to apply to all printed pages (unless the end-user re-configures
and prints again, but that's not likely to happen between every
print-out).

>> If the current template set doesn't have the right css classes to fully
>> express what you want, we can of course see if that can be changed, I
>> don't expect much problems there.
>>
>> All in all, I believe that this is a great improvement, maybe even more
>> for custom print friendlies rather than less.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel