Create Multiple PDF Files

Help
jdadwilson
2014-05-03
2014-05-03
  • jdadwilson
    jdadwilson
    2014-05-03

    I am totally new to TCPDF and have a simple question. I have a web app in which I generate invoices. After the invoices are generated I have a module for printing. The user can select one or multiple invoices from a list. With the present method I am using for producing the PDF file, all invoices are included in one document. Ideally, producing an individual file for each invoice would be better.

    Is this possible in TCPDF?

    TIA for any assistance.
    jdadwilson

     
    • epistaxis
      epistaxis
      2014-05-03

      On Sat, 03 May 2014 04:49:15 +0000
      "jdadwilson" jdadwilson@users.sf.net wrote:

      app in which I generate invoices. After the invoices are generated
      I have a module for printing. The user can select one or multiple
      invoices from a list. With the present method I am using for
      producing the PDF file, all invoices are included in one document.
      Ideally, producing an individual file for each invoice would be
      better.

      That's 'cos you only make one call to your routine
      @ the end of the process; you should call it every
      time an invoice is chosen (and generating once+saving
      these in a database would be IMHO a better practice).

      --
      BOFH excuse #17:
      fat electrons in the lines

       
  • jdadwilson
    jdadwilson
    2014-05-03

    Thank you for your reply. The invoices ARE generated once and stored in a JSON format in a mySQL database. What I did not make clear is that the present method I am using to produce the PDF file is other than TCPDF. I am looking to find something that will better fit my system.

    I guess I'll just continue with what I have at present. It has worked for 10+ years now.

    jdadwilson

     
    • epistaxis
      epistaxis
      2014-05-03

      On Sat, 03 May 2014 06:18:12 +0000
      "jdadwilson" jdadwilson@users.sf.net wrote:

      Thank you for your reply. The invoices ARE generated once and
      stored in a JSON format in a mySQL database. What I did not make
      clear is that the present method I am using to produce the PDF
      file is other than TCPDF. I am looking to find something that will
      better fit my system.

      Yeah, as usual: people almost never supply the whole shebang
      (not to mention they NEVER touched anything;)

      Programming (whatever the language or framework) will do whatever
      you programmed it to do…

      I guess I'll just continue with what I have at present. It has
      worked for 10+ years now.

      Bad habits longing…

      When I said "PDFs in DB", I meant whole PDFs in db.
      It's quite large (and shitsql doesn't cope very well with
      large tables) but you just have to compute each pdf once.

      Of course, it fits better in a real RDBMS (such as PostgreSQL).

      --
      Alliance, n.:
      In international politics, the union of two thieves who have
      their hands so deeply inserted in each other's pocket that they cannot
      separately plunder a third. -- Ambrose Bierce, "The Devil's Dictionary"

       
  • Lubos Dz
    Lubos Dz
    2014-05-03

    yes, TCPDF can create invoices as an individual file.
    It is actually not a matter of TCPDF, but of the design of your application.

    Storing binary PDF files in the database is really bad idea because:

    1. database can grow up quickly, which brings secondary issues (backups, pdf document management - deleting, updating etc gets complicated)
    2. requires special column types (binary safe) or converting binary data into base64 or vice versa.

    A better way would be storing all PDF files on the harddisk and keeping in database only basic data (title, size, path) related to the document file.

     
    • epistaxis
      epistaxis
      2014-05-03

      On Sat, 03 May 2014 19:36:16 +0000
      "Lubos Dz" lubosdz@users.sf.net wrote:

      Storing binary PDF files in the database is really bad idea
      because:

      Oh nooooooooo, not agaaaiiiin this recurring flamewar! *<-{o

      1. database can grow up quickly, which brings secondary issues
        (backups, pdf document management - deleting, updating etc gets
        complicated) 2. requires special column types (binary safe) or
        converting binary data into base64 or vice versa.

      With a poor DB design and a "SQL server" not even ISO compliant,
      for sure.
      But with a real world SQL server and a good design, piece of cake.

      A better way would be storing all PDF files on the harddisk and
      keeping in database only basic data (title, size, path) related to
      the document file.

      But this way, no more unified backup possibility; furthermore,
      most file systems don't cope very good in concurrent accesses
      when you store a huge qty of files on them.

      On 2nd thought, if the DB design's the same level as the application
      seems to be, keep PDFs as separated files…

      --
      <calc> knghtbrd: gnome 2.0 will be out in a few months, not sure how it
      will compare to kde 2.0 though
      <knghtbrd> calc: Just as bloated, just as buggy, and every Gnome 2 app
      will depend on 30 libraries.
      <Slimer> knghtbrd: so what changes from 1.0 ?