Conference vaxuum::online_bookbuilding

    It's undoubtedly the <mark>, <endmark>, etc. tags, as you've already
    guessed. We know there are problems with these tags for the online
    books: it's a wishlist item that we haven't been able to get to yet,
    
    I recently built an online book with change bars and it worked fine:
    seems that sometimes these tags work and sometimes they don't...
    
    You might try processing the book without the <update_range>. I really
    have no idea what this tag will do for online processing but (having
    just looked at the documentation for it) I suspect the worst. The
    reason I've never tried <update_range> is that CUP's policy is that
    online update pages will never be issued (really makes no sense) --
    the entire book will be reissued online when updated. (Customers hate
    update pages anyway, and trees aren't an issue for online books.)
    
    Mary
    
    PS. You might want to check out the ONLINE_BOOKBUILDING notes
    conference, also on CLOSET, which is devoted to online bookbuilding
    problems, issues, wishlist items.

    

	You can also get this error by using the same parameter for
	<LMF> and <LMF_PRODUCT> as I found out quite by trial and error. :-)

				Alfred

I also was getting a PAGE COORDINATION LOST error, and here was how I found
the problem:

I was using the same bookbuilding tools as the rest of my group, none of whom
had any problem like this, so I knew the tools had to be OK.  I had considered 
a number of possible causes, including the previously-mentioned things.  Then
Wayne Grant checked the profile's .TEX and noticed an unpaired ")".  This
character didn't display in either the front matter or the profile, but the 
error was present whenever building the front matter through the profile.  The
front matter built fine by itself, pointing an accusing finger at the profile. 

Finally, I concluded that the error had to be a hidden (non-displaying) 
character that must've gotten in over the network, so I retyped the profile 
from scratch, and it ran beautifully!

So, check your profile's .TEX file, then consider the possibility of a hidden
character.  (The hidden ")" was printing out on the hardcopy, at the upper
left corner of the title page!)

Randy

    I have been getting a PAGE COORDINATION LOST error too, and I have
    investigated all the suggestions in this note and in note 288 to try
    and get to the bottom of the problem.
    
    So far I have:
    
    * Looked for change bars and revision tags - my file contain none of
      either.
    * Checked the LMF information to make sure I was not using the same
      information for the <LMF> and <LMF_PRODUCT> tags.
    * Processed the file for hard copy (it works fine), and printed it out
      - I found some hidden garbage once, corrected it, and it still won't
      process for online.
    * Added some <ONLINE_CHUNK> tags in the longer passages, in case that
      has any effect.
    
    I am now at a loss for what to try next...
    
    Please can someone help me.  The text of my error will be included in
    my next reply.
    
    Ali 

$	DOCUMENT/NOPRINT/CONTENTS/INDEX/KEEP PAD_MAIL ONLINE.HANDBOOK BOOKREADER
%DOC-I-IDENT, VAX Document V1.2-B    25-JAN-1990 11:47:33.75
         .
         .
         .
         .
%DVC-E-PAGECOORDLOST,  PAGE COORDINATION LOST TeXpage = 1, ChunkID = 2
 
%DVC-E-BOOKABORT, aborting run -- book  DISK$HAYCORNS:[MANUALS.VAXPSI.V41.PAD_MAIL.BOOKREADER]PAD_MAIL.DECW$BOOK not created 
-DVC-I-INPUTFILE, input file is: 
   DISK$HAYCORNS:[MANUALS.VAXPSI.V41.PAD_MAIL.BOOKREADER]PAD_MAIL.DVI_BOOKREADER
