• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

ALERT! Please see below for the current understanding of this issue....

Printable mode used to be accomplished by viewing using skin=print . Now suddenly it has to be done via template=viewprint . The consequence is that plugins which relied on the skin to, for example, skip its processing, will fail for the printable mode. To make things worse, a different appearance results when one uses skin=viewprint .

If somebody could motivate this change, it would be easier to appreciate. However, why do we need two ways of changing the appearance now (one with passing a template, one with using a skin)?


This discussion is related to PatternSkin only (not the Engine).

Setting to normal / waiting for feedback (probably from Arthur).

It is not a release blocker but more of a feature request (a bit more discussion of this in TWiki:Codev.WhatIsIn04x01).

-- SP

Changing the behavior in non-backwards compatible ways is a release blocker. Why was this changed in the first place? -- TW

This cannot be a pattern skin only thing, as "view printable" is a TWiki feature, albeit one that may be realized by a skin.

-- TW

Guess this whole thing is worth some thought.

When print is made by skin - then it means that no matter which skin you use the Printable feature will result in the same look.

Is this correct? Is this desired? I would question this.

I would think that the printable when using PatternSkin should look the Pattern way. And printable in Kenneth skin should look the Kenneth way. Example the font could be larger or different in a special skin. And then printed you would want a result not too far from the normal display except you do not want menus and other navigation items.

The new implementation now allows a viewprint.pattern.tmpl and a viewprint.kenneth.tmpl so that the print style can be made to match the overall style of the skin.

I would assume this is the explanation for the change in TWiki4.

Which plugins are broken by this enhancement? And isn't it possible to fix those plugins instead of reverting what seems to me to be a good enhancement made in TWiki4?

KJL


Ken, thanks for the good explanation. I don't understand, though, why using a print skin would be any less flexible to adjust for the skin than the viewprint template, in particular in the presence of the cover feature.

The most important thing that is broken by this "enhancement" or change is that viewing a topic in printable mode looses all the url parameters. That breaks many of my topics that customize the topic dynamically based on url parameters that had been passed (search is one example, but there are many others). That is described in another bug report.

The other thing that broke is that now one needs to handle skins and templates where before one just needed to handle skins. For example, several of my plugins look at the skins to decide whether to process a topic or not. I had to adjust all these to also look for the viewprint template, which I did not have to do before. -- TW

Thomas, I believe Kenneth is waiting for feedback on his last two questions...thanks

CC

Oops. I think the questions are:

  • Q: Which plugins are broken by this enhancement? A: All plugins that do things differently when the mode is printable. Examples are the plugins using TWiki:Plugins/EditContrib.
  • Q: And isn't it possible to fix those plugins instead of reverting A: Yes, and I have rewritten my plugins (but did not check other people's plugins).

My concern is regarding what seems to me to be a good enhancement made in TWiki4. I fail to see why this is a good enhancement. It seems there are no advantages one way or the other, except now we have two ways of affecting the appearance of a topic in a systematic way:

  • by applying a skin or cover
  • by changing the template
We need to at least give guidance to developers when they need to use one vs. the other. Stackable skins solved the problem that (I think) the template-based print mode also was trying to solve. -- TW

  1. Using a template as url param has been done for a long time, not particularly new for pattern.
  2. A print view is not a new skin, but a change of template.
  3. I find it strange that you would rely application behaviour on a print view. Why not use skin=text? -- AC

Not sure what the last point is trying to say. -- TW

Out of ignorance: why do you need the print view? Is it for printing, or does it have another purpose? -- AC

AC, I am sorry but I must be dense here. I use the print view for showing pages in a printable form. There are many plugins that should not trigger for the printable view. There are also skins such that when they are applied, a plugin may not want to trigger. Before one only needed to examine the skins and dumped out of the plugin when a "non-printable skin" was applied. Now we need to look also for the printview template. No big deal, but as it seems to be a gratuitous change I was wondering why (remember the mission?). -- TW

