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