Follow-up Comment #3, bug #62726 (project groff): [comment #2 comment #2:] > [comment #1 comment #1:] > > I have for quite a while been contemplating _removing_ the > > auto-load of the _www_ macro package from the macro file for > > the _html_ output device, however. > > OK, I may as well wait and see where you land on that bigger issue before spending any more time on this minuscule one.
It is of course possible to use the HTML output device as a kind of weird terminal, or a somewhat dumb typesetter. One of the things I want to do is clearly establish what those capabilities are. > Regardless of whether the www macros are autoloaded, it sure seems like any document wanting to take any real advantage of HTML functionality--hyperlinks being the most basic and obvious example--will require them. Not true! Consider two practical examples recently demonstrated. With man pages (both man(7) and mdoc(7)) we have hyperlink support both for PDF and terminal output devices. As recently shown with my re-typesetting of Kernighan & Cherry's eqn user's guide, with a ONE-LINE patch to K&C's private `SC` sectioning macro, we have clickable links to sections in the navigation pane. Under the original definition of a hyperlink as I understand it, text you can poke your finger on to "go" to the referenced material is exactly what this is. Internet URLs do demand specialized support. man(7) and mdoc(7) already have macros to support those and do so in HTML, PDF, and terminal output; they don't need to load the 'www' package to get it. The means of access to this type of feature is the device control command, and the recognition of such commands by the output driver program is where the magic really happens. Consequently people can put hyperlinks to Internet URLs in their me(7) documents _today_. The downside is that they have to input \X escape sequences to do it, and this seems to scare most *roff users (they did me backed when I signed on to join this navy). I speculate that www.tmac was originally conceived as a supplementary macro package for _any_ full-service package. But the advent of mandoc and its community's insistence on a greatly reduced subsetting of the input language for the sake of portability (and concealment of mandoc's own limitations) has already taken man pages out of www.tmac's application domain. I wonder if perhaps it would be better for other full-service packages to just go ahead and add extension macros for the features they want. In some cases even that isn't necessary: as seen with the porting of K&C's paper to gropdf(1), if a work title or author name is well-behaved input-wise, it can be shoved into document metadata verbatim. Having a stronger `troff` request to sanitize any diversion, string, or macro of node data is a feature that I am increasingly coming to think is both feasible and desirable. Think, instead of "asciify", "utf8ify". Anything that can be back-converted to ASCII or a UTF-8 sequence (not forgetting that our old friends the hyphen-minus, caret, tilde, etc. are _not ASCII_ unless remapped) is, and everything else is thrown out. I relatedly think that arguments to the `tm` family of requests (including `ab`) should be similarly handled. I think it would be significant effort for little benefit to add general localization support for troff output to the standard error stream. That is, I don't want troff to have to care whether the environment uses Latin-1 or Latin-9 or Unicode. So the argument(s) to these requests would be scooped into a temporary anonymous troff string and then "utf8-sanitized" as described above, then re-emitted. As a first cut I wouldn't even inspect the environment, but just blast out the bytes in UTF-8 and if somebody's terminal encoding ain't that, they get mojibake. I seem to have wandered onto the topic of Debian #906091 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906091>... > Still, forcing the user to explicitly specify this macro package means the only users who do so will be ones _using_ macros from it, so they should know what macros it defines and be able to avoid those. I think this is the more polite thing to do, to avoid such a squat on the available portable name space. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?62726> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
