Up to now, users had to append ?style=printable to URLs to get a printable version of documents. This not user-friendly. Handbook pages show a "print" item in the navbar, why should they be an exception? Users have no way of knowing whether a doc is printable (only <guide> and <book> are), it is clumsy and some printable docs do not even yield a printable version even with ?style=printable because guide.xsl has been hardcoded into the .xml Dr. X has the cure ;-) 1) Making All Printable Docs Really Printable Testing style==printable before calling either guide.xsl or guide-print.xsl is pointless. guide.xsl needs to test it again anyway and any .xml explicitely using guide.xsl cannot become printable. All we need is 1 (one) test in guide.xsl to get rid of guide-print.xsl. handbook.xsl can be made simpler as well because it does not need to test the style at all. I have made guide-print.xsl trivial, it has to be available until the AxKit config has been updated to not reference it anymore. 2) Giving Users Easy Access to Printable Versions To let users get a printable versions of a doc, the friendliest way is IMHO to put a "Print" button on printable pages. See http://dev.gentoo.org/~neysx/tests/gentoolkit.html for an example. All <guide> and <book> are printable, but to display the link, the stylesheet needs the link attribute in <guide> or <book>. I suggest making the link attribute #REQUIRED instead of #IMPLIED in the DTDs. _ALL_ books already have the link attribute and it should have been made compulsory anyway because the navbar already relies on it. The GWN and very few <guide> docs are missing it. I can fix most, not the GWN though. The GWN guys would need to specify the link attribute in upcoming newsletters, old ones can be left as is (no link attribute==no print button==no change from current situation) or can be updated if the GWN guys want to. The few other docs that would need an attribute link on their next commit are: ./proj/en/base/sparc/obpreference.xml:<guide> ./proj/en/desktop/research/manifest.xml:<guide> ./proj/en/desktop/research/config_tools_reqs.xml:<guide> ./proj/en/desktop/research/meeting_reports.xml:<guide> ./proj/en/desktop/science/hpc_annonce.xml:<guide> ./proj/en/releng/status/status_20040607.xml:<guide> This not asking too much IMHO.
Created attachment 39607 [details, diff] Patch to several files to implement suggested improvement Please review. Thanks.
Suggested change to the AxKit config. I am neither an apache nor an AxKit gutu, this is the one I used: <IfDefine PERL> LoadModule perl_module extramodules/libperl.so PerlModule AxKit SetHandler perl-script PerlHandler Apache::AxKit::StyleChooser::PathInfo AxKit AddHandler axkit .xml .xsp AxAddXSPTaglib AxKit::XSP::Util AxAddXSPTaglib AxKit::XSP::IfParam AxAddXSPTaglib AxKit::XSP::Param AxAddStyleMap application/x-xsp Apache::AxKit::Language::XSP AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT <Files *.xml> AxAddProcessor text/xsl /xsl/guide.xsl </Files> </IfDefine> What's important: - not reference guide-print.xsl anymore so that it can be removed - use guide.xsl
*** Bug 64051 has been marked as a duplicate of this bug. ***
The changes have been committed.
Is axkit still using guide-print.xsl? We'd like to get rid of this one. Kurt?
I have no idea whether or not AxKit uses guide-print.xsl. Also, you should not depend on any AxKit-specific features as we will be replacing it at some point (hopefully sooner, rather than later) If we have to chose between losing features that we use (and even rely on) today vs. finding a suitable, if less feature-rich replacement for AxKit, we will definitely choose the later. --kurt
AxKit doesn't "depend" on it, our configuration does (or at least did when I got the httpd.conf excerpt from you). Neysx' changes don't require the use of an additional XSL file for the printable version which is an improvement over the old style (since it makes the search for a new solution easier). But you do have to alter the AxKit configuration as stated in comment #2. What I did was comment out the printable stuff: """ <AxStyleName "#default"> AxAddProcessor text/xsl /xsl/guide.xsl </AxStyleName> <AxStyleName printable> AxAddProcessor text/xsl /xsl/guide-print.xsl </AxStyleName> """ became """ <AxStyleName "#default"> AxAddProcessor text/xsl /xsl/guide.xsl </AxStyleName> # <AxStyleName printable> # AxAddProcessor text/xsl /xsl/guide-print.xsl # </AxStyleName> """ Everything still works, so this particular AxKit configuration can probably be removed. I haven't checked everything (especially those pages working on the /dyn generated ones) since I don't have those scripts.
As Sven explained, we do not rely on axkit's features, well, not anymore. My recent changes help make things simpler and the move to another engine has become simpler as well. FYI, AxKit looks at the requested URL and calls different stylesheets based on a style variable. The current setup is to default to guide.xsl and call guide-print.xsl whenever style=printable appears in the URL. This is not required anymore. Sven's sample config keeps the style functionality but uses guide.xsl only. My sample in #2 completely removes the functionality. It works for me on docs, GWN and project pages. BTW, what's the status on the new engine? Are you still looking for a solution? I thought you'd use tr4nsf0rm. If not, I could cook you a simple ruby cgi script that processes the .xml through xsltproc, even adding caching would be trivial. Just let me know if you're interested.
Reassigning to klieber (you really need an infrastructure@gentoo.org alias for bugzilla :). Check out if parts of the site still rely on guide-print.xsl. If not, it can be removed.
guide-print.xsl has been removed as current AxKit config does not use it. This can be closed IMHO
No need to keep this one open any longer.
