Re: [opensuse] man pages and PDF


----- Original Message -----
From: "Randall R Schulz" <rschulz@xxxxxxxxx>
To: <opensuse@xxxxxxxxxxxx>
Sent: Tuesday, July 29, 2008 11:29 AM
Subject: Re: [opensuse] man pages and PDF


On Tuesday 29 July 2008 08:23, Alexey Eremenko wrote:
PDFs are really slow to open.
If you learn some new topic and open 20-30 man pages then it is very
fast. Try that with PDFs.

I dislike PDFs for performance. I prefer man pages, info, or HTML.

I'm with Duaine.

HTML is a hideous medium for publishing.

Html is a great, basically _ideal_, format for publishing.
Especially for content like man pages.
There may be a few even better formats, but they are merely the same idea as troff & html taken a little further.
Like tex/latex. ie: markup & style based.

Html is merely no longer good for what most people want to get out of web sites and web pages.
They really shouldn't probably even be called web "pages" any more, since the last vestiges of the web being like docuents is pretty much gone. Web sites & web pages are more like applications now. But that's web sites, not man pages. documentation is still, uh, documentation, ie, documents. Html is just wonderful for documents.

Info makes me gag.

All in all I hate info too, but for pretty specific reasons, not just because "info makes me gag"

Info, like, troff, html, tex, etc.. is a perfectly fine format for ducuments. It's features exactly match the job.

The only thing I see as bad about the format itself is the index/toc files.
Really dumb. Man-pages are self contained. To install and view a man page you simply copy it or view it.
To install an app with it's man page, you can simply untar it, no install script needed.
But info requires you to correctly edit an index file to integrate your new documents in with all the others...*headsmack*

And I have never met an info viewer app I could stand, and there are damned few and poor of those incomparison to other formats.
That is purely a viewer app problem, and an "I happen to hate emacs keybindings" problem, not a document format problem.

pdf by comparison, is intrinsically terrible for the job man-pages need to do, which job includes being available at all times via even the most limited interfaces.
If all else fails, you can actually just read a man page directly in a plain text pager, or just cat it to your tty even, and mentally ignore the markup commands.
You can't do that with a pdf.

Paging through the CLI man viewer is tedious.

If you don't know enough to use the search function in your viewer of choice, to jump to what you want, that's hardly the document format's fault.
Besides how is that any different than paging through a pdf?
If what you're _really_ taking about is the difference between a text vs a gui viewer, well there are many gui man viewers that work more or less the same as any pdf viewer.
You're inability to find and use a document viewer, as long as they exist, also is not the fault of the document format.

Printing from any of these media
is very problematic.

Huh? The format was a printable format before is was a screen viewable one!
Really it attempts to be output device agnostic, just like html (talking design, not retarded web developers implimentations), but the first output devices were printers and then tty's that more or less emulated printers.
It's maybe not as easy as falling asleep but not exactly problematic. Pretend I don't know anything, I google "print man page"
I get mostly linux-specific answers but, that's ok it's only slightly different for other *ix.

man -t foo |lpr

what, you want gui?
yelp man:foo

Hoy cow that was hard.

And just how do you concurrently view your "20-30
man pages?"

Huh? uh, multiple telnet/ssh/xterm windows? gnu screen? virtual consoles at the console? Not exactly baffling rocket science.

Performance problems are almost always transient. If someone wanted a
fast-launching PDF reader, they could produce it. Hell, you could
integrate it into the kernel. (It works for Microsoft...)

No it doesn't. Pdf's are ridiculously slower and more cpu intensive to open on Windows than say, html.
Every part of handling pdf's (storing, generating, editing, printing, viewing,...) is ridiculously more work than simple text + markup like troff & html to view the same exact content.

