Re: Printer friendly pages

On Tue, May 13, 2008 at 3:07 AM, Thijs Kinkhorst <[email protected]> wrote:
> On Tuesday 13 May 2008 11:30, Thierry Godefroy wrote:
>  > 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.

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

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

>  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