[net.text] .hl in ditroff -me

isaac@mulga.OZ (Isaac Balbin) (01/21/86)

I wonder if anyone else has been bitten by this bug?
.hl is meant to draw a horizontal line with the -me package.
I have found that on occasion, especially within .(b and .)b,
.(l and .)l and .(x and .)x (the last of which I dread to use anyway
because text has disappeared down that proverbial black hole)
that the line does not appear as it should because:
(1)	It is not whole (ie it comes out dashed);
(2)	It extends beyond the line length, up to the end of the page.
At one stage we realised that using .(b M for example alleviated
the problem, but it is still not cured.
It is even more exacerbating because if I pull the block out and
print it seperately it actually works. It is clearly a context thing.
Whatsmore, it even happens when the .hl appears *immediately after* the .(b.
My question is: has anyone seen this before? does anyone have a fix (sic)?

				thanks,
					Isaac Balbin
UUCP:	{seismo,mcvax,ukc,ubc-vision}!munnari!isaac
ARPA:	isaac%munnari.oz@seismo.css.gov
CSNET:	isaac%munnari.oz@australia
JANET:	munnari.oz!isaac@ukc
ACSNET: isaac@munnari.oz

suze@terak.UUCP (01/24/86)

> I wonder if anyone else has been bitten by this bug?
> .hl is meant to draw a horizontal line with the -me package.
> I have found that on occasion, especially within .(b and .)b,
> .(l and .)l and .(x and .)x (the last of which I dread to use anyway
> because text has disappeared down that proverbial black hole)
> that the line does not appear as it should because:
> (1)	It is not whole (ie it comes out dashed);
> (2)	It extends beyond the line length, up to the end of the page.
> At one stage we realised that using .(b M for example alleviated
> the problem, but it is still not cured.
> It is even more exacerbating because if I pull the block out and
> print it seperately it actually works. It is clearly a context thing.
> Whatsmore, it even happens when the .hl appears *immediately after* the .(b.
> My question is: has anyone seen this before? does anyone have a fix (sic)?
> 
> 				thanks,
> 					Isaac Balbin
> UUCP:	{seismo,mcvax,ukc,ubc-vision}!munnari!isaac
> ARPA:	isaac%munnari.oz@seismo.css.gov
> CSNET:	isaac%munnari.oz@australia
> JANET:	munnari.oz!isaac@ukc
> ACSNET: isaac@munnari.oz

I have had a similar problem, but fixed it rather easily. Most
of the .( commands alter the line length. Try using .(b L or
.(l L.  This should cure the problem, since you're telling troff
to NOT alter the line length. I don't understand the problem
with .(x since it doesn't, of itself, alter the line length.

I must say though, that the problem I encountered was a bit
different. I did not get dashed lines and they were too short,
not too long. Nevertheless, it sounds, at least partially, as
though it's a line length problem.

I've never had any problem with .(x causing text to disappear
into a black hole. Are you sure you printed the index it was
placed in? And that the index didn't overflow its temporary
file? The later will print error messages during troff
processing. The former is silent, since it isn't a troff, but
a writer, error. If you'll give an example of where your text
disappeared, I'll try to help.
-- 
Suzanne Barnett-Scott
uucp:	 ...{decvax,ihnp4,noao,savax,seismo}!terak!suze
CalComp/Sanders Display Products Division
14151 N 76th Street, Scottsdale, AZ 85260
(602) 998-4800