Item8575: Remove EditChapterPlugin Icon from print Version / PDF Export

Priority:	CurrentState:	AppliesTo:	Component:	WaitingFor:
Normal	Closed	Extension	EditChapterPlugin & GenPDFAddOn	Foswiki:Main.GeorgeClark

Since HTMLDOC does not support CSS and JS the EditChapterPlugin Icon is vissible on every Heading in a PDF Export. GenPDFAddOn uses the cover=print for exports. So it would help, if EditChapterPlugin would not generate the Code for the img tag if the page is renderd for printing.

-- JohannesHammersen - 19 Feb 2010

Afaik GenPDFWebkitPlugin does honor CSS. Maybe its an easier and faster solution to your problem.

-- OliverKrueger - 19 Feb 2010

There is probably a really quick fix that you could do locally. Try adding ?contenttype=application/pdf to the genpdf URL. That should cause EditChapterPlugin to not generate the Edit icons. I don't think it's a CSS issue. (Tested it here and it does work, and does not appear to conflict with GenPDFWebkitPlugin.

I suspect that I broke this when I added the "view" context to the genpdf script. The "view" context was needed or the EditTableRow? plugin left it's tags un-expanded literals in the document. But this plugin adds the edit icons if context is view.

I need to coordinate with the author of EditChapterPlugin, but I'm considering adding a "pdf" context and suggest that that plugin also bail if in the PDF context. The "contenttype" URL parameter is used by the GenPDFWebKit? and GenPDFPrince? plugins. If I add the context= parameter to the GenPDFAddOn URL, it would potentially conflict with one of the other GenPDF? * plugins.

-- GeorgeClark - 19 Feb 2010

Changes to GenPDFAddOn and EditChapterPlugin will be made. A FeatureProposal? has been raised to add a readonly context that could be set to control rendering of any Edit markup. Other examples are the EditTablePlugin. There are many more. See AddStaticContext

-- GeorgeClark - 22 Feb 2010