[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxuum::document_ft

Title:DOCUMENT T1.0
Notice:**New notesfile (DOCUMENT.NOTE) now available (see note 897)**
Moderator:CLOSET::ADLER
Created:Mon Feb 09 1987
Last Modified:Thu Oct 31 1991
Last Successful Update:Fri Jun 06 1997
Number of topics:897
Total number of notes:4397

41.0. "LINE_PRINTER bug with <figure*>tags ?" by GRAMPS::MYERS () Mon Mar 02 1987 10:14

    
    I am having a problem with the LINE_PRINTER destination.  When I
    process a source file (using the SOFTWARE.REF doctype) using the
    LINE_PRINTER destination, the text formatter seems to go on
    forever.  Examining the .LIS file shows that the page numbers are
    simply increasing upwards into the thousands.  If I process the
    file using the LN03 destination, everthing works OK.  If I
    examine the .TEX file, there seems to be no problem (that I
    can recognize).
    
    I tried to isolate the culprit tag but to no avail.  The only thing
    I could determine is that it appears to be related to the
    <figure*> tags.
    
    Any ideas ?
T.RTitleUserPersonal
Name		DateLines
41.1<figure> bugCLOSET::ANKLAMFri Mar 13 1987 11:3117
    
    This was not a line printer bug per se. It is a bug in T1.0, which
    has been found and fixed. The problem is that:
    
    <figure>
    <figure_attributes>(multipage)
    <code_example>(Keep)
    
    causes the infinite loop *when* the example is indeed too big for
    a single page (line printer bombs more frequently because fewer
    lines fit on the page). Until the update, you can work around this
    by removing the <figure_attributes>. You will get page that are
    too long, but at least you will know what needs to be fixed.
    
    patti anklam
41.2My problem!CHAPLN::ROSENTHALI REALLY need a vacation!Wed Jun 17 1987 12:3128
    
    Good heavens!  A note that mirrors a problem I've been wrestling
    with for the last 2 days!
    
    I was trying to do the same thing... LINE destination, S.R doc-
    type...
    
    I submitted a BATDOC job at 6:30 last night.  When I logged in
    from home at 7:00 this a.m., I check the .LIS file... there were
    problems inside my Chapter 7... it managed to go all the way 
    through page 7-34763... I realized there was a problem!  The
    .DVI_LPR file was almost 22,000 blocks long!  And it was STILL
    processing...
    
    I've taken out all the attributes stuff and am BATDOC-ing again
    now... I hope it works... the book's supposed to get added onto
    a distribution tape TODAY!
    
    The only question I have now, Patti, is this:  I needed to ADD
    the multipage attribute to get an .LN3 file (this was explained
    to me by you in a reply from a note I wrote a few days ago.)
    I always have to produce .LNO, .LN3 and .LPR versions of the
    same .GNC file.  Does this mean I have to edit the attributes
    out of the .GNC file each time BEFORE I try to get an .LPR
    file?
    
    donna
41.3KEEP was the killerCLOSET::ANKLAMThu Jun 18 1987 10:269
    
    Donna, you shouldn't have to recode your file. The loop occurred
    when (KEEP) was specified on the <code_example>. In your corrected
    files, you should just have <example_attributes>(multipage) followed
    by <code_example> or <display>, no explicit <page> tags in the
    examples, and it should work for all output devices. 
    
    patti