Conference vaxuum::online_bookbuilding

    I posted this note in the DOCUMENT notes file... now that I am aware of
    needing to look in this notes file, I believe that note 290.* contains
    the answer to my problem as well....
    
    Never mind....
    
    
    Judy
    

    make that 291.*
    
    Judy

    Actually,
    
    While, I am receiving the same error as in note 291.0, I have already
    commented out all of the footnotes in this file.  Plus, I have been
    successful in compiling another book using the ONLINE.REFERENCE doctype
    and this book contains many footnotes.
    
    Any other suggestions?
    
    Judy
    

    Note 291.7 reports that the error is in the way the converter handle
    <online_title> strings of more than 48 characters. Are you using
    this tag?
    
    Mary

If you're not using the <online_title> tag with more than 48 chars (291.7) 
then send me a pointer to the dvi files

MIke

    
Here are the filenames for the .dvi* files for the book that is giving me
problems.

-----------------------------------------------
On node
    
    BUCKY::
    
Directory 
    
    BUCKY$DUA1:[GERBERG.IVCS.SHELL_GUIDE]
    
Files
    
    
PROFILE.DVI_BOOKREADER
PROFILE_CONTENTS.DVI_BOOKREADER
PROFILE_INDEX.DVI_BOOKREADER
     
--------------------------------------------------

The pathname for the profile.log file is


PROFILE.LOG


in the same directory. 

Judy Gerberg

    Well, thanks to Mike and Wayne's help, this problem is now solved.
    
    First, I had included an <lmf_alternate>() tag without specifying an
    alternate name. I had intended to fill it in later. I had to delete
    this. 
    
    Then, I had accidently put a hyphen in BOOK-BROWSER which I fixed.
    
    
    Once I made these changes, the error DOCUMENT gave me changed.
    
    This error looked like this the following error.
    
    
    %DVC-E-PAGECOORDLOST, PAGE COORDINATION LOST TeXpage = 1,ChunkID = 1752201577
    
    
    Then Wayne noted that I had used an underscore in my product name as an 
    argument to the <lmf_product>(DECWINDOWS_WORKFLOW-MANAGER). By replacing the
    underscore with a hyphen, my book compiled.
    
    The funny thing to me is that I had used the same series of <lmf..>
    tages for 4 different manuals, but only 2 of them gave me this error.
    The other two compiled fine.
    
    But, by changing the underscore to a hyphen, now the other 2 compile
    fine as well.
    
    Plus Wayne notified me that product names are limited to 24 characters.
    Since I am not yet sure of the legal name of my product, this may not
    be a problem for me in the long run.
    
    Thanks much for solving my problem, Wayne and Mike.
    
    
    

    After fixing my previous problem, I found that the Bookreader would
    hang when I tried to open one of my books.  I had to stop the
    Bookreader process in order to continue.  I found that by <COMMENT>ing
    out the <LMF> tags, my books would still compile with the online.*
    doctypes, and I could then view them in the Bookreader.
    
    Does anyone know of any reason why <COMMENT>ing out the <LMF> tags
    would be a problem somewhere else?
    
    Judy Gerberg 

    See topic 330 in this notes conference.  It may be the answer to your
    problem.
    
    Wayne

    I don't think that is my problem because
    
    1) I asked my system manager about that last week when I had the
    original problems. He said that this was done already...
    
    2) I could read the 3 other books in the same doc set as the one that I
    couldn't open. Wouldn't I have had the same problem with all 4 books?
    
    Judy

    Yes, you should have had problems with all 4. I'm assuming the LMF tags
    were coded the same way for all four document: doublecheck this, as the
    the problem noted in 330 is the *only* instance that we know about
    where the Bookreader hangs. If you are still having problems after you
    doublecheck your LMF tags, please send me your frontmatter .SDML file
    and the LMF tags as you have them coded (if they are not in the same
    .SDML file).
    
    Thanks,
    
    Mary

use the BOOKINFO utility that came with 1.2B to see that you have (correct)
LMF info in the books.

