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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Storing binary PDF files in the database is really bad idea
because:
Oh nooooooooo, not agaaaiiiin this recurring flamewar! *<-{o
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 ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
On Sat, 03 May 2014 04:49:15 +0000
"jdadwilson" jdadwilson@users.sf.net wrote:
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
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
On Sat, 03 May 2014 06:18:12 +0000
"jdadwilson" jdadwilson@users.sf.net wrote:
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…
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"
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:
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.
On Sat, 03 May 2014 19:36:16 +0000
"Lubos Dz" lubosdz@users.sf.net wrote:
Oh nooooooooo, not agaaaiiiin this recurring flamewar! *<-{o
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.
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 ?