groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Groff] Fw: the www.tmac macros


From: Werner LEMBERG
Subject: [Groff] Fw: the www.tmac macros
Date: Tue, 29 Dec 2009 07:52:16 +0100 (CET)

Back to the list...


     Werner
--- Begin Message --- Subject: the www.tmac macros Date: Mon, 28 Dec 2009 20:26:06 -0500 User-agent: Thunderbird 2.0.0.19 (X11/20090121)
I finally got directed to read the boilerplate at the top of that file, so I got
your names.  I'd passed over it several times.  I have some comments regarding
the OLS/OLE, ULS/ULE, and DLS/DLE macros, and how best to integrate them along
into the mm macros.  I don't want to ask you to do my coding for me.  That
doesn't mean I would reject help, but I will assume (unless you tell me
otherwise) that you both have moved on to other projects, and while you two
might be willing to give me opinions, I need to do the work myself.

[If you feel this stuff ought to go to the list (and you'd reply there) then
feel free to forward this there.  I got the feeling that this stuff was too
down-in-the-details for that list, and I sure didn't want to raise their noise
level.]

OK, several points:

1) from the html test files I've handwritten, embedding one list type inside
another, from a purely html standpoint, works fine (using lynx to display the
file for me).

2) From the test file I wrote using the macros listed above (and LI), your list
embedding doesn't operate.  I mean, the sublists display, but their indentation
and marks are all wrong.  First level lists work fine.

>From these two points, I *think* I can draw several conclusions, and maybe need
some advice on how to get the proper integration with mm working properly.

1) At every list level, it seems to me that you need to know these several
items: what list type (if any) is currently active.
2) If (at every list level) if a subitem is open.  This means if either a LI is
open, or a DD.  I can figure out which from the open list type, but I need to
know this, so I can correctly close the item.
3) this info needs to be available in something that (at least roughly)
approximates a stack.  This both because of the form of the data AND because I
need to be able to pop that stack, and recover data items #1 and #2 at every
level.  It would be nice to know how deeply I was at in that stack, but I think
that might be gotten by finding out that the list type was "".

Questions regarding the mm integration are those of strategy.  The simplest way
for me to get it to work would be for me to make something like a mmhtml.tmac
file, and expressly include it in my source file.  That way, I could be assured
that the mm macros had already been read in, so I could feel safe about
rewriting those .AL, BL, ML, and VL macros (if I detect html) to something using
a fixed version of your www.tmac macros.  However, there are other ways to fix
this: if I knew of some OTHER way to insure that my mmhtml.tmac file would
definitely get read in AFTER the mm macros, then having a mmhtml.tmac located in
the system macros, would be another way to do it.  If I could be certain that
your www.tmac would be read in after the mm macros, I could just add in the
rewriting of the mm macros right in your own file.  Or, lastly, I could add my
fixes to mm (and separately to your www.tmac file).

Do you have opinions about that?  Do you think I'm right or wrong about the data
I think is needed about the state of open html macros?  Or, seeing as I didn't
find any text about how to use your www.tmac macros, maybe you think I miswrote
them, and your macros work just fine already?

Ton of questions, aren't they?  I promise that if I get a better notion about
these "strategic" questions, I will try hard not to bother you about the
"tactical" questions regarding actual implementation.  I've been reading
everything I could find regarding macros, and maybe I can keep things quiet
there (at least, I hope so).

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]