Opened 18 years ago
Closed 17 years ago
#1834 closed defect (wontfix)
RFE: printable manuals — at Version 9
Reported by: | Owned by: | hobu | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Documentation - mapserver.org | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
Throughout the site, code snippets are formatted with [pre class="literal-block"] in an already narrow centre column layout. In some places the results look good, but all too often this formatting causes big chunks of code to disappear to the right of a scrollbar, making it impossible to print the page. Since it's a common and very useful practice to print out manuals, I'd like to suggest some alternative formatting for the "all in one page" documents, which does away with the scrollbars and, preferably, with the top, left and right "frames" as well.
Change History (9)
comment:2 by , 18 years ago
Well yes, it would be, but the pdf link is not always present. I'm looking at http://mapserver.gis.umn.edu/docs/howto/wms_time_support/ . Having a pdf link everywhere would solve the problem nicely.
comment:4 by , 18 years ago
Thanks. However, I'd never have guessed that appending /html2pdf to a URL creates a pdf. I don't know if it's a plone feature or a gis.umn.edu special trick, but either way it's pretty esoteric. Adding a pdf link to the base template could be helpful to uninsightful users like me.
comment:5 by , 18 years ago
pretty much every page should have a little adobe acrobat icon in the upper right corner of the center column. Please let me know of any pages that don't
comment:6 by , 18 years ago
You're right, I didn't see it even when I was looking for it :( Unfortunately I just found out that pdfs don't solve the original issue, printability. For example, http://mapserver.gis.umn.edu/docs/howto/WCSServerFormatHowTo/html2pdf has code with long lines in the NetCFD section. If you pdf it, you'll find that the long lines aren't wrapped, but truncated. On page of the pdf you'll see part of the actual code run off the edge. It's not a huge problem; rather a recurring minor annoyance that should be fixed if there's an easy fix. A workaround could be to make the textarea in which these texts are typed/pasted hard wrap, thereby forcing the authors to use \ to split long lines.
comment:7 by , 18 years ago
I don't have a good/easy fix for long lines when it comes to the pdf. Is the PDF generation that we have now sufficient enough to close this bug?
comment:8 by , 18 years ago
Well, no, unless you opt for WONTFIX. The bug is not specifically about pdf generation; it's about printability in general. Because of the way "pre" works, you can't print the html pages and you can't print the pdfs either. You could remove "pre" or force the input textarea to hardwrap or change the behaviour of "class=literal-block" and any one of these things would fix the problem in the html. If it's fixed in the html, it goes away from the pdfs too, or at least it doesn't matter any more.
comment:9 by , 17 years ago
Description: | modified (diff) |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Closing this one as it appears the only way to fix it is to go back through all of the html in the website. Maybe we'll revisit it at a future date.
Note:
See TracTickets
for help on using tickets.