Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XSL-FO] Linking to/from SVG and FO Content--How Should It Work?

Expand Messages
  • Eliot Kimber
    ... mydoc.fo That is the resource being processed. As part of the FO-to-PDF output, the FO processor must again rewrite the pointers to reflect what things
    Message 1 of 13 , Sep 21, 2005
      Jirka Kosek wrote:

      >>But I think you should also be able to use external-destination to point
      >>to an instream SVG using the logic that pointing to yourself should be
      >>the same whether you do it by including a filename or by using just a
      >>fragment identifier.
      >
      >
      > I'm not sure about this. How would you know that you are pointing to
      > yourself? By external-destination="mydoc.fo" or
      > external-destination="mydoc.pdf" or external-destination="mydoc.ps"?

      mydoc.fo

      That is the resource being processed.

      As part of the FO-to-PDF output, the FO processor must again rewrite the
      pointers to reflect what things become in the PDF, i.e., PDF anchors,
      with whatever names, and PDF link annotations to those anchors.

      Cheers,

      E.


      --
      W. Eliot Kimber
      Professional Services
      Innodata Isogen
      9390 Research Blvd, #410
      Austin, TX 78759
      (512) 372-8155

      ekimber@...
      www.innodata-isogen.com
    • Jirka Kosek
      ... But AFAIK current FO processors don t do this. They just pass URL in external-destination from FO to PDF file. -- ... Jirka Kosek e-mail:
      Message 2 of 13 , Sep 21, 2005
        Eliot Kimber wrote:

        >>I'm not sure about this. How would you know that you are pointing to
        >>yourself? By external-destination="mydoc.fo" or
        >>external-destination="mydoc.pdf" or external-destination="mydoc.ps"?
        >
        >
        > mydoc.fo
        >
        > That is the resource being processed.
        >
        > As part of the FO-to-PDF output, the FO processor must again rewrite the
        > pointers to reflect what things become in the PDF, i.e., PDF anchors,
        > with whatever names, and PDF link annotations to those anchors.

        But AFAIK current FO processors don't do this. They just pass URL in
        external-destination from FO to PDF file.

        --
        ------------------------------------------------------------------
        Jirka Kosek e-mail: jirka@... http://www.kosek.cz
        ------------------------------------------------------------------
        Profesion�ln� �kolen� a poradenstv� v oblasti technologi� XML.
        Pod�vejte se na n�� nov� spu�t�n� web http://DocBook.cz
        Podrobn� p�ehled �kolen� http://xmlguru.cz/skoleni/
        ------------------------------------------------------------------
        Nejbli��� term�ny �kolen�: DocBook 5.-7.12. * XSL-FO 19.-20.12.
        XSLT 17.-20.10. * XML sch�mata (v�etn� RELAX NG) 7.-9.11.
        ------------------------------------------------------------------



        [Non-text portions of this message have been removed]
      • Eliot Kimber
        ... Hmm. That s a problem. The FO processor should be examining the value of external-destination to determine if it is pointing into a resource it knows
        Message 3 of 13 , Sep 21, 2005
          Jirka Kosek wrote:
          > Eliot Kimber wrote:
          >
          >
          >>>I'm not sure about this. How would you know that you are pointing to
          >>>yourself? By external-destination="mydoc.fo" or
          >>>external-destination="mydoc.pdf" or external-destination="mydoc.ps"?
          >>
          >>
          >>mydoc.fo
          >>
          >>That is the resource being processed.
          >>
          >>As part of the FO-to-PDF output, the FO processor must again rewrite the
          >>pointers to reflect what things become in the PDF, i.e., PDF anchors,
          >>with whatever names, and PDF link annotations to those anchors.
          >
          > But AFAIK current FO processors don't do this. They just pass URL in
          > external-destination from FO to PDF file.

          Hmm. That's a problem. The FO processor should be examining the value of
          external-destination to determine if it is pointing into a resource it
          knows something about (i.e., the input FO, included graphic objects,
          etc.) or something it doesn't (anything that is not the FO instance or
          an FO-defined or SVG-defined dependency on it). There is no other way
          that FO processors could, for example, implement links from the FO to
          SVG graphic objects in external SVGs.

          Note the implication here: In an FO processor that also does SVG
          processing, it must build a list consisting of the FO instance itself,
          any SVG documents it points to, and any SVG-related resources those SVG
          documents point to (i.e., embedded rasters, components in other SVG
          documents). All of these objects are part of the "compound document"
          rooted at the FO instance and the FO engine must be prepared to directly
          handle the processing of links to and from any of them.

          But there are still cases where the only thing the FO engine should have
          to do is pass the value straight through. But that then raises the
          question of what value to pass through? Which I think was Jirka's
          original question, applied to the more general case.

          That is, in the specific case of links between an FO instance and SVG
          graphics included in that FO instance, either instream or external,
          there's no reason for an FO processor *not* to recognize that the
          external-destination is in fact to that FO instance or one of its
          included SVG graphics and do the right thing.

          But when the external destination is to a resource that is entirely
          outside the scope of the FO instance and its dependencies, then I agree
          that there's not much it can do but pass it straight through. This is
          because the responsibility for determining the right ultimate target
          address lies with the processor that generates the FO, not the FO
          renderer itself.

          For example, consider the case where you have two "units of
          publication", Doc_A and Doc_B. These units of publication represent,
          logically, the final rendered result (for example, two manuals within a
          set of manuals for a single product) in whatever form they might be
          rendered (PDF, HTML, online help, etc.).

          Each unit of publication will be composed of many separate components,
          i.e., XML source for the text, SVG graphics, etc. Some of these
          components may be use in multiple units of publication.

          Again we quickly realize that the links must be constructed in the
          source data in terms of the data *as authored*, because again that's all
          we know about for sure and because there may be a one-to-many
          relationship between source objects and renditions of those source objects.

          For consider the scenario where you have a component of Doc_A that needs
          to link to a component of Doc_B. The link as authored will be from an
          element in the source for Doc_A to an element in the source for Doc_B, i.e.:

          doc_a.xml:

          <?xml version="1.0"?>
          <doc>
          ...
          <link href="doc_b.xml" xpointer="sect-a">...</link>
          ...
          </doc>

          doc_b.xml:

          <?xml version="1.0"?>
          <doc>
          ...
          <sect id="sect-a">...</sect>
          ...
          </doc>

          In order to make this link from Doc_A to Doc_B a working link in the
          final PDF you must know, at the time you generate the PDF for Doc_A,
          what the PDF anchor for the PDF rendering of <sect> sect-a is. The FO
          renderer cannot know this because it doesn't know anything about any PDF
          rendered from Doc_B (it only knows about the FO instance it is rendering
          at the moment).

          So what will the processing of Doc_A look like?

          First, we transform doc_a.xml into FO. As part of this we have to
          transfrom the <link> element into an <fo:basic-link with an
          external-destination= value.

          The challenge here is that the working link in the final PDF for Doc_A
          must point to a named anchor in the PDF rendering of Doc_B. How can we
          know what the name of the anchor for the PDF rendering of <sect> sect-a is?

          There are only three posibilities as far as I can determine:

          1. The generation of PDF anchor names is deterministic based on some
          value provided in the FO instance, either FO IDs or some
          FO-engine-specific bit of information (i.e., an "anchor-name=" attribute).

          2. The FO engine generates the anchor names but then writes out a "side
          file" that maps IDs in the FO to anchor names in the PDF. From this you
          can map back to the original XML elements by having your FO generation
          process write out the mapping from elements in specific source files to
          the IDs generated for them in a specific FO instance.

          3. A variant of (2): You put the ID-to-name mapping in the PDF itself
          and then extract it as a post process.

          I'm pretty sure no FO implementation does (2) but they may do (1) and
          (3) is always doable using the sort of technique Ken Holman uses for
          back-of-the-book index generation.

          So at this point we can presume that we have a mapping from original XML
          source document/element ID pairs to PDF anchor names in specific
          renderings of those XML elements (that is, the elements in the context
          of specific renderings of specific units of publication).

          In our simple case here, we will have this mapping entry, created as a
          side effect of rendering unit of publication Doc_B to PDF:

          Source Doc | Elem ID || Unit of Pub | Rendition | Anchor Name |
          -----------|---------||-------------------------|-------------|
          doc_b.xml | sect-a || Doc_B | Doc_B.pdf | anch_00234 |


          Note that a basic aspect of XML is that document/ID pairs provide unique
          addresses for every XML element in the universe (where by "document" I
          mean a specific physical storage object containing an invariant XML
          document). That is, every element instance exists in exactly one
          document and every document is, by definition, an addressible object.
          Therefore every element can be addressed in terms of its location with a
          specific document.

          Note also that "Doc_B.pdf" really has to be an absolute location or an
          relative path that is in a known relationship to all other PDFs that
          might be rendered and that might link to it, otherwise, short of
          server-side redirection of URLs embedded in the PDFs or rewriting of
          URLs in the PDF when its location is moved (which is doable), there is
          no way to create reliable PDF-to-PDF pointers. For this example we can
          assume that all the PDFs are published in the same directory just to
          keep it simple.

          Given the mapping shown above, we can implement our XSLT process so that
          we can generate a PDF-specific external destination value at FO
          generation time:

          doc_a.fo:

          <?xml version="1.0"?>
          <fo:root>
          ...
          <fo:basic-link
          external-destination="Doc_B.pdf#anch_00234">...</fo:basic-link>
          ...
          </fo:root>

          Now the FO engine can pass the value of external-destination straight
          through and it will work as long as our mapping table was correct.

          Cheers,

          Eliot
          --
          W. Eliot Kimber
          Professional Services
          Innodata Isogen
          9390 Research Blvd, #410
          Austin, TX 78759
          (512) 372-8155

          ekimber@...
          www.innodata-isogen.com
        • Jirka Kosek
          ... Seems that we are moving away from original topic, but still in interesting direction. ... XEP uses id value as PDF anchor name. AFAIK other FO
          Message 4 of 13 , Sep 21, 2005
            Eliot Kimber wrote:

            > The challenge here is that the working link in the final PDF for Doc_A
            > must point to a named anchor in the PDF rendering of Doc_B. How can we
            > know what the name of the anchor for the PDF rendering of <sect> sect-a is?

            Seems that we are moving away from original topic, but still in
            interesting direction.

            > I'm pretty sure no FO implementation does (2) but they may do (1) and
            > (3) is always doable using the sort of technique Ken Holman uses for
            > back-of-the-book index generation.

            XEP uses id value as PDF anchor name. AFAIK other FO implementations do
            same thing.

            > Given the mapping shown above, we can implement our XSLT process so that
            > we can generate a PDF-specific external destination value at FO
            > generation time:

            If anyone is curious, for DocBook this was already implemented

            http://sagehill.net/docbookxsl/Olinking.html

            BTW: Eliot, have you asked RenderX or Antenna House about implementing
            links from SVG to FO at least in the simplest case when SVG images are
            placed as instream-foreign-objects and links are using just fragment
            identifiers? It shouldn't be hard to implement. Is any FO engine vendor
            listening here?

            --
            ------------------------------------------------------------------
            Jirka Kosek e-mail: jirka@... http://www.kosek.cz
            ------------------------------------------------------------------
            Profesion�ln� �kolen� a poradenstv� v oblasti technologi� XML.
            Pod�vejte se na n�� nov� spu�t�n� web http://DocBook.cz
            Podrobn� p�ehled �kolen� http://xmlguru.cz/skoleni/
            ------------------------------------------------------------------
            Nejbli��� term�ny �kolen�: DocBook 5.-7.12. * XSL-FO 19.-20.12.
            XSLT 17.-20.10. * XML sch�mata (v�etn� RELAX NG) 7.-9.11.
            ------------------------------------------------------------------



            [Non-text portions of this message have been removed]
          • Eliot Kimber
            ... Only a little bit. I think the FO and SVG case is just a special case of the more general problem of how to render documents in which links work, both
            Message 5 of 13 , Sep 21, 2005
              Jirka Kosek wrote:
              > Eliot Kimber wrote:
              >
              >
              >>The challenge here is that the working link in the final PDF for Doc_A
              >>must point to a named anchor in the PDF rendering of Doc_B. How can we
              >>know what the name of the anchor for the PDF rendering of <sect> sect-a is?
              >
              >
              > Seems that we are moving away from original topic, but still in
              > interesting direction.

              Only a little bit. I think the FO and SVG case is just a special case of
              the more general problem of how to render documents in which links work,
              both within a single unit of publication and among units of publication.

              >>I'm pretty sure no FO implementation does (2) but they may do (1) and
              >>(3) is always doable using the sort of technique Ken Holman uses for
              >>back-of-the-book index generation.
              >
              >
              > XEP uses id value as PDF anchor name. AFAIK other FO implementations do
              > same thing.

              That makes it a little easier.

              > BTW: Eliot, have you asked RenderX or Antenna House about implementing
              > links from SVG to FO

              I have.

              Cheers,

              E.
              --
              W. Eliot Kimber
              Professional Services
              Innodata Isogen
              9390 Research Blvd, #410
              Austin, TX 78759
              (512) 372-8155

              ekimber@...
              www.innodata-isogen.com
            • Altsoft Xml2PDF
              ... Altsoft Xml2PDF allows linking between embedded SVGs and XSL-FO document and vice versa. We treat all IDs in all documents (XSL-FO and embedded SVG) as the
              Message 6 of 13 , Sep 22, 2005
                > BTW: Eliot, have you asked RenderX or Antenna House about implementing
                > links from SVG to FO at least in the simplest case when SVG images are
                > placed as instream-foreign-objects and links are using just fragment
                > identifiers? It shouldn't be hard to implement. Is any FO engine
                > vendor listening here?

                Altsoft Xml2PDF allows linking between embedded SVGs and XSL-FO
                document and vice versa. We treat all IDs in all documents (XSL-FO and
                embedded SVG) as the joint set of IDs. There is no difference for
                Xml2PDF in the source of the destination. Thus, if author knows the
                desired ID in the parent or embedded document he just uses it as an
                internal destination. However, the problem with overlapping sets of
                IDs still exists, but it can be easily solved by the author.

                You can download a free evaluation version of Altsoft Xml2PDF at
                http://alt-soft.com/products_xml2pdf_download.jsp


                Best regards,
                Victor Vishnyakov
                Altsoft NV
                http://alt-soft.com/





                --- In XSL-FO@yahoogroups.com, Jirka Kosek <jirka@k...> wrote:
                > Eliot Kimber wrote:
                >
                > > The challenge here is that the working link in the final PDF for
                Doc_A
                > > must point to a named anchor in the PDF rendering of Doc_B. How
                can we
                > > know what the name of the anchor for the PDF rendering of <sect>
                sect-a is?
                >
                > Seems that we are moving away from original topic, but still in
                > interesting direction.
                >
                > > I'm pretty sure no FO implementation does (2) but they may do (1) and
                > > (3) is always doable using the sort of technique Ken Holman uses for
                > > back-of-the-book index generation.
                >
                > XEP uses id value as PDF anchor name. AFAIK other FO implementations do
                > same thing.
                >
                > > Given the mapping shown above, we can implement our XSLT process
                so that
                > > we can generate a PDF-specific external destination value at FO
                > > generation time:
                >
                > If anyone is curious, for DocBook this was already implemented
                >
                > http://sagehill.net/docbookxsl/Olinking.html
                >
                > BTW: Eliot, have you asked RenderX or Antenna House about implementing
                > links from SVG to FO at least in the simplest case when SVG images are
                > placed as instream-foreign-objects and links are using just fragment
                > identifiers? It shouldn't be hard to implement. Is any FO engine vendor
                > listening here?
                >
                > --
                > ------------------------------------------------------------------
                > Jirka Kosek e-mail: jirka@k... http://www.kosek.cz
                > ------------------------------------------------------------------
                > Profesionální ¹kolení a poradenství v oblasti technologií XML.
                > Podívejte se na ná¹ novì spu¹tìný web http://DocBook.cz
                > Podrobný pøehled ¹kolení http://xmlguru.cz/skoleni/
                > ------------------------------------------------------------------
                > Nejbli¾¹í termíny ¹kolení: DocBook 5.-7.12. * XSL-FO 19.-20.12.
                > XSLT 17.-20.10. * XML schémata (vèetnì RELAX NG) 7.-9.11.
                > ------------------------------------------------------------------
                >
                >
                >
                > [Non-text portions of this message have been removed]
              • Peter B. West
                ... Eliot, Sorry about the delay. Address problems. What happens when doc_a and doc_b cross-reference? Peter -- Peter B. West Folio
                Message 7 of 13 , Sep 23, 2005
                  Eliot Kimber wrote:
                  > Jirka Kosek wrote:
                  >
                  >>Eliot Kimber wrote:
                  >>
                  >>
                  >>
                  >>>>I'm not sure about this. How would you know that you are pointing to
                  >>>>yourself? By external-destination="mydoc.fo" or
                  >>>>external-destination="mydoc.pdf" or external-destination="mydoc.ps"?
                  >>>
                  >>>
                  >>>mydoc.fo
                  >>>
                  >>>That is the resource being processed.
                  >>>
                  >>>As part of the FO-to-PDF output, the FO processor must again rewrite the
                  >>>pointers to reflect what things become in the PDF, i.e., PDF anchors,
                  >>>with whatever names, and PDF link annotations to those anchors.
                  >>
                  >>But AFAIK current FO processors don't do this. They just pass URL in
                  >>external-destination from FO to PDF file.
                  >
                  >
                  > Hmm. That's a problem. The FO processor should be examining the value of
                  > external-destination to determine if it is pointing into a resource it
                  > knows something about (i.e., the input FO, included graphic objects,
                  > etc.) or something it doesn't (anything that is not the FO instance or
                  > an FO-defined or SVG-defined dependency on it). There is no other way
                  > that FO processors could, for example, implement links from the FO to
                  > SVG graphic objects in external SVGs.
                  >
                  > Note the implication here: In an FO processor that also does SVG
                  > processing, it must build a list consisting of the FO instance itself,
                  > any SVG documents it points to, and any SVG-related resources those SVG
                  > documents point to (i.e., embedded rasters, components in other SVG
                  > documents). All of these objects are part of the "compound document"
                  > rooted at the FO instance and the FO engine must be prepared to directly
                  > handle the processing of links to and from any of them.
                  >
                  > But there are still cases where the only thing the FO engine should have
                  > to do is pass the value straight through. But that then raises the
                  > question of what value to pass through? Which I think was Jirka's
                  > original question, applied to the more general case.
                  >
                  > That is, in the specific case of links between an FO instance and SVG
                  > graphics included in that FO instance, either instream or external,
                  > there's no reason for an FO processor *not* to recognize that the
                  > external-destination is in fact to that FO instance or one of its
                  > included SVG graphics and do the right thing.
                  >
                  > But when the external destination is to a resource that is entirely
                  > outside the scope of the FO instance and its dependencies, then I agree
                  > that there's not much it can do but pass it straight through. This is
                  > because the responsibility for determining the right ultimate target
                  > address lies with the processor that generates the FO, not the FO
                  > renderer itself.
                  >
                  > For example, consider the case where you have two "units of
                  > publication", Doc_A and Doc_B. These units of publication represent,
                  > logically, the final rendered result (for example, two manuals within a
                  > set of manuals for a single product) in whatever form they might be
                  > rendered (PDF, HTML, online help, etc.).
                  >
                  > Each unit of publication will be composed of many separate components,
                  > i.e., XML source for the text, SVG graphics, etc. Some of these
                  > components may be use in multiple units of publication.
                  >
                  > Again we quickly realize that the links must be constructed in the
                  > source data in terms of the data *as authored*, because again that's all
                  > we know about for sure and because there may be a one-to-many
                  > relationship between source objects and renditions of those source objects.
                  >
                  > For consider the scenario where you have a component of Doc_A that needs
                  > to link to a component of Doc_B. The link as authored will be from an
                  > element in the source for Doc_A to an element in the source for Doc_B, i.e.:
                  >
                  > doc_a.xml:
                  >
                  > <?xml version="1.0"?>
                  > <doc>
                  > ...
                  > <link href="doc_b.xml" xpointer="sect-a">...</link>
                  > ...
                  > </doc>
                  >
                  > doc_b.xml:
                  >
                  > <?xml version="1.0"?>
                  > <doc>
                  > ...
                  > <sect id="sect-a">...</sect>
                  > ...
                  > </doc>
                  >
                  > In order to make this link from Doc_A to Doc_B a working link in the
                  > final PDF you must know, at the time you generate the PDF for Doc_A,
                  > what the PDF anchor for the PDF rendering of <sect> sect-a is. The FO
                  > renderer cannot know this because it doesn't know anything about any PDF
                  > rendered from Doc_B (it only knows about the FO instance it is rendering
                  > at the moment).
                  >
                  > So what will the processing of Doc_A look like?
                  >
                  > First, we transform doc_a.xml into FO. As part of this we have to
                  > transfrom the <link> element into an <fo:basic-link with an
                  > external-destination= value.
                  >
                  > The challenge here is that the working link in the final PDF for Doc_A
                  > must point to a named anchor in the PDF rendering of Doc_B. How can we
                  > know what the name of the anchor for the PDF rendering of <sect> sect-a is?
                  >
                  > There are only three posibilities as far as I can determine:
                  >
                  > 1. The generation of PDF anchor names is deterministic based on some
                  > value provided in the FO instance, either FO IDs or some
                  > FO-engine-specific bit of information (i.e., an "anchor-name=" attribute).
                  >
                  > 2. The FO engine generates the anchor names but then writes out a "side
                  > file" that maps IDs in the FO to anchor names in the PDF. From this you
                  > can map back to the original XML elements by having your FO generation
                  > process write out the mapping from elements in specific source files to
                  > the IDs generated for them in a specific FO instance.
                  >
                  > 3. A variant of (2): You put the ID-to-name mapping in the PDF itself
                  > and then extract it as a post process.
                  >
                  > I'm pretty sure no FO implementation does (2) but they may do (1) and
                  > (3) is always doable using the sort of technique Ken Holman uses for
                  > back-of-the-book index generation.
                  >
                  > So at this point we can presume that we have a mapping from original XML
                  > source document/element ID pairs to PDF anchor names in specific
                  > renderings of those XML elements (that is, the elements in the context
                  > of specific renderings of specific units of publication).
                  >
                  > In our simple case here, we will have this mapping entry, created as a
                  > side effect of rendering unit of publication Doc_B to PDF:
                  >
                  > Source Doc | Elem ID || Unit of Pub | Rendition | Anchor Name |
                  > -----------|---------||-------------------------|-------------|
                  > doc_b.xml | sect-a || Doc_B | Doc_B.pdf | anch_00234 |
                  >
                  >
                  > Note that a basic aspect of XML is that document/ID pairs provide unique
                  > addresses for every XML element in the universe (where by "document" I
                  > mean a specific physical storage object containing an invariant XML
                  > document). That is, every element instance exists in exactly one
                  > document and every document is, by definition, an addressible object.
                  > Therefore every element can be addressed in terms of its location with a
                  > specific document.
                  >
                  > Note also that "Doc_B.pdf" really has to be an absolute location or an
                  > relative path that is in a known relationship to all other PDFs that
                  > might be rendered and that might link to it, otherwise, short of
                  > server-side redirection of URLs embedded in the PDFs or rewriting of
                  > URLs in the PDF when its location is moved (which is doable), there is
                  > no way to create reliable PDF-to-PDF pointers. For this example we can
                  > assume that all the PDFs are published in the same directory just to
                  > keep it simple.
                  >
                  > Given the mapping shown above, we can implement our XSLT process so that
                  > we can generate a PDF-specific external destination value at FO
                  > generation time:
                  >
                  > doc_a.fo:
                  >
                  > <?xml version="1.0"?>
                  > <fo:root>
                  > ...
                  > <fo:basic-link
                  > external-destination="Doc_B.pdf#anch_00234">...</fo:basic-link>
                  > ...
                  > </fo:root>
                  >
                  > Now the FO engine can pass the value of external-destination straight
                  > through and it will work as long as our mapping table was correct.
                  >
                  > Cheers,
                  >
                  > Eliot

                  Eliot,

                  Sorry about the delay. Address problems.

                  What happens when doc_a and doc_b cross-reference?

                  Peter
                  --
                  Peter B. West <http://cv.pbw.id.au/>
                  Folio <http://defoe.sourceforge.net/folio/>


                  [Non-text portions of this message have been removed]
                • Eliot Kimber
                  ... I m not sure I understand exactly what your question is. But I think what you re alluding to is the fact that Doc B has to be rendered before Doc A if Doc
                  Message 8 of 13 , Sep 28, 2005
                    Peter B. West wrote:
                    >
                    > What happens when doc_a and doc_b cross-reference?
                    >

                    I'm not sure I understand exactly what your question is.

                    But I think what you're alluding to is the fact that Doc B has to be
                    rendered before Doc A if Doc A has a cross reference to Doc B and wants
                    to resolve it and likewise Doc A has to be rendered before Doc B if Doc
                    B has a cross reference to Doc A and wants to resolve it.

                    This looks like deadlock and it is.

                    The resolution is to do two passes: Render Doc A, defering generation of
                    links to Doc B. This populates the XML ID to rendered PDF name map for
                    Doc A. Then render Doc B, which can now resolve all its links to Doc A.
                    This populates the XML ID to rendered PDF name map for Doc B. Now
                    re-render Doc A, resolving the links to Doc B.

                    This is another way of saying that Doc A and Doc B have to processed
                    together, either literally as a single processing operation, or in
                    stages as described above.

                    In a set of inter-linked compound documents you essentially have to
                    render each doc twice.

                    Cheers,

                    Eliot

                    --
                    W. Eliot Kimber
                    Professional Services
                    Innodata Isogen
                    9390 Research Blvd, #410
                    Austin, TX 78759
                    (512) 372-8155

                    ekimber@...
                    www.innodata-isogen.com
                  • Peter B. West
                    ... That s what I was asking. ... Peter -- Peter B. West Folio [Non-text portions of this message
                    Message 9 of 13 , Sep 28, 2005
                      Eliot Kimber wrote:
                      > Peter B. West wrote:
                      >
                      >>What happens when doc_a and doc_b cross-reference?
                      >>
                      >
                      >
                      > I'm not sure I understand exactly what your question is.
                      >
                      > But I think what you're alluding to is the fact that Doc B has to be
                      > rendered before Doc A if Doc A has a cross reference to Doc B and wants
                      > to resolve it and likewise Doc A has to be rendered before Doc B if Doc
                      > B has a cross reference to Doc A and wants to resolve it.
                      >

                      That's what I was asking.

                      > This looks like deadlock and it is.
                      >

                      Peter
                      --
                      Peter B. West <http://cv.pbw.id.au/>
                      Folio <http://defoe.sourceforge.net/folio/>


                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.