I am trying to read the info for Groff using KDE Help Center. The paragraphs take turns in using monospace and sans-serif. There is no apparent logic behind this variability. Additionally, several lists are misplaced (not indented).
Additionally, the lists at GROFF_CHAR are blank.
perhaps you would like to “pay back” to the community by doing some
proof-reading and editing…
you can jump in, from here: http://en.opensuse.org/How_to_Participate
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
Suggestion accepted, and that is indeed what I intend to do; however, I am a bit overwhelmed with the number of things that do not work or are undocumented and I really do not know where to start. For now, I am trying to put down the obstacles I trip on.
For example, it turns out that the man command uses groff device ascii8, which is undocumented, and groff itself uses the command grotty, which is also undocumented.
yecril71pl wrote:
> overwhelmed with the number of things that do not work or are
> undocumented
i guess you need to define “undocumented” or maybe you missed one of
my earlier posts:
because using the last mentioned documentation option therein i
easily find info/documentation on:
groff http://tinyurl.com/33tdql9
ascii8 http://tinyurl.com/33xmhyq
grotty http://tinyurl.com/3xbqut5
don’t get me wrong, i very much agree when first starting up this
“steep learning curve” it would be much more easy if one didn’t need
to know lots of stuff just to know where and how to find the stuff
they don’t know…
it would also be cool to have been born with a good understanding of
which is it:
an openSUSE problem
a KDE problem
a Gnome problem
a Linux problem
a software problem
a hardware problem
a driver problem
an operator problem
or etc etc etc…
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
By undocumented I mean not documented in info. Thanks for pointing out that ascii8 is documented in man; however, since GNU in general prefers using info, I did not expect the info pages to be obsolete and inconsistent.
yecril71pl wrote:
> https://savannah.gnu.org/bugs/index.php?29894, I do not make these
> things up.
drop an unneeded ‘s’ and give this a try:
http://savannah.gnu.org/bugs/index.php?29894
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
yecril71pl wrote:
> And chapter 1p, where ‘iconv’ (man:iconv(1p)) is documented, is not
> mentioned in the Help Center at all.
what do you think: ‘we’ are paying these documentation writers huge
sums of money and ‘they’ are ripping us all off?
or what?
well, let me ask it another way: what do you expect for free??
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
well, let me ask it another way: what do you expect for free??
In this case, I expect that manual and info pages are accessible and readable from the Help Center, preferably in the user’s language of choice, and that they contain relevant and consistent information. I think the fact the system is free is an opportunity to achieve that.
FTR, a better description of what ‘-Tutf8’ means:
The “utf8” device in the unmodified versions of groff accepts input in ISO-8859-1 and produces valid UTF-8 output. Therefore it works properly in UTF-8 locales if the manual page is ISO-8859-1 encoded.
<http://www.linuxfromscratch.org/hints/downloads/files/man-i18n.txt>
The corollary of that document is that I cannot honestly tell anyone that she can use a Linux system instead of Microsoft Windows unless she is fluent in English or speaks a Western European language. Not until groff_2.0 appears.
An alternative would be to transcribe all manual pages to HTML.
My 2 cents: you will see less and less manuals delivered with software. Stick them in one place on the web, update with every software update. There’s already loads of (linux) apps that send you directly to help content on a website.
If you are convinced you have found a true source of trouble, consider making some kind of project from it, as a contribution to the open source world.
Web manuals are very good for people on broadband with an intelligent proxy server. Not everyone has this luxury, and local content is still considerably faster to access.
In the particular case of groff the Web manual is broken as well.
Addendum: The manual page for pic does not contain the full description, and the path to the [full description](file:////usr/share/doc/groff/1.18.1/pic.ms) does does not denote a file. That particular file is installed [elsewhere](file:///usr/share/doc/packages/groff/1.18.1/pic.ms).
That’s going quite off topic, I don’t think these forums can do anything in this matter. openSUSE does not make the man pages. If I do a ‘man pic’ I get exactly the same as what is on PIC
You may have caught a bug on the file urls. But, like said, you might be better off posting this to the manpages mailing list.
What is the manpages mailing list?
The original topic was not about what man displays but how the KDE Help Center screws up info pages. I get the same result opening a documentation URL for [groff](info:/groff/What Is groff%3F); it opens in Konqueror and looks the same. I am able to look at the document source this time; it looks dramatic because it is peppered with random PRE tags. The bottom line says:
Automatically generated by a version of info2html modified for KDE
I submitted the source to the validator; it is invalid, of course, so no more questions I guess.
Also, compare the node “(texinfo)Overview” in KDE and standalone. Notice how the latter looks significantly better. The info2html script appears to be broken for KDE.
The idea to reverse engineer formatted info documents into HTML code is insane. Konqueror would be better off using texi2html or makeinfo directly instead. However, since the documentation sources are not installed with binary packages, the HTML version should be produced during build.