Re: <OK> [Groff] grohtml

[Chuck Robey]

Mike Bianchi wrote:
> Chuck,
> 
> As a fellow lover of mm (since the mid-1970s) I will try to help.
> Please send along:
>       example files that illustrate your issues, both sources and results
>               the simpler the examples, the better
> 
>       the command lines you use to create the results from the sources
> 
>       the output from  groff --version 
> 
>       output from  uname -a
> 
> I will take a look and let you know what I find.

Well, having been using mm for nearly as long as you, I can sympathize with your
term "lover", I really like using them, but I think you didn't read me: I was
stating that I have no problem whatsoever with the mm macros when they're going
to postscript or ascii, but when I have them as html output, the mm list macros
show up very, very, badly.  It looks like there isn't any leading spacing
allowed after I use a list macro.  If I invoke (say) .AL, then the list starts
immediately after the last character previously output, and it totally ignores
me if I try to add either a .br or a .sp to force a break in formatting to
workaround that lack of leading spacing.  I'm not talking about each list item,
I'm talking about the beginning of the entire list, it refuses to give me a
leading line break.  Again, this is in -Thtml ONLY.

In the doc I'm currently working on, I have a centered title, a break, then I go
immediately into alpha lists, and it looks very bad for the html out (other
outputs, as usual, look just fine).  From hints I got from Gaius Mulley, I
looked at the www.tmac file, and found that there seems to be added macros
ULE/ULS, DLE/DLS, and OLE/OLS (meaning list start/stop for ordered, unordered,
and "definition" lists, as would be familiar to any old html fan).  I'm thinking
that what I'd want to see would be some way to convert some of the mm list
macros into macros already written (and I think they work, from what tests I've
done) for html output.

I mean, for myself, I think that the best thing would be to modify the mm macro
to read the  -T arg (no problem) to see if the output is html, and provide a
pretty easy conversion from .VL(mm) to .DLE(html), .AL to .OLE, and .BL to .ULE.
 You wouldn't be able to get perfect conversion, but it'd be close.  Would that
kind of trick be strategically sound?  I mean, if I were to work up a small set
of diffs to mm to handle this, would it get immediately rejected for doing
things in the wrong order, or (depending on if I do acceptable code) would such
an approach be acceptable?

Another way to handle this (instead of changing the mm macros) would be to make
a smallish set of macros which would intercept the .AL, .BL, and .VL macros, see
if it were html output, and convert them there.  Wouldn't touch the mm macro
file at all, but I'm not sure how do I force (via the commend line) for my
little mm-html-listmacro-fix file to get read *before* the mm macro processing
gets done.

Which would be better from the standpoint of you fellows?  how do I force my fix
file to get done before the mm macros get read?

If either of these kinds of approaches sound off, then could I get some ideas of
how you'd handle things?  Don;'t worry about telling me HOW to convert, if I
have problems doing that, we can hash that out later, ok?  Just tell me the
strategy you'd rather see used.  I'd really rather not just write a fix for my
own use alone (which is what I'd be doing if I can't get an idea of a correct
fix here).