Re: Printer friendly pages

--- On Thu, 5/15/08, Fredrik Jervfors <[email protected]> wrote:

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

This might be desirable for normal emails, when you only have 4 or 5 header fields to deal with, but it is certainly not true any more with a Melinda formal message. And even in the standard email case, you will probably want to have the untouched headers in the window (where you can scroll quickly with the mouse wheel if you are not interested in them), and only simplified headers on the paper (where the room taken by the header matters a lot more).

Take the TO and CC fields (TO and INFO for Melinda), for example... In Melinda, they contain the name (which is standardized worldwide and in fact comes from the old ACP127 messaging system in use in the NATO) of the authorities followed with the corresponding email (which is local and could change from one year to another, should the said authority move, or even for the Navy, from one week to the other, when the authority is embarked or comes back ashore). On screen, you will want to see the full address (the email will tell you where a given authority is based, for example), but on the paper and for archiving purpose, you will only want the name of the authority.

This of course can be done with CSS, at the cost of more pre-processing in read_body.php, but it was just to give you an example how one can want to have messages look differently when printed.

Oh... also... About seeing evrything in the message once printed... What happens, i the current, CSS based printing code, when SQM abbreviated the To/Cc/Bcc fields (when there are a lot of adresses in them, SQM truncates the list and adds a "more" link to let you request the full list): With the old "Printer Friendly" method, all the emails were listed in the printed message. With the new method, you must click on each of the "more" links in the window before finally clicking on "Print". Else, you will have only the truncated fields printed... Not very user-friendly, IMHO...

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

Like I said, it is not as much about "how it will look" (even if it is an issue) than "what will be printed". Take the attachments issue: you could want to have the printable attachments to be automatically printed along with the message for example, which _was_ possible with the "Printer friendly" method and is no more possible with the direct printing method relying exclusively on CSS.

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

Not if Javascript is available... All you got is the "Print" link which directly triggers the printing by the browser. The reason why the "Printer friendly" method was better, is that it went through one intermediary step before printing (the preview pop up window).

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

Exactly.

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

That's indeed the way to go, as far as I am concerned. :-)

Keep the CSS for customizing the look (don't take me wrong: I'm all for generalized CSS use... where it makes sense), but do it from an intermediate (print preview) page, so to allow some PHP processing of the message data as well.

I must also add that about scalability and speed, the new solution is sub-optimal, as it involves more pre-processing by the plugins in read_body.php hooks (or more likely, it involves using custom templates, which in turn involves a custom read_body.php for the plugin, or would require adding an easy way for plugins to change the templates used by src/read_body.php) to allow the proper CSS style tags to be added around the elements you don't want to see printed...
Given you will print only a small proportion of the messages you will receive, this means that a lot of code will be executed uselessly, while with the "Printer Friendly" method, the code was only executed when you actually wanted to print a message

When I was serving onboard warships in operation it was not uncommon for me receive over 2000 messages a day, and I rarely printed more than 50 of them: multiply this number by the number of officers and senior petty officers on board the ship, and you will get the figure for the server load...

Best regards,

Thierry.


      


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