Re: Publisher 2000

["Rick Quatro" <frameexpert@xxxxxxxxxxxxxx>]

Susan,

Here are the technical details why element cross-references and TOCs don't
work in WebWorks:

When you create a TOC with paragraphs (not elements), each entry has a
Hypertext marker in the form:

openObjectId filename.fm:2 1013415

What appears after the colon is the key. In the example above, the number
"2" identifies the source as a paragraph. The seven-digit number is the
"unique identifier" of the source paragraph. Every paragraph (and many other
items) in FrameMaker has a unique ID. The "$AUTOTAG;" building block in
WebWorks captures this unique ID for a paragraph so that it can be the
destination of a hypertext link; for example,

<a name="1013415"> </a>

WebWorks uses the Hypertext marker text in the TOC to make the hypertext
link:

<a href="$LINKFILE(html, name);#$LINKTAG;"> [translates to:] <a
href="filename.html#1013415">

A similar mechanism is used for paragraph (and spot) cross-references. Now,
here is the problem with element cross-references and TOCs:

When you create a TOC with elements, each entry has a Hypertext marker in
the form:

openObjectId filename.fm:5 656356

This time, a "5" after the colon identifies the source as an ELEMENT, not a
paragraph. The unique ID following is the ID of the source element. This
information does not get transfered to WebWorks. There is not always a
one-to-one correspondence between elements and paragraphs, since an element
can contain more than one paragraph. Element cross-references are similar;
they use elements (and attributes) to maintain the links, and this
information is lost going to WebWorks.

What are the solutions? The TOC problem can be solved by choosing paragraphs
instead of elements for your TOCs. This is generally not a problem in
Frame+SGML because your generated files are not usually structured, anyway.
Element cross-references pose more of a problem, because they use SGML
attributes to mark both ends of the cross-reference. You will most likely
need this information if you need valid SGML output. However, if your only
electronic use of the files is HTML via WebWorks (and PDF), you should use
paragraph cross-references instead of element cross-references.

I have a FrameScript script that converts element cross-references to spot
cross-references and back again. However, at this point it only works with
single documents; it can't convert cross-references to other files. When (or
should I say, if) FrameScript adds support for SGML objects, this will be
much easier to accomplish. This could also be done with an API client via
the Frame Developers Kit (FDK). It would make a nice plug-in for Quadralay
to bundle with WebWorks.

Rick Quatro
Carmen Publishing
frameexpert@mindspring.com
FrameScript Information at http://www.mindspring.com/~frameexpert


>      Your message raised a red flag for me -- we're about to implement a
>      frame+SGML publishing system, and are leaning toward WebWorks to
>      generate HTML.
>
>      It doesn't preserve element cross-references? So hyperlinks generated
>      from cross-refs created with Frame's cross-reference formats are not
>      possible?
>
>      I've perused Quadralay's www site, but couldn't find any detailed
info
>      on this.
>
>      Thanks for the tip -- more information is always a good thing.
>
>      Susan


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **