[Groff] Re: some details missing from your patch

[Gaius Mulley]

I wrote sometime ago:
>>>>  The @code{tag} request emits a device special ditroff command
>>>>  @emph{without} any space between itself and the next glyph.
>>>>  Importantly it is also issued immediately after the previous troff
>>>>  state (if any were emitted).

Werner LEMBERG <address@hidden> writes:

> > > If I understand that correctly, tags issued with `.tag' are
> > > emitted twice under particular circumstances, right?  Can you
> > > provide a small example?
> 
> Could you answer this, please?

Maybe I've mistaken your question, but tags generated via `.tag' are
only emitted once.  But they are issued after the previous troff state
(as one would expect) and with no space between the last list of
specials generated by a troff state change. Diversions of course
generate quite a few tags (restoring and changing) the troff state
(br, in, sp, ll) but these tags are not generated via the request
`.tag' but by `.sp', `.br' etc.


This behaviour differs from the `.taga' which will emit the user tag
before the next glyph is written to the ditroff output stream. Note
that a troff state change could occur in-between. For example:

.LP
one
.taga two
.sp
three

results in the following ditroff output:

tone
wh24
n40 0
V160
H0
x X html-tag:.sp 1
x X html-tag:.br
x X two
V160
H0
tthree

this is used in www.tmac in the macro HTML-TAG-NEXT and this macro is
utilised by s.tmac and an-old.tmac to handle indented paragraphs.

> 
> > >   .tag -- a new request which is really the equivalent to \X'...'.
> >
> > this emits a tag with a tailing space between itself and the
> > next glyph.
> 
> Why?  If I say
> 
>   a\c
>   .ft foo
>   b

true, from some preliminary testing .tag abcd appears equivalent to:

   \X^html-tag:abcd^\c

Here is a worked example `.IP' from s.tmac

file: tmac/www.tmac
.\" HTML-TAG-NS
.\"
.\"   Emit a tag for grohtml (without a space).  This is an internal macro.
.\"
.de HTML-TAG-NS
.  if \\n[www-html] \
.    tag html-tag:\\$*
..


file: tmac/s.tmac


.de @IP
.if \\n[.$]>1 .nr \\n[.ev]:ai (n;\\$2)
.par*start \\n[\\n[.ev]:ai] 0
.if !'\\$1'' \{\
.       \" Divert the label so as to freeze any spaces.
.       di par*label
.       par*push-tag-env
\&\\$1
.       par*pop-tag-env
.       di
.       chop par*label
.       ti -\\n[\\n[.ev]:ai]u
.       ie \\n[dl]+1n<=\\n[\\n[.ev]:ai] \{\
.               HTML-TAG-NS ".col 1"
\\*[par*label]\h'|\\n[\\n[.ev]:ai]u'\c
.               HTML-TAG-NS ".col 2"             <---       **
.       \}
.       el \{\
.               HTML-TAG-NS ".col 1"
\\*[par*label]
.               HTML-TAG-NEXT ".col 2"
.               br
.       \}
.       rm par*label
.\}


when run with the input:

.LP
file is \*[.F]
.IP "this"
is an example showing the effect of .IP
.IP "and this is another"
example showing what happens when the leader is longer than some default value.

we get:

x X html-tag:.fi 1
x X html-tag:.ll 1440
x X html-tag:.ta  L 120 L 240 L 360 L 480 L 600 L 720 L 840 L 960 L 1080 L 1200 
L 1320 L 1440
x X html-tag:.col 2
V440
H120
tis


however if we replace ** line with 

    .nop \X^html-tag:.col 2^

we get this broken output:

x X html-tag:.fi 1
x X html-tag:.ll 1440
x X html-tag:.ta  L 120 L 240 L 360 L 480 L 600 L 720 L 840 L 960 L 1080 L 1200 
L 1320 L 1440
V440
H120
x X html-tag:.col 2
wh24
tis

but as you indicated if this were changed to

    .nop \X^html-tag:.col 2^\c

we get the corrected output:

x X html-tag:.fi 1
x X html-tag:.ll 1440
x X html-tag:.ta  L 120 L 240 L 360 L 480 L 600 L 720 L 840 L 960 L 1080 L 1200 
L 1320 L 1440
V440
H120
x X html-tag:.col 2
tis

so it looks as if we might be able to dispense with `.tag'. Although
I'd favour keeping it as it would be nice to move away from using
specials and using `.tag' etc. It would be clearer what these requests
do and for what purpose - they could also be used by the future -Tdoc
device.

> I also don't get a space between a and b.
> 
> > > .tag1 -- this is currently called .tag
> >
> > this emits a tag without a tailing space between itself and the next
> > glyph. Maybe the name could be changed to `.tagns' or do you wish to
> > keep to the numeral extension?
> 
> I'm open to all suggestions which make sense.  But we have already
> .tm1 and .de1, so it is probably not a bad choice.

ok sure, we'll use `.tag1' as this naming method is already in use.

I hope this is understandable?

Gaius