isaac@mulga.OZ (Isaac Balbin) (02/11/86)
Has anyone ever had the text (in this case a picture from pic)
between the .(z and .)z of the -me package vanish never to appear
on the output?
If you have, and have a fix could you tell me. We are running
the 4.3BSD -me macro package.
Isaac Balbin
"Reincarnation == the least fixed point of a recursive born again ..."
===========================
UUCP: {seismo,mcvax,ukc,ubc-vision}!munnari!isaac
ARPA: isaac%munnari.oz@seismo.css.gov
CSNET: isaac%munnari.oz@australiahopp@nbs-amrf.UUCP (Ted Hopp) (02/12/86)
> Has anyone ever had the text (in this case a picture from pic) > between the .(z and .)z of the -me package vanish never to appear > on the output? > If you have, and have a fix could you tell me. We are running > the 4.3BSD -me macro package. > Isaac Balbin > If the vertical size of the floating keep (from '.(z' to '.)z') is larger than the page length, the keep will never be emitted. (I think, in fact, that all future floating keeps will be queued behind the keep that is stuck.) This is probably what is happening to you. The -me macros would apparently rather never output a floating keep than split it across a page boundary. Sort of nasty, I say. You'd think any left over stuff would come spewing out at the end of the document as part of the end macro execution. -- Ted Hopp {seismo,umcp-cs}!nbs-amrf!hopp
isaac@mulga.OZ (Isaac Balbin) (02/13/86)
In article <149@nbs-amrf.UUCP> hopp@nbs-amrf.UUCP (Ted Hopp) writes:
!
! If the vertical size of the floating keep (from '.(z' to '.)z') is
! larger than the page length, the keep will never be emitted. (I think,
! in fact, that all future floating keeps will be queued behind the
! keep that is stuck.) This is probably what is happening to you.
!
! The -me macros would apparently rather never output a floating keep
! than split it across a page boundary. Sort of nasty, I say. You'd
! think any left over stuff would come spewing out at the end of the
! document as part of the end macro execution.
!
! Ted Hopp {seismo,umcp-cs}!nbs-amrf!hopp
That was not the case, in fact. I should mention that the reason (I surmise)
it is not printing the floating keep is that the last bit of `normal' text
does not fill the last page. The vicinity of the last page is approximately
where the floating keep was entered in the original ditroff -me input.
The floating keep should ideally float all on its lonesome to the next page.
However, since there is no text on the next page - except for the floating keep
itself - `-me' says, "No point printing that diagram".
This is just not good enough. I can't believe this sort of thing has not
happened to others before. You haven't all solved this problem by manually
making sure there is enough space on the page for the block (and putting
it inside .(b.)b rather than .(z .)z?
Will I be forced to abandon `-me' and ditroff for `Tex?' Is it indeed more
reliable? I would prefer to think someone out there has a `fix'.
Isaac Balbin
(Rhetorically) "Eric Allman where are you? (In Perth last I heard)"hopp@nbs-amrf.UUCP (Ted Hopp) (02/13/86)
> .... I should mention that the reason (I surmise) > it is not printing the floating keep is that the last bit of `normal' text > does not fill the last page. The vicinity of the last page is approximately > where the floating keep was entered in the original ditroff -me input. > The floating keep should ideally float all on its lonesome to the next page. > However, since there is no text on the next page - except for the floating > keep itself - `-me' says, "No point printing that diagram". What you describe could well be the problem. If the floating keep is defined too close to the end of the output, and doesn't fit on what would otherwise (without the keep) be the last page, it will never get output. The problem is that the output of the keep is tied to a break set at top- of-page, and the break is never getting triggered. This is a bug in -me's end macro, which should test for such conditions. (It does test for hanging footnotes, but evidently not for things waiting for the next page.) A work-around is to force a new page by ending your input with a .bp (break page) request. I simulated your problem (with version 2.15 of -me) and this does indeed fix it. The only disadvantage is that if there is nothing to go on the last page (say, the keep fits on the bottom of the last text page) then you will get a blank page (except for headers and/or footers). Unless you are doing something with the number of pages emitted, or are seriously concerned about paper waste, this won't be a problem. -- Ted Hopp {seismo,umcp-cs}!nbs-amrf!hopp
tet@uvaee.UUCP (Thomas E. Tkacik) (02/14/86)
In article <1047@mulga.OZ> isaac@mulga.OZ (Isaac Balbin) writes: >Has anyone ever had the text (in this case a picture from pic) >between the .(z and .)z of the -me package vanish never to appear >on the output? > Isaac Balbin > The problem is that the floating keep is on the last page. If the page does not fill up then there is nothing to force the the keep to print. This has happened to me many times. All you need to do is have the floating keep earlier in the text, so that it is not on the last page. (Or a .bp command at the end of the text should do the trick, though I have not tried this yet.) If there is a better way to force out a keep on the last page, I would love to here about it. Tom Tkacik ...decvax!mcnc!ncsu!uvacs!uvaee!tet
isaac@mulga.OZ (Isaac Balbin) (02/20/86)
In article <151@nbs-amrf.UUCP> hopp@nbs-amrf.UUCP (Ted Hopp) writes:
! The problem is that the output of the keep is tied to a break set at top-
! of-page, and the break is never getting triggered. This is a bug in -me's
! end macro, which should test for such conditions. (It does test for hanging
! footnotes, but evidently not for things waiting for the next page.)
!
! A work-around is to force a new page by ending your input with a .bp (break
! page) request. I simulated your problem (with version 2.15 of -me) and this
! does indeed fix it. The only disadvantage is that if there is nothing to go
! on the last page (say, the keep fits on the bottom of the last text page) then
! you will get a blank page (except for headers and/or footers). Unless you are
! doing something with the number of pages emitted, or are seriously concerned
! about paper waste, this won't be a problem.
!
That sounds correct, and the idea of the .bp was known to me, as was the
one of putting the keep a little earlier (not always possible).
What annoys me though is that this BUG in -me has probably been around since
kingdom come, and we still have people who have to print a thesis look at
the output, fiddle around with some macros, look at the output, fiddle some
more, ... and so on, because the macros do not do what they purport to.
Not to mention the inherent problems with the .ev command which was discussed
in another article and which demonstrated the horrible things that can happen
when you try to use a pre-processor to troff.
Yet, we (me included) persist with troff and its concomitant
buggy macro packages. I actually switched from ms about 3 years ago
because it was worse. Recently it underwent a face-lift to
give it some of the features which -me already had.
I haven't used mm so I can't comment. At any rate
"me" and "ms" were at least modified to incorporate those features useful
for theses, papers etc. Are we all going to continue living with these incessant
bugs (perhaps fixing a few)? It is lucky we are in the ivory tower, Industry
would have thrown the packages away long ago.
Isaac Balbin
===========================
UUCP: {seismo,mcvax,ukc,ubc-vision}!munnari!isaac
ARPA: isaac%munnari.oz@seismo.css.gov
CSNET: isaac%munnari.oz@australia