Having a fast, mostly un-used cpu in your particular desktop that hides the overhead doesn't make the system efficient. When a given server that normally could generate print-to-html output and display it in the users web browser or email client instantaneously and support say 200 users doing that, the same server can only support say 75 if all those print jobs suddenly became print to pdf jobs. It's absolutely gross. Ask me how I now. Now multiply that by 30 servers...
And even with as much of the workload as possible on the server and the servers load reduced by reducing the number of users to compensate, it's still not as convenient for the end user simply because the pdf takes way longer to open in an email client, and appears as an attachement that must be clicked to view it first. No email client yet lets you flip quickly through all your emails and read & discard them right from the preview pane, including the pdf attachements. But plain text & html work fine. They are right there, already rendered and readable without needing to be opened. I can tap through 60 emails in 30 seconds. If they were all pdfs, no matter how fast my machine was it't be at least several minutes. I don't even want to think about downloading 60 pdf attachment emails and then viewing them on my palm phone, yet text & html re no problem at all for speed, size, & client viewer.
And on the server side the work to create the text or html email or the temp web page was approximately "cat" merely reading and copying a few k of text. Thats no remote comparisn to what ghostpdl or ghostscript or any other util has to do to generate a pdf of the same text.

Man pages are intended to be accessible from any interface, least-common-denominator.
Even if you are dialed in via 9600 baud modem, no tcp/ip, no multiple windows (except maybe via screen or other tty multiplexer), no gui, non-standard display size (8x40 character lcd display?), any kind of terminal including uber dumb terminal with no ansi features and only 7 bit ascii, you can still view any man page. Anything that removes that universal access is a step backwards not forward, since there is no need or excuse for it. The man page format, while old and a bit simple, does allow for fairly nice rendering options on output devices that can support them.

I would have to hear a description of a job a man-page should do, that troff, or some other equally efficient and simple markup system, doesn't provide a means to do, before I'd consider this argument valid enough to even talk about at all.
All the supposed points above fail that test.

Examples might be:
Display graphics/diagrams. Even for basic CLI utils, there is occaional need for such.
Wiring diagrams & signal timing diagrams for serial or other i/o ports, mathematical equations, flow charts and block diagrams describing how a subsystem works or interacts with other subsystems, etc...
Hyperlink to other man pages or specific items within other man pages.

Hyperlinking is easily handled by switching to merely a different markup system that happens to have that.
That seems to have ben the main idea behind info. (which is basically just tex)
Graphics is not so simple. html obviously provides a way to display them while still being a simple plain text markup system, but, should graphics be embedded in the man pages like mime emails with cid:// links? should man-pages maybe be mime formatted for that matter (mime is not an email standard but a generic one) or should the text of a man page remain as small as possible with img links pointing to seperate files, thus allowing man pages to be riddled with broken links...

I'd be interested to hear of any other ideas for things man pages should do but currently can't.

Brian K. White brian@xxxxxxxxx http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages

  • Re: No Word 2007 Viewer?
    ... I forget that sometimes because while I have PDF creating ... Word 2007 was used to create it in Word 2007 format. ... come out with a genuine Word 2007 viewer at some point. ... You simply can't access new Word 2007-only features unless you're ...
    (microsoft.public.word.conversions)
  • Re: What about these?
    ... individual HTML pages, jumping to the relevant location - if the site ... I have dowloaded books on HTML format ... sure may be better PDF own. ... good printed results as TeX which is less complex. ...
    (comp.lang.lisp)
  • Re: No Word 2007 Viewer?
    ... There are even some decent freeware PDF makers out there, ... Word 2007 was used to create it in Word 2007 format. ... come out with a genuine Word 2007 viewer at some point. ... You simply can't access new Word 2007-only features unless you're ...
    (microsoft.public.word.conversions)
  • Re: No Word 2007 Viewer?
    ... Word MVP web site http://word.mvps.org ... PDF makers out there, I hear. ... if Word 2007 was used to create it in Word 2007 format. ... will come out with a genuine Word 2007 viewer at some point. ...
    (microsoft.public.word.conversions)
  • Re: Info Problem
    ... you've essentially got a special-purpose hypertext viewer. ... ...in a manpage is simply unacceptable. ... > Again you can convert it to html all on one page. ... extract another, more useful, format. ...
    (Debian-User)
Loading