-DVC-I-ONPAGE, on page [1] 
 

    Hi Alison,
    	It sounds as if there is still a printable character before the
    title.  That's usually the cause of this error message.  Please process
    your file using the /KEEP=TEX qualifier on the command line and send me
    a pointer to the PAD_MAIL.TEX file.  With that, I can hopefully get an
    idea of what the character(s) may be.  Then, knowing the character, we
    can look into your .SDML files to find the culprit.
    
    Thanks,
    	Wayne

    Wayne and I communicated by MAIL, to sort this out.  It turned out
    that the problem was a file called DSRREQ.SDML which was still hanging
    around from my having converted the file from DSRPLUS to VAX DOCUMENT.

    The file contained only a couple of lines of commented information, plus
    a <LINE> tag, and it was the <LINE> tag that caused the problem.  As far
    as my <TITLE> tag was concerned, there were some extra characters due to
    the <LINE> tag, but when I printed out the hard copy I could see no sign 
    of them!

    The file now processes fine.  Thank you Wayne for your help.

    Alison

    I'm getting the page coordination error message when I try to build
    an online version of a book.  In fact, I get the error message that's
    used as an example in Section 6.2.1 of VAX DOCUMENT:Producing Online
    and Printed Documentation.  However, I checked (and even retyped) the
    title page and made sure there were no tags generating text before
    the <TITLE_PAGE> tag.  I also looked at the other hints in this note
    and couldn't find anything that made it work.  
    
    Before the page coordination lost error message, I get the following
    warning messages:
    
    %TAG-W-DUPHIDNAM, tag <HIDE_TAGS>, line 294, file DOC$STANDARD_FORMATS:
    TAG$ONLINE.STT
    A <HIDE_TAGS> is reusing the hide_name, _DECW_HT_CMDSECHD_TAG
    
    
    %TAG-W-DUPHIDNAM, tag <HIDE_TAGS>, line 305, file DOC$STANDARD_FORMATS:
    TAG$ONLINE.STT
    A <HIDE_TAGS> is reusing the hide_name, _DECW_HT_SUBCMDSECHD_TAG
    
    %TEX-W-UNDEFINEDCS, Undefined control sequence
    %TEX-I-LINE, Error occurred on or around line number: 2
    %TEX-I-SHOWCONTEXT, '\onlinetoolsid'
                                   {VAX DOCUMENT T2.0-1}
    %TEX-I-FILENAME, 'USER$G:[GOLDMAN.STATS]SUG_PRO.TEX;5
      -TEX-I-ONPAGE, on page [1]
    
    
    The book built normally in hardcopy. Any suggestions?  Are there
    other files I should be checking for hidden characters?
    
    Thanks,
    Eliot

    The undefined control sequence \onlinetoolsid in the .tex file is
    throwing text into the output (because it's undefined, much as an
    undefined tag will end up as text in the output). \onlinetoolsid is
    written automatcally into the .tex file (before the title page) to
    identify the authoring tool that created the book.  (All of which is
    to say that the problem has nothing to do with your SDML coding.)
    
    The question is, why is \onlinetoolsid undefined? From looking at your
    log file fragments, it appears that you are running T2.0 but the wrong
    files are being read in for tag definitions and TeX macros. Under T2.0,
    there should be no tag$online.stt; that's an old V1.2B file name. I
    suspect that's also why you're getting the <hide_tags> message (which is
    actually harmless, but does indicate that something is wrong here...).
    
    The \onlinetoolsid control sequence is defined in the file
    doc$standard_format:tex$s_online.design. Is that file in your
    doc$standard_formats dir? It's not the one being called in.
    
    Could you send me a complete log of your command line and all the
    error messages issued during processing?
    
    Also, make sure that your T2.0 installation completed successfully,
    that all the correct .stt and .design files are in
    doc$standard_formats, and that the correct doc$designs.dat and
    doc$destinations.dat files are in doc$standard_formats.
    
    Have you defined the logicals doc$personal_formats or doc$local_formats
    and could there be doc$designs.dat and doc$destinations.dat files in
    those directories that are trashing the T2.0 stuff in
    doc$standard_formats?
    
    Mary

    I ran across that notorious PAGECOORDLOST error today while trying to
    build a BOOKREADER file and it took me about 4 hours to track down the
    cause: some printing characters in the profile file.  
    
    My request to the BOOKREADER developers is to please trap these
    PAGECOORDLOST errors more effectively.  BOOKREADER seems to stumble on
    errors that DOCUMENT takes in stride when building for print
    destinations.  If the problem is that BOOKREADER fails if text appears
    ahead of a <title> tag, then report this during the TEX processing, not
    as the last thing before producing the output file!  If there's one
    thing I can't stand about creating BOOKREADER files, it's that final
    bomb.
    
     
    Here are the only -E- messages I got when the problem first appeared:
    -----------------------------------------
    [ D e v i c e    C o n v e r s i o n ]...
    
    %DVC-E-PAGECOORDLOST,  PAGE COORDINATION LOST TeXpage = 1, ChunkID = 2
    
    
    %DVC-E-BOOKABORT, aborting run -- book 
    SYS$LOGIN_DEVICE:[FRASCINELLA.DECIMAGE--DVC-I-INPUTFILE, input file is:
    
       SYS$LOGIN_DEVICE:[FRASCINELLA.DECIMAGE-UG]DECIMAGE-USER-GUIDE.DVI_BO
    OKREADER -DVC-I-ONPAGE, on page [1]
    -----------------------------------------
    
    I tried a different online doctype, with and without /contents
    on the command line, going through the front matter file and deleting
    every possible space at the end of lines and in between, but to no
    avail.
    
    I looked through the DOCUMENT notes file and then this one looking for
    a ray of hope.
    
    Finally, since the problem seemed to be in the front matter, I ran just
    the front matter file through BOOKREADER.  It worked!  
    
    This meant there was something different between running the front
    matter and running the whole book.  The only difference was the profile
    file. I edited the profile file again and carefully looked at it.  At
    the top of the file, to the left of a <comment> tag block that I usually 
    ignore, were the characters "sq" as shown here.
    -----------------------------------------------------------
    sq<comment>              BOOK BUILDING FILE FOR
                           DECimage System One User's Guide
    
    <endcomment>
    
    
    <profile>
    .
    .
    .
    ------------------------------------------------------   
    Once I removed "sq" the BOOKREADER created the online book.
    
    I can only guess that, in moving from one window to another, and in and
    out of files, I typed some characters in one window and they
    inadvertently were carried over into the profile file when I switched
    windows.
    
    Again, I wish that DOCUMENT had provided better help on the
    problem.  TeXpage = 1 and ChunkID = 2 were really inadequate.
    
    Yours,
    
    Michael F.

    The tag translator has historically only had the ability to
    "translate tags".  The rest of the input file is not "seen"
    by the "intelligent" part of the software.  Instead, everything
    in the input file (SDML) just gets shuffled to the output file,
    until another tag is "seen".  Then the intelligent part of the
    software is given the tag and it goes about "translating it".
    
    That's why we can't slap the writer's wrist for putting two
    <p> tags in a row, without supplying the text that should 
    follow every <p> tag.  And it is the same reason that we
    can't diagnose the missing <p> tags after things like
    <head1>(...), <endtable>, etc.
    
    We are working on putting some rudimentary ability to detect
    the presence and absence of text between the tags, which will
    allow us to detect those stray characters that occurred in
    your profile file.  But retrofitting that ability into the
    tag translator and then modifying the tag definitions to use
    the information about the presence or absence of text inbetween
    the tags is tricky and time consuming.  It is being done, but
    isn't at the releasable stage.
    
    Sorry.  I understand the frustration of having to try a zillion
    things before you find the problem, and feeling that it would
    have been so easy if there was an error message that pointed
    at it.          
    
    Bill

    Thanks, Bill for the fact that you're working on the problem.  If this
    problem will exist in DOCUMENT V2.0 when shipped, your
    writers should add something about this problem to chapter 11,
    Diagnosing Errors in an Online Book, to the book, "Producing
    Online and Printed Documentation."  That chapter should also point the
    reader to Appendix B, Messages in the "Using Global Tags" book. Users
    won't have our notes files to root around in so it would be good to put
    something in a manual. 
    
    I'm still curious as to why the page coordination problem kills the
    bookreader output but not the PostScript or other printable output.

    
>>>    I'm still curious as to why the page coordination problem kills the
    bookreader output but not the PostScript or other printable output.

    You're comparing apples and oranges. Just because a car will run
    on diesel fuel doesn't mean it will run when regular gasoline is put 
    in the gas tank.

    Different display mediums have different constraints. You as the writer
    or editor are the final arbitor of what the printed output looks like
    both structurally and content wise. Content wise Bookreader doesn't care
    structurally it does. Thus the Bookwriter routines are quite harsh in 
    enforcing what the bookreader requires for structure.   

    TEX pages and Bookreader internal units are mapped one for one, when we
    get PAGE COORDINATION LOST it usually means the TEX page has for some 
    reason been reset to one.  While two page ones might not effect printed 
    output it would effect the Bookreader output (probably in a very negative 
    way).   

    

Mike