Package: links-ssl Version: 0.96.20011222-1.1 Recently, debiandoc-sgml in woody started generating <link href="..."> tags at the start of pages. This was quite annoynig for the user of links-ssl and lynx, but OK for the uses of w3m, galeon, and evil-IE. After a chat with Ardo van Rangelrooij <ardo@debian.org>, we came to the conclusion that these tags are becoming standard thing and kinks and lynx must handle them reasonabbly. I personally think these shell be the optional content to be displayed by specifying some command line option. You may differ with me on above strong comment but at least these shall be some way of turning on/off these links. To see the effect, please see page like: http://qref.sf.net/quick Though I report on ssl enabled packages, I think this is general issues with these program. I see the same problem with cygwin lynx :) Thanks Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii links-ssl 0.96.20011222- Character mode WWW browser with SSL ii lynx-ssl 2.8.4.1b-3 Text-mode WWW Browser supporting SSL
Package: debiandoc-sgml
Version: 1.1.59
Severity: wishlist
Please make the generation of <link href="..."> tags in <head> ...
</head> section of html files to be selectable by a command-line option
because of the following reasoning. Also cyclic page pointer at the top
of html should also be selectable. (CCed to the affected package
maintainers.)
---
Recent improvement in debiandoc-sgml started generating new tags at the
<head> ... </head> section of html file. This causes annoying effect
when these pages created from a large sgml source is viewed by browsers
such as "lynx" and "links", i.e., first few pages of each page are just
"href" links.
Good example web page is: http://qref.sf.net/quick/index.en.html
("links" starts at page 13 so pressing the "HOME" key is nightmare)
Though this is a problem with the browsers (bug report #138240 and #138241)
and not a problem with mozilla/galeon/w3m, I think debiandoc-sgml shall
offer some kind of remedy considering woody is in practical freeze mode
and these browsers will be released in this state.
For cyclic tag, since we have [1] ... links at the top of pages seen by
"galeon" and "w3m", I do not know how useful it is.
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii debiandoc-sgml 1.1.59 DebianDoc SGML DTD and formatting tools
[...] links or lynx, because text mode browsers take teh approach to visualise everything could be visualised, then providing non-visual data to the user in a form they feel appropriate. Both browsers approach the question as "we won't hide information possibly useful to the user", and I believe this is what happens: the information is showed, because browser cannot decide whether user needs it or not. Graphical browsers usually handle these differently, some may even use this info to visualise the links/references, create a toolbar or whatever goodies they come up with. I don't think hiding this would be easy, because there are plenty way to embed informations into html and the browsers cannot guess which one does the user need and which one doesn't. Hiding useful info is usually not an option here, graphical browsers aren't for the ignorant average Joe. :-) Uh, what't the goal of those anyway? Does any browser use it? Peter
Peter, I understand you are "links" guy :) I thank you a lot for maintaining nice package. I feel some gap with you. "appropriate" is good guide line, though. Please read on and reconsider the situation. First, updates on the situation. 1. After discussion with Ardo (debiandoc-sgml upstream and package maintainer), Ardo agreed to make generation of <link ...> tag as optional feature since woody release is near and it is very unlikely to get popular browsers to be friendly to these tags before the release. Currently, creations of <link ...> tags are optional and enabled only by the command line option "-L". So those bug reports (#138240 and #138241), we do not expect any actions from their maintainers before the woody release. We both agreed, generation of these tags are GOOD things since it can be used by browser effectively as index etc. 2. What is really happening with "links" and "lynx" In case of "Debian reference" created by debiandoc-sgml with -L option, you get followings: Link: start Link: prev Link: next Link: contents Link: copyright Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: appendix Link: appendix Link: appendix Link: appendix Link: section then there are 17 page long repeats of just Link: section before seeing any real contents. This is the effects of <link..> tag. Besides, those links was not so useful without proper display of "title". "lynx" does print "title" but 11 pages of them without any formatting was pain. My request should be understood as a request of data presentation format and choice given to the user. At this moment, "links" and "lynx" force users to see long practically useless representation of <link ...> tags on certain web pages whose authors expect them to be shown in separate window or such. User has no choice to turn it off. That is the issue. Yes. Same can be said for console browsers. Turning their display by command line option (or key command) is a practical feature to have. "Useful" if only they are presented in a reasonable manner. You do not display information in <!-- ... --> unless you display sources in these browsers. Discussion of displaying these hidden links shall be something similar to how we should handle comments and chose not to show them in normal display but display them in the source display. Good point. I do not know. :( I think having index side-bar is natural use of them.
uh, could you keep a page up showing these link fields? I cannot test it. thanks.
Hi Andrei! Andrei POPESCU wrote: Thanks a lot for reminding me of these. Manuel A. Fernandez Montecelo approached me a few weeks because of these, too, but back then I just found time to work through a few of them. I've now checked all the remaining ones. At least some of them are duplicates of bugs against links or links2, others are fixed in links/links2 in the meanwhile (those should be closed with this mail), but many seem still present. Here's my summary (Cc'ed to all mentioned bugs, some of them closed via -done) of these bugs and what I did so far: No more present. Closing. Duplicate of #55425. Forcemerged. Maybe a duplicate of #509469. Contacting the reporter or the commenters would likely be the sanes option. Haven't touched it yet. No more happens in Debian Squeeze. Closing. Is tagged as unreproducible -> Asking the reporter (which is MIA) or directly closing. Haven't touched it yet. Still present. Reassigned. No more present in Debian Unstable _and_ a duplicate of #108431 which I can no more reproduce anymore in Unstable. Yay! Reassigned. Closing. Still present in Unstable. Reassigned. Of 4 things mentioned in there, 1 is fixed (|), 1 is no more applicable (h/y), 1 is still there (*) and with the fourth thing, I'm not sure what he means. The "z" keybinding for "Go back in URL history" is indeed still present in unstable. Reassigned and retitled. Of 3 things mentioned in here, 2 are fixed (languages and codepages are now a menu), and the third (blank on startup without parameter) is still present, but likely a wontfix + upstream or such. Reassigned, tagged and retitled. Still present. The easiest workaround (and likely that upstream did that on purpose), is to prepend "./". Reassigned and tagged as wontfix as this looks like on purpose. Still present. Reassigned and tagged upstream. Can't reproduce it anymore and according to the last mail a fix has been committed upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=144542#11 Closing. Gah. That sounds like an ugly feature. Not sure what to do. That needs a non-trivial setup to test. Reassigned. Will maybe test it somewhen after the freeze. Still present. Reassigned. No more present. I just switched to yellow links in the terminal. ;-) Closing. Still present. Reassigned. Still present. Reassigned. Clearly fixed. Closing. Still present. Example: /usr/share/doc/developers-reference/index.html Reassigned. (I hope none of the bug reporters minds this mass-bug-closing and -replying. :-) Regards, Axel
-- _An official winning notification has been sent to you Google Cooperation INC, Kindly download attachment for more information:_ _Sincerely,_ _ _ _Monica Marchese Swinerd_ _Director Google Senior Fellow/Artificial Intelligence_