joe

    Okay, I used the BOOKINFO utility and found out that all of the LMF
    information matched. But, I realized that 3 of the 4 books Symbolic
    Names were wrong.  I figured out that I had been using the
    <define_symbol> tag for all symbols. I hadn't realized that there was a
    <define_book_name> tag. So, I edited all 4 of my books and used the
    <define_book_name> tags, and deleted the surrounding <comment> tags
    from around the <lmf> tags and I am now recompiling. I will let you
    know how it turns out.  
    
    But, it looks like I created my own problems by using the wrong tag.
    
    Thanks for your help.
    
    Judy
        

    This problem was taken offline, and the net result is that Judy
    had several problems going simultaneously and they had to be
    sorted out.
    
    1. At my suggestion, Judy asked her system manager to go through
       the process of installing the BOOKBROWSER PAK on her system
       and it turned out that, indeed, it had not been installed in
       the first place. After that, she could read the book that was
       hanging.
    
    2. There was no LMF information in her other three books because
       the symbol names specified for <LMF> and for <TITLE>(<REFERENCE>())
       did not match. 
     
       For example, in one of her profiles she specified <LMF>(WFM_BOOK) 
       and in the frontmatter for that book specified
       <TITLE>(<REFERENCE>(SHELL_GUIDE)).
    
       This resulted in the 'no LMF information' message and BOOKINFO's
       report that there was no LMF information in the book.
    
       When I changed the profile to <LMF>(SHELL_GUIDE) all was well.
    
    3. BOOKINFO also reported bogus book symbol names. This was because
       of the presence of part pages in those documents -- in 1.2B, the
       <TITLE> tag in part pages trashes the book symbol name. This bug
       has been fixed for the next release. Since the BOOKREADER, at
       present, does not use the book symbol, this is a harmless error.
    
    Mary

    Is there an online doctype that does not force you to use Chapters in
    Bookreader?  Something like the Report doctype, where you can use just
    headers?
    
    -Rob

    You can just use headers with the online doctypes (I do it all the time
    in test files...). You can also use <unnumbered_heads>.
    
    However, if we must enforce header heirarchies to support the V3
    Bookreader (this is a Bookreader-specific requirement on authoring
    tools; see note 382), then we may need to enforce the use of <chapter>
    (but certainly doctypes that do not require <chapter> tags could be
    develped: the REPORT doctype is on the online doctype wishlist).
    
    Mary

    I'm using CUP.ONLINE and if I don't use the chapter tag, I get lots of
    errors, telling me I can't use header tags.  <Unnumbered_heads> does
    not affect chapter numbers, at least not in this doctype.  
    
    What other online doctypes are being used?  I can't seem to find a
    definitive list, and what works with what.
    
    -Rob

    The online doctypes on V1.2B are:
    
      ONLINE.REFERENCE and ONLINE.HANDBOOK
    
    They were modelled on software.reference and software.handbook, but
    over time were modified until there were only one of two differences
    between the two doctypes (some font specs, I think, maybe a tag or
    two). There's also ONLINE.ADA but that's only of interest to a couple
    of people.
    
    CUP.ONLINE is provided on the local kit.
    
    For V2.0, the online doctypes are:
    
    SOFTWARE.ONLINE
    MANUAL.ONLINE
    MILSPEC.ONLINE
    
    SOFTWARE.ONLINE and MANUAL.ONLINE are actually identical: they are both
    provided for ease of use -- if you use SOFTWARE.REFERENCE to build your
    hardcopy manual, using SOFTWARE.ONLINE to build the online version
    seems to make sense. Keep it in the family, so to speak. The doctype(s)
    are based on CUP.ONLINE, rather than the earlier doctypes, because we
    felt that CUP.ONLINE was a better design. (But there are things in the
    local doctype that are not SOFTWARE/MANUAL.ONLINE, some tags I think,
    and apparently the inability to use headers without a chapter tag.)
    
    CUP.ONLINE does not work on DOCUMENT T2.0 -- GS is developing a local
    V2 kit but it's not ready yet.
    
    No, <unnumbered_heads> does not affect chapter numbering in any of
    these doctypes. (I only mentioned that because suppressing chaptering
    (if that's a word) and suppressing section numbers somehow seem to
    go hand-in-hand.)
    
    Does this help?
    
    Mary
    

For CUP.ONLINE try :

<DOCUMENT_ATTRIBUTES>
<SET_HEADINGS>(UNNUMBERED)
<ENDDOCUMENT_ATTRIBUTES>

The documentation for CUP. doctypes should be on
DOC$LOCAL_FORMATS:CUP$LD_FAMILY_PRO.PS or DECW$BOOK