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

RE: [XSL-FO] Re: Several files to create - best approach?

Expand Messages
  • Fournier,Danny [NCR]
    ... I ve ended up registering the FOP classes on my Coldfusion MX server. Then, I can invoke them in my code which is producing PDFs faster and seems to take
    Message 1 of 8 , Dec 1, 2005
    • 0 Attachment
      > -----Original Message-----
      > From: XSL-FO@yahoogroups.com [mailto:XSL-FO@yahoogroups.com]
      > On Behalf Of andrewsc51
      > Sent: Thursday, December 01, 2005 1:20 AM
      > To: XSL-FO@yahoogroups.com
      > Subject: [XSL-FO] Re: Several files to create - best approach?
      >
      >
      > <Danny.Fournier@e...> wrote:
      > >
      > > Right now, I dynamically create 118 (59*2) FO files.
      > > Then, I proceed to build a batch file that has 118 calls
      > > to the individual FO files using FOP.
      > > Each files are about 5-7Kb and represent about one
      > > page each.
      >
      > I am planning for a similar process, to produce 4800 PDF files of 2-3
      > pages each. Then, I need to concatenate the PDF files, to produce a
      > single big one.
      >
      > Does any one know how to concatenate PDF files in a Java-Unix
      > environment ?
      >
      > I just feel it is safer to have separate invocations of FOP for each
      > file. I realise this means creating and dismantling the Java VM 4800
      > times. But we will have a dedicated Unix box for this purpose,
      > different from the Web and Database boxes. So, we can afford a bit of
      > raw power. Besides the robustness of the FOP renderer, there are
      > possible issues at the back-end. On one file or another, the database
      > may throw an error when producing the XML (it happens now), and I
      > don't want this to stop the entire batch.

      I've ended up registering the FOP classes on my Coldfusion MX server.
      Then, I can invoke them in my code which is producing PDFs faster and
      seems to take less of a performance hit on the server.

      Plus, I can pass FO in memory instead of having to create FO files and
      pass their path as parameters. Works really well so far.
    • andrewsc51
      ... You are quire right, I was slowly coming to the same conclusion myself. There is really no need to dismantle and recreate the JVM each time. Instead of
      Message 2 of 8 , Dec 3, 2005
      • 0 Attachment
        >> I realise this means creating and dismantling
        >> the Java VM 4800 times.

        Danny.Fournier@e... wrote:
        > I've ended up registering the FOP classes on my Coldfusion
        > MX server. Then, I can invoke them in my code which
        > is producing PDFs faster and seems to take less of
        > a performance hit on the server.

        You are quire right, I was slowly coming to the same conclusion
        myself. There is really no need to dismantle and recreate the
        JVM each time. Instead of invoking FO from the command line
        each time, I shall be able to have a master Java class, to call
        the FO renderer repeatedly. This way, I should be able to save
        the considerable overhead of having to create a new JVM for each
        file. Based on past experience, I intend to call Jaava garbage
        collection after rendering every few files. I'm not too keen on
        the idea of a single huge memory space growing indefinitely, so I
        rather get rid of leftover bits and pieces at a convenient moment,
        when not much else is in use. My job will be (hopefully) a pure
        batch invoked from the Shell, so I don't have to worry about Web
        session contexts and such.

        > Plus, I can pass FO in memory instead of having to create
        > FO files and pass their path as parameters. Works really
        > well so far.

        This sounds interesting, and I might try it as well. But I place
        a high value on "supportability". In case of any trouble, I want
        to be able to come the morning after, and inspect the
        intermediate files in XML and FO formats. Managing 4800 files
        is well within the capabilities of a Unix box, and I've done
        it before. I don't care if the machine works hard at night,
        as long as I can sleep tight.

        Andrew

        P.S. thanks for other people who responded, pointing me to
        the Lowagie package.
      • vijay chiniwar
        I have done Some thing like this before but am sure, Memory will be a serious issue, between i make use of SVG in my Pdf and have noticed that these SVGs are
        Message 3 of 8 , Dec 6, 2005
        • 0 Attachment
          I have done Some thing like this before
          but am sure, "Memory" will be a serious issue,
          between i make use of SVG in my Pdf and have noticed that these SVGs are stored in memory and never get deleted unless i restart my webserver

          If i can get some way where i can getaway with this images from memory it would be just great

          heres the program for merging pdfs

          you will need a lowagiepdf.jar from iText which is a freeware


          package com.db.eqr.croci.struts.actions;
          /**
          * test.java
          * @author vch
          * @version
          *
          */
          public class test
          {
          public void genPdf()
          {
          String directory=Application.getProperty("pathtoPDFStore")+"/pdfs/";
          String destDirectory=Application.getProperty("pathtoPDFStore")+"/merge/";
          String[] files = //read files from dir here
          PdfReader reader = null;
          Rectangle psize = null;
          Document document = null;
          PdfWriter writer = null;
          Timer t2=new Timer("Time to Merge Documents");
          t2.start();
          for (int index = 0; index < companyIdList.size(); index++)
          {
          files[index]=((String)companyIdList.get(index)+".pdf");
          try
          {
          if (index == 0)
          {
          reader = new PdfReader(directory+ files[index]);
          psize = reader.getPageSize(1);
          document = new Document(psize);
          writer = PdfWriter.getInstance(document,
          new FileOutputStream(destDirectory+"mergedDocument.pdf"));
          document.open();
          }
          else
          {
          reader = new PdfReader(directory + files[index]);
          }
          int n = reader.getNumberOfPages();
          PdfContentByte cb = writer.getDirectContent();
          int i = 0;
          while (i < n)
          {
          document.newPage();
          i++;
          PdfImportedPage page1 = writer.getImportedPage(reader, i);
          cb.addTemplate(page1, .5f, .5f);
          }
          }
          catch(Exception e)
          {
          continue;
          }
          }
          if(document!=null)
          {
          document.close();
          }
          t2.stop();
          }
          }






          andrewsc51 <andrewsc51@...> wrote:
          >> I realise this means creating and dismantling
          >> the Java VM 4800 times.

          Danny.Fournier@e... wrote:
          > I've ended up registering the FOP classes on my Coldfusion
          > MX server. Then, I can invoke them in my code which
          > is producing PDFs faster and seems to take less of
          > a performance hit on the server.

          You are quire right, I was slowly coming to the same conclusion
          myself. There is really no need to dismantle and recreate the
          JVM each time. Instead of invoking FO from the command line
          each time, I shall be able to have a master Java class, to call
          the FO renderer repeatedly. This way, I should be able to save
          the considerable overhead of having to create a new JVM for each
          file. Based on past experience, I intend to call Jaava garbage
          collection after rendering every few files. I'm not too keen on
          the idea of a single huge memory space growing indefinitely, so I
          rather get rid of leftover bits and pieces at a convenient moment,
          when not much else is in use. My job will be (hopefully) a pure
          batch invoked from the Shell, so I don't have to worry about Web
          session contexts and such.

          > Plus, I can pass FO in memory instead of having to create
          > FO files and pass their path as parameters. Works really
          > well so far.

          This sounds interesting, and I might try it as well. But I place
          a high value on "supportability". In case of any trouble, I want
          to be able to come the morning after, and inspect the
          intermediate files in XML and FO formats. Managing 4800 files
          is well within the capabilities of a Unix box, and I've done
          it before. I don't care if the machine works hard at night,
          as long as I can sleep tight.

          Andrew

          P.S. thanks for other people who responded, pointing me to
          the Lowagie package.







          SPONSORED LINKS
          Xml xsl Xsl Xsl fo Xsl-fo Xsl tutorial

          ---------------------------------
          YAHOO! GROUPS LINKS


          Visit your group "XSL-FO" on the web.

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

          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


          ---------------------------------








          ---------------------------------
          Yahoo! Shopping
          Find Great Deals on Gifts at Yahoo! Shopping

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