It seems that this is taken as far as it can go. Thomas now knows why the change was done and it seems the plugins can look for the printview template.

And I do not sense that there is a majority that want to loose the new feature where each skin can have their own print view. So the right thing now will be to change this to discard.

KJL


How would calling ?skin=print make things better for you?

AC

I have moved on to a bigger problem, that I discovered recently... see below -- TW


I recently discovered a nasty problem that is due to this change:

If you have a topic specific view template to present a particular topic, and you click "print" to show it in a printable mode, the topic specific view is ignored but instead, the ordinary view and viewprint templates are used to render the page.

The problem is that replacing the template is not right. The printable mode is an overload mode to the standard view which should just remove some of the decoration of the page. It must not change the basic view of the topic otherwise.

This really has to be rethought... -- TW


I will think about a solution...


If an application uses a different template and you want to print it - then you want the top bar and left bar and other noice to disappear but still want to preserve the rest.

Thomas has something here which is not an enhancement but a bug.

Changing the state to urgent.

KJL

An additional note. Surely changing the entire way we print is our of scope for 4.1 but at least the experts in templates should consider

  • If there is a workaround quick fix that can be implemented
  • The more long term plan which accomodates the two requirements.
    • The ability to print topics that have a customized template
    • The ability for each skin to have its own printing style

It is the two requirements above that seems to pull towards new TWIki 4 method vs old Cairo print skin method. A technical solution is needed that gives reasonable coverage of both requirements.

KJL


I have written up my thoughts at TWiki:Codev.PrintableViewNeedsRethinking. I think I have an easy solution, but need to experiment first. Will report back there... -- TW
Turns out there is an easy and quick initial solution (discussed in the discussion topic). Tested on my installation. -- TW
Checked in a fix, but pseudo-install needs to be run on Bugs before that change is fully workable. Until then printable view does not work. -- TW

Note that this fix also addresses a shortcoming in the current printable mode in that it deviates to much from the view mode, as discussed in Item3271. It does, at this time, include the broadcast message in printable view, due to a lack of granularity (this is a tradeoff between the risk of somebody redefining in the topic-specifc template the "textcontent" snippet vs. the broadcast message not being wanted in printable mode).

TW

Remember twikiplugins/PatternSkin/lib/TWiki/Contrib/PatternSkin/MANIFEST

I have fixed it.

KJL

Broadcastmessage does not belong in print view. It is meant to be an alert for site visitors, and bears no relationship with the topic.

AC

I agree with AC on this Broadcastmessage detail.

But most important - the good news is that so far I have not seen this fix break anything. I have not used customized templates much myself so I have no local test topics to test this in but I am sure Thomas has.

But from a compatibility point of view all normal printing seems very fine.

KJL


I have added another snipped TMPL:DEF{"broadcastmessage"} to view.pattern.tmpl to allow removing that... -- TW

I found a problem in that the form does not always show and fixed that. -- TW


Please think about whether the attachements should show in the printable mode. Currently it shows the twisty in the printable mode (if twisty are used) which is not very useful. -- TW
No further feedback, thus leave further refinement for future enhancement. This is currently consistent with how the printable mode was in Dakar. Ready for release.
I implemented a generic way of invoking printable mode independent of the current skin via ?cover=print . This allows the print directive to be used anywhere without having to worry about what the current skin is. The basic idea is that view.print.tmpl dispatches to the appropriate skin via viewprint.tmpl. -- TW

4.1.0 released

KJL

ItemTemplate
Summary PatternSkin: Print view changed in backwards incompatible way
ReportedBy TWiki:Main.ThomasWeigert
Codebase 4.0.2
SVN Range TWiki-4.1-beta1, Mon, 24 Jul 2006, build 11161
AppliesTo Extension
Component PatternSkin ClassicSkin
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 12195 12197 12202 12222 12223 12250
TargetRelease minor
Edit | Attach | Watch | Print version | History: r47 < r46 < r45 < r44 < r43 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r47 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback