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

apache fop not rendering pdf. goes into endless loop

Expand Messages
  • markivs2003
    Hello, Sometimes while generating PDF s apache FOP runs into endless loop. All I see is blank IE window which is spinning and spinning. I also noticed that the
    Message 1 of 12 , Dec 29, 2003
    • 0 Attachment
      Hello,
      Sometimes while generating PDF's apache FOP runs into endless loop.
      All I see is blank IE window which is spinning and spinning. I also
      noticed that the memory usage in my machine is 100% and I had to
      eventually kill my app server.

      PDF generation works just fine for most of the xml file inputs. But
      for some xml inputs, the FOP goes into this endless loop.
      Note: I used the same xsl file in both scenarios.
      There are no logs messages.
      In my recent case, when I reduced the value of "padding-bottom"
      attribute of fo:block, things started working fine.

      But, the problem is xml input can contain any data. I don't have
      control over it. So my question is why is apache not detecting this
      and why there's is no log messages?

      I saw some bugs reported on apache site about similar problem. Dose
      any one know if this problem is addressed in the latest fop
      version ? If not, any suggestions to solve this problem ?

      It's quite frustrating because, you never know for which xml input,
      it's going to fail. Any help regarding this will be very much
      appreciated. I have spent last few days, trying to figure out a
      solution.

      Thanks in advance.
    • J.Pietschmann
      ... Because it s not all that easy to detect loops, at least with the current design. Also there are quite a few bugs where certain area extents are not taken
      Message 2 of 12 , Dec 30, 2003
      • 0 Attachment
        markivs2003 wrote:
        > But, the problem is xml input can contain any data. I don't have
        > control over it. So my question is why is apache not detecting this
        > and why there's is no log messages?

        Because it's not all that easy to detect loops, at least with
        the current design. Also there are quite a few bugs where certain
        area extents are not taken into account for loop detection.

        Furthermore there are cases in which it's generally very hard to
        decide whether backtracking during layout cause a loop or is just
        a waste and another method of resolving an overconstrained layout
        should be tried.

        > I saw some bugs reported on apache site about similar problem. Dose
        > any one know if this problem is addressed in the latest fop
        > version ?

        It is addressed to some extent in the current development code,
        some of the more stupid problems shouldn't occur there. The
        hard problems still remain.

        > It's quite frustrating because, you never know for which xml input,
        > it's going to fail. Any help regarding this will be very much
        > appreciated. I have spent last few days, trying to figure out a
        > solution.

        Which approaches did you try? Did you look at the FOP FAQ?

        J.Pietschmann
      • markivs2003
        Hello, Thanks for your response. In our testing machine, we are using FOP 0.20.4. and that s where I am seeing the problem. But I downloaded FOP 0.20.5 in my
        Message 3 of 12 , Dec 30, 2003
        • 0 Attachment
          Hello,
          Thanks for your response.

          In our testing machine, we are using FOP 0.20.4. and that's where I
          am seeing the problem. But I downloaded FOP 0.20.5 in my machine and
          in the "CHANGES" file they have listed lot of fixes for the infinite
          loop problem (bug #8878,bug #6094 to name a few). So I am thinking
          may be it's a good idea to switch to FOP 0.20.5. What's your opinion
          on that ?

          Yes, i did read the FOP FAQ. But couldn't find much info there
          related to this problem.

          I am using table based layout and at times my tables are nested upto
          3 levels. Not sure if this could be a source for my problem.
          So one thing I can try is change the layout. But that will mean I
          will have to restructure my whole layout.

          One more question,
          If I want to download the source for FOP 0.20.4 where can I find it ?

          Thanks again for your help.
          Mark

          --- In XSL-FO@yahoogroups.com, "J.Pietschmann" <j3322ptm@y...> wrote:
          > markivs2003 wrote:
          > > But, the problem is xml input can contain any data. I don't have
          > > control over it. So my question is why is apache not detecting
          this
          > > and why there's is no log messages?
          >
          > Because it's not all that easy to detect loops, at least with
          > the current design. Also there are quite a few bugs where certain
          > area extents are not taken into account for loop detection.
          >
          > Furthermore there are cases in which it's generally very hard to
          > decide whether backtracking during layout cause a loop or is just
          > a waste and another method of resolving an overconstrained layout
          > should be tried.
          >
          > > I saw some bugs reported on apache site about similar problem.
          Dose
          > > any one know if this problem is addressed in the latest fop
          > > version ?
          >
          > It is addressed to some extent in the current development code,
          > some of the more stupid problems shouldn't occur there. The
          > hard problems still remain.
          >
          > > It's quite frustrating because, you never know for which xml
          input,
          > > it's going to fail. Any help regarding this will be very much
          > > appreciated. I have spent last few days, trying to figure out a
          > > solution.
          >
          > Which approaches did you try? Did you look at the FOP FAQ?
          >
          > J.Pietschmann
        • J.Pietschmann
          ... Just try it. If it works for you, great. ... There are two known loops: 1. Block loops. This happens in 0.20.4 if you try - Put something too high for a
          Message 4 of 12 , Dec 30, 2003
          • 0 Attachment
            markivs2003 wrote:
            > So I am thinking
            > may be it's a good idea to switch to FOP 0.20.5. What's your opinion
            > on that ?

            Just try it. If it works for you, great.

            > Yes, i did read the FOP FAQ. But couldn't find much info there
            > related to this problem.

            There are two known loops:
            1. Block loops. This happens in 0.20.4 if you try
            - Put something too high for a page into the flow, for example
            an image, a table row, or a block container. The image may be
            implicitely too high (pixel heigth * 72 dpi), all other must
            have an explicit heigth for this.
            - Keeps on table rows may cause the total height of a table too
            much for a page
            Block loops usually cause page spilling, which is caught in 0.20.5
            by a simple counter. This aborts rendering and will let your browser
            in the dark though. There may also be block loops which don't cause
            page spilling, I don't know.
            Also, in 0.20.5 images without explicit heigth/width are auto-scaled
            (well, almost always), which reduces the chance for block loops
            occuring accidentally even further. Note that the auto-scale code
            has its own bugs which will bite you if you try to pull tricks with
            overlapping static content.
            2. Line loops. This happens if something too wide in a line, most
            notably images. Another notorious case are list labels, which due
            to the complicated model may fall too narrow to hold even a single
            character, which also causes a line loop. Too narrow table cells
            fall in the same category but are less common, due to the explicit
            column width declaration.
            These loops are *not* caught, and it's not easy to catch them without
            breaking other things.
            A third categroy are oscillations, caused by footnotes and rebalancing
            multiple columns also due to footnotes and span="all" blocks. AFAIK
            they don't currently cause loops, but there may be circumstances where
            they do anyway. Note that footnotes just barely work, and it's best
            not to use them in multi column layout and in tables with keeps.

            > I am using table based layout and at times my tables are nested upto
            > 3 levels.
            Very bad idea. Tables are memory hogs.

            > If I want to download the source for FOP 0.20.4 where can I find it ?

            Its still available via some mirrors reachable from
            http://xml.apache.org/fop/download.html
            for example
            http://sunsite.cnlab-switch.ch/www/mirror/apache/dist/xml/fop/source/
            Use a mirror nearer to you if possible.

            J.Pietschmann
          • gjlloyd
            yea, i had similar problems with FOP 0.20.5, after spending a grueling weekend before a deadline trying to figure out the endless loop problems, we switched to
            Message 5 of 12 , Dec 31, 2003
            • 0 Attachment
              yea, i had similar problems with FOP 0.20.5, after spending a grueling
              weekend before a deadline trying to figure out the endless loop
              problems, we switched to a commerical processor (XEP). we had to spend
              a 1/2 day re-configuring our stylesheets to work with the new
              processor but so far we haven't run into any unsolvable problems with
              XEP (knock on wood).

              my opinion is that FOP 0.20.5 is not ready for complex, professional
              docs. although its fine for simple, or even moderately complex docs,
              there were just too many times when it would behave unexpectedly, and
              the 'fix' would just cause some other problem.

              G

              --- In XSL-FO@yahoogroups.com, "J.Pietschmann" <j3322ptm@y...> wrote:
              > markivs2003 wrote:
              > > So I am thinking
              > > may be it's a good idea to switch to FOP 0.20.5. What's your opinion
              > > on that ?
              >
              > Just try it. If it works for you, great.
              >
              > > Yes, i did read the FOP FAQ. But couldn't find much info there
              > > related to this problem.
              >
              > There are two known loops:
              > 1. Block loops. This happens in 0.20.4 if you try
              > - Put something too high for a page into the flow, for example
              > an image, a table row, or a block container. The image may be
              > implicitely too high (pixel heigth * 72 dpi), all other must
              > have an explicit heigth for this.
              > - Keeps on table rows may cause the total height of a table too
              > much for a page
              > Block loops usually cause page spilling, which is caught in 0.20.5
              > by a simple counter. This aborts rendering and will let your browser
              > in the dark though. There may also be block loops which don't cause
              > page spilling, I don't know.
              > Also, in 0.20.5 images without explicit heigth/width are auto-scaled
              > (well, almost always), which reduces the chance for block loops
              > occuring accidentally even further. Note that the auto-scale code
              > has its own bugs which will bite you if you try to pull tricks with
              > overlapping static content.
              > 2. Line loops. This happens if something too wide in a line, most
              > notably images. Another notorious case are list labels, which due
              > to the complicated model may fall too narrow to hold even a single
              > character, which also causes a line loop. Too narrow table cells
              > fall in the same category but are less common, due to the explicit
              > column width declaration.
              > These loops are *not* caught, and it's not easy to catch them without
              > breaking other things.
              > A third categroy are oscillations, caused by footnotes and rebalancing
              > multiple columns also due to footnotes and span="all" blocks. AFAIK
              > they don't currently cause loops, but there may be circumstances where
              > they do anyway. Note that footnotes just barely work, and it's best
              > not to use them in multi column layout and in tables with keeps.
              >
              > > I am using table based layout and at times my tables are nested upto
              > > 3 levels.
              > Very bad idea. Tables are memory hogs.
              >
              > > If I want to download the source for FOP 0.20.4 where can I find it ?
              >
              > Its still available via some mirrors reachable from
              > http://xml.apache.org/fop/download.html
              > for example
              > http://sunsite.cnlab-switch.ch/www/mirror/apache/dist/xml/fop/source/
              > Use a mirror nearer to you if possible.
              >
              > J.Pietschmann
            • christian brugeron
              I do agree. We tried XEP and XSL Formatter, and for hard work, we use XSL formatter. For some books, over 400 pages, even 1.5 gig of memory was not enough for
              Message 6 of 12 , Jan 1, 2004
              • 0 Attachment
                I do agree. We tried XEP and XSL Formatter, and for hard work, we use
                XSL formatter.
                For some books, over 400 pages, even 1.5 gig of memory was not enough
                for XEP, and XSL formatter did it in 800 Megs.
                We kept XEP for multiplatform, relatively light composition.

                Hope that helps
                Christian


                -----Message d'origine-----
                De : gjlloyd [mailto:gjlloyd@...]
                Envoyé : mercredi 31 décembre 2003 18:53
                À : XSL-FO@yahoogroups.com
                Objet : [XSL-FO] Re: apache fop not rendering pdf. goes into endless
                loop

                yea, i had similar problems with FOP 0.20.5, after spending a grueling
                weekend before a deadline trying to figure out the endless loop
                problems, we switched to a commerical processor (XEP). we had to spend
                a 1/2 day re-configuring our stylesheets to work with the new
                processor but so far we haven't run into any unsolvable problems with
                XEP (knock on wood).

                my opinion is that FOP 0.20.5 is not ready for complex, professional
                docs. although its fine for simple, or even moderately complex docs,
                there were just too many times when it would behave unexpectedly, and
                the 'fix' would just cause some other problem.

                G

                --- In XSL-FO@yahoogroups.com, "J.Pietschmann" <j3322ptm@y...> wrote:
                > markivs2003 wrote:
                > > So I am thinking
                > > may be it's a good idea to switch to FOP 0.20.5. What's your opinion

                > > on that ?
                >
                > Just try it. If it works for you, great.
                >
                > > Yes, i did read the FOP FAQ. But couldn't find much info there
                > > related to this problem.
                >
                > There are two known loops:
                > 1. Block loops. This happens in 0.20.4 if you try
                > - Put something too high for a page into the flow, for example
                > an image, a table row, or a block container. The image may be
                > implicitely too high (pixel heigth * 72 dpi), all other must
                > have an explicit heigth for this.
                > - Keeps on table rows may cause the total height of a table too
                > much for a page
                > Block loops usually cause page spilling, which is caught in 0.20.5
                > by a simple counter. This aborts rendering and will let your browser
                > in the dark though. There may also be block loops which don't cause
                > page spilling, I don't know.
                > Also, in 0.20.5 images without explicit heigth/width are auto-scaled
                > (well, almost always), which reduces the chance for block loops
                > occuring accidentally even further. Note that the auto-scale code
                > has its own bugs which will bite you if you try to pull tricks with
                > overlapping static content.
                > 2. Line loops. This happens if something too wide in a line, most
                > notably images. Another notorious case are list labels, which due
                > to the complicated model may fall too narrow to hold even a single
                > character, which also causes a line loop. Too narrow table cells
                > fall in the same category but are less common, due to the explicit
                > column width declaration.
                > These loops are *not* caught, and it's not easy to catch them
                without
                > breaking other things.
                > A third categroy are oscillations, caused by footnotes and rebalancing
                > multiple columns also due to footnotes and span="all" blocks. AFAIK
                > they don't currently cause loops, but there may be circumstances where
                > they do anyway. Note that footnotes just barely work, and it's best
                > not to use them in multi column layout and in tables with keeps.
                >
                > > I am using table based layout and at times my tables are nested upto

                > > 3 levels.
                > Very bad idea. Tables are memory hogs.
                >
                > > If I want to download the source for FOP 0.20.4 where can I find it
                ?
                >
                > Its still available via some mirrors reachable from
                > http://xml.apache.org/fop/download.html
                > for example
                >
                http://sunsite.cnlab-switch.ch/www/mirror/apache/dist/xml/fop/source/
                > Use a mirror nearer to you if possible.
                >
                > J.Pietschmann





                Yahoo! Groups Sponsor


                ADVERTISEMENT

                <http://rd.yahoo.com/SIG=12cl18mti/M=267637.4116730.5333196.1261774/D=eg
                roupweb/S=1705016061:HM/EXP=1072979803/A=1853619/R=0/*http:/www.netflix.
                com/Default?mqso=60178356&partid=4116730> click here


                <http://us.adserver.yahoo.com/l?M=267637.4116730.5333196.1261774/D=egrou
                pmail/S=:HM/A=1853619/rand=820229788>

                _____

                Yahoo! Groups Links
                * To visit your group on the web, go to:
                http://groups.yahoo.com/group/XSL-FO/

                * To unsubscribe from this group, send an email to:
                XSL-FO-unsubscribe@yahoogroups.com
                <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                Service <http://docs.yahoo.com/info/terms/> .


                [Non-text portions of this message have been removed]
              • David Tolpin
                [ Charset ISO-8859-1 unsupported, converting... ] ... Overall, XSL Formatter V2.* requires more memory than XEP. XSL FO Recommendation is formatted with
                Message 7 of 12 , Jan 1, 2004
                • 0 Attachment
                  [ Charset ISO-8859-1 unsupported, converting... ]
                  > I do agree. We tried XEP and XSL Formatter, and for hard work, we use
                  > XSL formatter.
                  > For some books, over 400 pages, even 1.5 gig of memory was not enough
                  > for XEP, and XSL formatter did it in 800 Megs.
                  > We kept XEP for multiplatform, relatively light composition.
                  >
                  > Hope that helps
                  > Christian

                  Overall, XSL Formatter V2.* requires more memory than XEP. XSL FO Recommendation is
                  formatted with RenderX XEP with -Xmx set too 200m, that is, 200 Megabytes, and it
                  is more than 400 pages long.

                  My guess is that you simply didn't change the default settings of Java Virtual Machine,
                  which limits the heap size to 64 Megabytes, as it is described in almost every Java
                  related FAQ. 1.5 gig is for 3000 pages long document at least.

                  While the design can and should be changed towards less than linear memory requirements,
                  the current implementation of RenderX XEP is usable for any practical formatting tasks.

                  Sincerely,
                  David Tolpin
                • Dave Pawson
                  ... I ve just done a 1929 pages, but as mentioned, the memory for the java implementation needed to be increased. java -Xms100M -Xmx200M did it for me. That
                  Message 8 of 12 , Jan 1, 2004
                  • 0 Attachment
                    At 15:59 01/01/2004, David Tolpin wrote:



                    >My guess is that you simply didn't change the default settings of Java
                    >Virtual Machine,
                    >which limits the heap size to 64 Megabytes, as it is described in almost
                    >every Java
                    >related FAQ. 1.5 gig is for 3000 pages long document at least.


                    I've just done a 1929 pages, but as mentioned, the memory
                    for the java implementation needed to be increased.

                    java -Xms100M -Xmx200M did it for me.
                    That for a 5.5 mb source file.

                    HTH DaveP
                  • christian brugeron
                    I did change the memory requirements; it simply did not make it. Maybe I had to play with some other options (I tried Xmx and Xms) The source file was 8meg,
                    Message 9 of 12 , Jan 1, 2004
                    • 0 Attachment
                      I did change the memory requirements; it simply did not make it.
                      Maybe I had to play with some other options (I tried Xmx and Xms)
                      The source file was 8meg, and it worked if I did not want a cross-ref
                      index (in fact I needed 2 indexes).

                      Thanks for your input.
                      Christian


                      -----Message d'origine-----
                      De : Dave Pawson [mailto:dpawson@...]
                      Envoyé : jeudi 1 janvier 2004 17:12
                      À : XSL-FO@yahoogroups.com
                      Objet : Re: RE : [XSL-FO] Re: apache fop not rendering pdf. goes into
                      endless loop

                      At 15:59 01/01/2004, David Tolpin wrote:



                      >My guess is that you simply didn't change the default settings of Java
                      >Virtual Machine,
                      >which limits the heap size to 64 Megabytes, as it is described in
                      almost
                      >every Java
                      >related FAQ. 1.5 gig is for 3000 pages long document at least.


                      I've just done a 1929 pages, but as mentioned, the memory
                      for the java implementation needed to be increased.

                      java -Xms100M -Xmx200M did it for me.
                      That for a 5.5 mb source file.

                      HTH DaveP






                      Yahoo! Groups Sponsor


                      ADVERTISEMENT

                      <http://rd.yahoo.com/SIG=12cv4goj3/M=266841.4316200.5507732.1261774/D=eg
                      roupweb/S=1705016061:HM/EXP=1073059893/A=1911858/R=0/*http:/www.lifescap
                      einc.com/picasa/landing.php?capid=222&caId=1987> click here


                      <http://us.adserver.yahoo.com/l?M=266841.4316200.5507732.1261774/D=egrou
                      pmail/S=:HM/A=1911858/rand=219330305>

                      _____

                      Yahoo! Groups Links
                      * To visit your group on the web, go to:
                      http://groups.yahoo.com/group/XSL-FO/

                      * To unsubscribe from this group, send an email to:
                      XSL-FO-unsubscribe@yahoogroups.com
                      <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                      * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                      Service <http://docs.yahoo.com/info/terms/> .


                      [Non-text portions of this message have been removed]
                    • David Tolpin
                      [ Charset ISO-8859-1 unsupported, converting... ] ... Did you report the problem to the support team of RenderX? If it is a memory issue related to indices,
                      Message 10 of 12 , Jan 1, 2004
                      • 0 Attachment
                        [ Charset ISO-8859-1 unsupported, converting... ]
                        > I did change the memory requirements; it simply did not make it.
                        > Maybe I had to play with some other options (I tried Xmx and Xms)
                        > The source file was 8meg, and it worked if I did not want a cross-ref
                        > index (in fact I needed 2 indexes).

                        Did you report the problem to the support team of RenderX? If it is
                        a memory issue related to indices, then it should be fixed.

                        The current version of RenderX XEP is normally mentioned at http://xep.xattic.com/.
                        Did you obtain those results with the current version?

                        David Tolpin
                      • christian brugeron
                        It was last year, as I did it with XSL formatter, I did not try this project with a newer version of XEP. Neither did I report the problem. I had the very same
                        Message 11 of 12 , Jan 1, 2004
                        • 0 Attachment
                          It was last year, as I did it with XSL formatter, I did not try this
                          project with a newer version of XEP. Neither did I report the problem.
                          I had the very same problem with FOP.

                          BTW, how to you output a vertical bar between two columns, and that
                          stops when a block spans the 2 column? XSL Formatter has an extension,
                          and I don’t know how to do it without.

                          Christian


                          -----Message d'origine-----
                          De : David Tolpin [mailto:dvd@...]
                          Envoyé : jeudi 1 janvier 2004 18:29
                          À : XSL-FO@yahoogroups.com
                          Objet : Re: RE : RE : [XSL-FO] Re: apache fop not rendering pdf. goes
                          into endless loop

                          [ Charset ISO-8859-1 unsupported, converting... ]
                          > I did change the memory requirements; it simply did not make it.
                          > Maybe I had to play with some other options (I tried Xmx and Xms)
                          > The source file was 8meg, and it worked if I did not want a cross-ref
                          > index (in fact I needed 2 indexes).

                          Did you report the problem to the support team of RenderX? If it is
                          a memory issue related to indices, then it should be fixed.

                          The current version of RenderX XEP is normally mentioned at
                          http://xep.xattic.com/. <http://xep.xattic.com/>
                          Did you obtain those results with the current version?

                          David Tolpin
                          _____

                          Yahoo! Groups Links
                          * To visit your group on the web, go to:
                          http://groups.yahoo.com/group/XSL-FO/

                          * To unsubscribe from this group, send an email to:
                          XSL-FO-unsubscribe@yahoogroups.com
                          <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                          * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                          Service <http://docs.yahoo.com/info/terms/> .


                          [Non-text portions of this message have been removed]
                        • Alexander Peshkov
                          Hello Christian, cb BTW, how to you output a vertical bar between two columns, and that cb stops when a block spans the 2 column? XSL Formatter has an
                          Message 12 of 12 , Jan 5, 2004
                          • 0 Attachment
                            Hello Christian,

                            cb> BTW, how to you output a vertical bar between two columns, and that
                            cb> stops when a block spans the 2 column? XSL Formatter has an extension,
                            cb> and I don’t know how to do it without.

                            You can draw a rule in SVG and place it into the background of the
                            body-region (block with span="all" in this case should have
                            background-color="white"). The only shortcoming of this approach is
                            that this rule will be drawn through all the page even if columns are
                            shorter.
                            There is another solution which gives you desired result although it's
                            a kind of hack:
                            - wrap whole text in a fo:block with left/right borders as thick as
                            required rule and left/right padding with the size equal to
                            (column-gap width minus rule width) divided by two.
                            This way you have desired rule between columns and undesired
                            border on either sides.
                            - add symmetrical region-start/region-end which have extents as
                            wide as region-body margin minus padding of fo:block (calculated
                            above). Place in appropriate static contents fo:block-container
                            with height="100%" and background-color="white" (it should have
                            some non-empty content, i.e. block with empty leader inside).
                            These containers will be drawn atop of the side borders and will
                            hide them.

                            I'll send you a sample demonstrating both approaches off-list.

                            Best regards,
                            Alexander Peshkov mailto:peshkov@...
                            RenderX

                            cb> Christian


                            cb> -----Message d'origine-----
                            cb> De : David Tolpin [mailto:dvd@...]
                            cb> Envoyé : jeudi 1 janvier 2004 18:29
                            cb> À : XSL-FO@yahoogroups.com
                            cb> Objet : Re: RE : RE : [XSL-FO] Re: apache fop not rendering pdf. goes
                            cb> into endless loop

                            cb> [ Charset ISO-8859-1 unsupported, converting... ]
                            >> I did change the memory requirements; it simply did not make it.
                            >> Maybe I had to play with some other options (I tried Xmx and Xms)
                            >> The source file was 8meg, and it worked if I did not want a cross-ref
                            >> index (in fact I needed 2 indexes).

                            cb> Did you report the problem to the support team of RenderX? If it is
                            cb> a memory issue related to indices, then it should be fixed.

                            cb> The current version of RenderX XEP is normally mentioned at
                            cb> http://xep.xattic.com/. <http://xep.xattic.com/>
                            cb> Did you obtain those results with the current version?

                            cb> David Tolpin
                            cb> _____

                            cb> Yahoo! Groups Links
                            cb> * To visit your group on the web, go to:
                            cb> http://groups.yahoo.com/group/XSL-FO/

                            cb> * To unsubscribe from this group, send an email to:
                            cb> XSL-FO-unsubscribe@yahoogroups.com
                            cb> <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                            cb> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                            cb> Service <http://docs.yahoo.com/info/terms/> .


                            cb> [Non-text portions of this message have been removed]





                            cb> Yahoo! Groups Links

                            cb> To visit your group on the web, go to:
                            cb> http://groups.yahoo.com/group/XSL-FO/

                            cb> To unsubscribe from this group, send an email to:
                            cb> XSL-FO-unsubscribe@yahoogroups.com

                            cb> Your use of Yahoo! Groups is subject to:
                            cb> http://docs.yahoo.com/info/terms/
                          Your message has been successfully submitted and would be delivered to recipients shortly.