| This sounds like a known bug in the 5.3 Bookreader. If you have LMF info
in the book (the BOOKINFO utility will tell you the actual license(s) needed
to read the book) and don't have an appropriate license installed on the
node running the Bookreader, it will hang. NOTE that the appropriate
licence (usually BOOKBROWSER will do) must be installed on node actually
running the Bookreader--if the display node is different, it will not help
having the license installed there.
joe
|
| The problem apparently is related to using the LMF tags in a profile or
symbol file. I got around the problem by using a single file for the whole
book -- definitely a short-term solution.
Here is the block of tags that I moved from place to place trying to solve
the problem:
<DEFINE>(component\SIT Library)
<DEFINE_BOOK_NAME>(book_name\SIT Library Reference)
<LMF>(BOOK_NAME)
<LMF_PRODUCER>(dec)
<LMF_PRODUCT>(sit)
<LMF_RELEASE_DATE>(0)
<LMF_VERSION_NUMBER>(0)
<LMF_ALTNAME>(bookbrowser)
<ENDLMF>
When I put these tags after the <PROFILE> tag, the book build failed with
the following message:
%TAG-E-NOTINELEM, tag <DEFINE_BOOK_NAME>, line 15, file
ACES4$:[SEALY.SAFE.SITLIB]SITLIB_PRO.SDML;
Tag can appear only within the context established by
an element heading tag such as <CHAPTER>, <PART>, etc
When I put the tags in a symbol file, or before the <PROFILE> tag, or after
the <FRONT_MATTER> tag, the book build completed successfully, but the
strange behavior I reported in .0 occurred.
I don't think the BOOKBROWSER license is the problem. Can anyone explain
or offer a better work-around?
Thanks, Joe, for identifying the LMF tags as the likely cause of the
problem.
--Steve
|
| What does the BOOKINFO utility list for licenses in the book? Does it list
SIT with BOOKBROWSER as an alternate? Is at least one of these PAKs
installed on the node actually running the Bookreader? (as opposed to the
Workstation where it is being displayed?). If not, you WILL see the
behaviour you describe when trying to read the book with the V5.3 Bookreader.
joe
p.s. if an appropriate licence is installed, and you still see the
behaviour you describe, please send me a pointer to the book
|
| RE .2: The original problem seems to be solved but there I think it's
worth noting that the <define_book_name> error message --
%TAG-E-NOTINELEM, tag <DEFINE_BOOK_NAME>, line 15, file
ACES4$:[SEALY.SAFE.SITLIB]SITLIB_PRO.SDML;
Tag can appear only within the context established by
an element heading tag such as <CHAPTER>, <PART>, etc
occurs for *both* online and hardcopy and has nothing to do with
the LMF tags, but with the way the tag translator processes profiles.
At the bottom of the note is an explanation by Bill Kohlbrenner about
why this is the case.
In addition, you should be using <define_symbol>(component\...),
not <define>.
Mary
*****************************************************************
From Bill Kohlbrenner:
A symbol-defining tag, like <define_book_name> must be placed
in the book's files in such a way that it is "within" an element
of the book or it is in element "0", that is, in no element.
Every symbol belongs to a specific element, or to no element,
by the fact that it has associated with it (in the symbol table)
an element number.
Until we get to the <chapter> or <front_matter>, etc tag, we
are still in the "preceding" element. Suppose the first two tags
in the third element of the book look like this:
<define_book_name>(pooh\The Pooh Book)
<chapter>(The Honey Pot\honey_pot_chap)
During a bookbuild, the "pooh" symbol will be entered into the symbol
table with element number 2. Then we encounter the <chapter> tag,
increase the element number to 3 and enter the "honey_pot_chap"
symbol with element number 3. All subsequent symbols in this chapter
will have element number 3 associated with them.
When it comes time to do an element build, we find the <chapter> tag,
look up its symbol, find the corresponding element number and delete
all symbols that have the same element number. That clears the symbol
table of all existing symbols from element number 3. Then we start to process
the element and as we insert symbols from this chapter we encounter
no DUPSYMBOL problems. However, if the <define_book_name> tag precedes
the <chapter> tag it will give us a DUPSYMBOL error because it is
encountered before the <chapter> tag, that is, before the symbols for
this chapter have been deleted. An even worse problem occurs if we
do an element build on the preceding chapter! The symbol "pooh" belongs
to the preceding chapter, so it gets deleted from the symbol table when
the preceding chapter is rebuilt in an element build. But the element
build on chapter 2 will not reenter the "pooh" symbol because the
<define_book_name> tag is in the file that contains chapter 3.
In order to avoid all these problems, we made the rule that an element-heading
tag, such as <chapter>, <appendix>, etc must precede all major tags
(including the symbol defining tags) in each element.
Bill
|