Re: Printer friendly pages

On Wed, May 14, 2008 at 10:16 PM, Fredrik Jervfors
<[email protected]> 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.
>
>  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.

Nowhere was I suggesting otherwise.

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