Help with PDF

[Harry Strybos]

Hi All

Could some kind soul help me with advice on PDF generation. Our company
seems to have gone PDF mad and I am expected to produce outgoing reports in
..pdf rather than .txt, .xls or .csv (as they are now).

No worries with buying a component to fit in with VB.Net (2008). I would be
grateful for any advice on the best (and easiest to understand ) component
for the job.

Thanks and a Merry Christmas to all.

Harry

 

[rowe_newsgroups]

Hi All

Could some kind soul help me with advice on PDF generation. Our company
seems to have gone PDF mad and I am expected to produce outgoing reports in
.pdf rather than .txt, .xls or .csv (as they are now).

No worries with buying a component to fit in with VB.Net (2008). I would be
grateful for any advice on the best (and easiest to understand ) component
for the job.

Thanks and a Merry Christmas to all.

Harry

I've used Siberix Report Writer in the past and still swear by it. The
entire library (with the exception of a few native calls) is written
in C# and the licensing is tremendous (and cheap!). It also always the
creation of pdfs based on xml files, something that I find extremely
useful. A fully functional free trial is available (it watermarks the
outputted pages) so you can give it a whirl before purchasing a
license.

http://siberix.com/

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

 

[Cor Ligthert[MVP]]

Harry,

As PDF original was owned by Adobe, is that in my idea the first place to
look at.
In past they had a kind of PDF developper toolkit. I don't know if that
still exist.

http://support.adobe.com/devsup/devsup.nsf/docs/53588.htm?OpenDocument&Click=

Cor

 

[James Hahn]

A PDF file is "in no way a report". PDF, csv or txt all need a viewer to
create the report. The purpose is to standardize on the viewer (PDF).
Requiring the user to access the existing viewers and then print to PDF so
they can view in the PDF viewer hardly meets the requirements.

 

[Mike Williams]

A PDF file is "in no way a report". PDF, csv or txt all
need a viewer [sic!] to create the report. The purpose
is to standardize on the viewer (PDF).

.. . . and your point is?

Requiring the user to access the existing viewers and
then print to PDF so they can view in the PDF viewer
hardly meets the requirements.

I think you've misunderstood what the other respondents have said, James. As
far as I can tell from the OP's question he wants to use his own
VB(sic!).net application to create the pdf files so that he can send the
resultant pdf files to the recipients, who are currently receiving the
reports in some other format. The recipient is in no way required to access
any existing viewer for any file format other than pdf, and neither is he
required to perform the printing to pdf himself. All the recpient needs at
his end is a standard pdf viewer so that he can view the pdf files he
receives and also to print copies of them from within the viewer if he
wishes to do so.

So, the suggestion of using a PDF "printer" driver to produce his pdf files
from within the OP's own application is a good one because it gets the job
done and it also allows the OP to create a pdf file from any existing
standard printing code he may have already written simply by sending it to
the pdf driver rather than to a "real" printer. If the OP is capable of
writing standard printing code to print documents on a standard real printer
(which I asume he is) then he can use exactly the same code to produce a pdf
file. Alternatively he could create his pdf files using raw code rather than
using a PDF "printer" driver, which has the advantage of having everything
contained within the app itself and therefore not requiring a pdf printer
driver or any other third party control at the OP's end, but of course that
particular method is nowhere near as simple as using a ready made pdf driver
that behaves exactly like a standard printer other than for the fact it
produces pdf files rather than hard output on paper.

Mike

 

[James Hahn]

The point is that an application that produces output in PDF is not any more
producing a report than an application that produces output in CSV or TXT.
The user still has to fire up a viewer to see or to print the 'report'. It
doesn't exist, as far as the user is concerned, until this happens.

I was not commenting on whether or not a PDF printer is an appropriate
solution. I was commenting on the implied assertion that a CSV or TXT
output is not a 'report' when a PDF output is. OP is NOT talking about
rendering CSV or TXT files in PDF, as Patrice states he is. OP is talking
about changing an existing data transfer process from the CSV and TXT file
format to a PDF file format. There is no weirdness at all in changing an
application from creating a CSV file as output, to be accessed from Excel in
order to view or print the report, to one that creates a PDF file as output
to be acccessed from Acrobat Reader (or similar) in order to view or print
the report. There's nothing magical about the PDF file format - it's just
another data transfer file format. In this context a PDF file is exactly the
same form of data exchange as CSV or TXT.

It's Patrice who has misunderstood what OP is trying to do, by suggesting
that if the XLS file can be used to produce good looking reports
(presumably, using EXCEL) then they can be printed to the PDF printer to
meet management requirements. As the OP made it clear that the application
is producing CSV and TXT files, then I presume it is the USER, not OP, who
is using EXCEL to produce the reports from these files. Creating PDF files
from the EXCEL display is not what this change is trying to achieve. That
was the reason for my post. The appropriate solution is for the application
developer, not the user, to produce the PDF files. The CSV files won't
exist, and how they look in EXCEL will be irrelevant.

A PDF file is "in no way a report". PDF, csv or txt all
need a viewer [sic!] to create the report. The purpose
is to standardize on the viewer (PDF).

. . . and your point is?

Requiring the user to access the existing viewers and
then print to PDF so they can view in the PDF viewer
hardly meets the requirements.

I think you've misunderstood what the other respondents have said, James.
As far as I can tell from the OP's question he wants to use his own
VB(sic!).net application to create the pdf files so that he can send the
resultant pdf files to the recipients, who are currently receiving the
reports in some other format. The recipient is in no way required to
access any existing viewer for any file format other than pdf, and neither
is he required to perform the printing to pdf himself. All the recpient
needs at his end is a standard pdf viewer so that he can view the pdf
files he receives and also to print copies of them from within the viewer
if he wishes to do so.

So, the suggestion of using a PDF "printer" driver to produce his pdf
files from within the OP's own application is a good one because it gets
the job done and it also allows the OP to create a pdf file from any
existing standard printing code he may have already written simply by
sending it to the pdf driver rather than to a "real" printer. If the OP is
capable of writing standard printing code to print documents on a standard
real printer (which I asume he is) then he can use exactly the same code
to produce a pdf file. Alternatively he could create his pdf files using
raw code rather than using a PDF "printer" driver, which has the advantage
of having everything contained within the app itself and therefore not
requiring a pdf printer driver or any other third party control at the
OP's end, but of course that particular method is nowhere near as simple
as using a ready made pdf driver that behaves exactly like a standard
printer other than for the fact it produces pdf files rather than hard
output on paper.

Mike

 

[Mike Williams]

The point is that an application that produces output in PDF
is not any more producing a report than an application that
produces output in CSV or TXT.

That depends on your definition of "report". You could say that they are all
reports, or that none of them are reports, depending on your definition.

The user still has to fire up a viewer to see or to print the
'report'. It doesn't exist, as far as the user is concerned,
until this happens.

Well, yes. That is /always/ the case except for a document that is already
printed on one or more pieces of paper. But the OP clearly does /not/ want
to send printed documents to people, otherwise he would not be interested in
producing files in the pdf format. What he wants to do is send them a pdf
file so that they can view or print them themselves. That much is quite
clear.

There is no weirdness at all in changing an application
from creating a CSV file as output, to be accessed from
Excel in order to view or print the report, to one that
creates a PDF file as output to be acccessed from
Acrobat Reader (or similar) in order to view or print the report.

I never said there was!

I was commenting on the implied assertion that a CSV
or TXT output is not a 'report' when a PDF output is.

I didn't say that either, and neither did I imply it. You are responding to
my post [Mike Williams] and yet you are commenting on something that was
said by someone else [Patrice]. I was merely suggesting to the OP that
sending the output from his VB(sic!).net application to a pdf "printer"
driver was indeed a good way of achieving what are his clearly stated aims.

As the OP made it clear that the application is producing
CSV and TXT files, then I presume it is the USER, not
OP, who is using EXCEL to produce the reports from
these files.

Actually the OP did NOT say that the application was producing only .csv and
..txt files. He actually said, "I am expected to produce outgoing reports in
..pdf rather than .txt, .xls or .csv (AS THEY ARE NOW)". Your own assumption
that it is the user rather than the OP who is using Excel to produce the
reports from the .csv or .txt files is clearly WRONG! The OP is clearly
already producing files in all of the three formats he mentioned (.csv, .txt
and .xls) and he wants to produce .pdf files instead so that he can send the
..pdf files to his users instead of the .xls files (or whatever) that he is
currently sending them!

The appropriate solution is for the application developer, not the user,
to produce the PDF files.

That is EXACTLY what I suggested. The following is exactly what I said:

". . . using a PDF "printer" driver to produce his pdf files
from within the OP's own application is a good one . . ."

I also suggested that the OP could create the .pdf files from within his
application using raw code if he wished to do so, but that doing so would
need a lot more code than simply directing his output to a pdf driver. So in
both cases it is clear that I suggested that the OP should produce his pdf
files from within his own application. Why are you suggesting that I said
otherwise? Have you an axe to grind or something?

Mike

 

[James Hahn]

Your argument is with Patrice, not me. Go back and read the post I was
responding to.

The point is that an application that produces output in PDF
is not any more producing a report than an application that
produces output in CSV or TXT.

That depends on your definition of "report". You could say that they are
all reports, or that none of them are reports, depending on your
definition.

The user still has to fire up a viewer to see or to print the
'report'. It doesn't exist, as far as the user is concerned,
until this happens.

Well, yes. That is /always/ the case except for a document that is already
printed on one or more pieces of paper. But the OP clearly does /not/ want
to send printed documents to people, otherwise he would not be interested
in producing files in the pdf format. What he wants to do is send them a
pdf file so that they can view or print them themselves. That much is
quite clear.

There is no weirdness at all in changing an application
from creating a CSV file as output, to be accessed from
Excel in order to view or print the report, to one that
creates a PDF file as output to be acccessed from
Acrobat Reader (or similar) in order to view or print the report.

I never said there was!

I was commenting on the implied assertion that a CSV
or TXT output is not a 'report' when a PDF output is.

I didn't say that either, and neither did I imply it. You are responding
to my post [Mike Williams] and yet you are commenting on something that
was said by someone else [Patrice]. I was merely suggesting to the OP that
sending the output from his VB(sic!).net application to a pdf "printer"
driver was indeed a good way of achieving what are his clearly stated
aims.

As the OP made it clear that the application is producing
CSV and TXT files, then I presume it is the USER, not
OP, who is using EXCEL to produce the reports from
these files.

Actually the OP did NOT say that the application was producing only .csv
and .txt files. He actually said, "I am expected to produce outgoing
reports in .pdf rather than .txt, .xls or .csv (AS THEY ARE NOW)". Your
own assumption that it is the user rather than the OP who is using Excel
to produce the reports from the .csv or .txt files is clearly WRONG! The
OP is clearly already producing files in all of the three formats he
mentioned (.csv, .txt and .xls) and he wants to produce .pdf files instead
so that he can send the .pdf files to his users instead of the .xls files
(or whatever) that he is currently sending them!

The appropriate solution is for the application developer, not the user,
to produce the PDF files.

That is EXACTLY what I suggested. The following is exactly what I said:

". . . using a PDF "printer" driver to produce his pdf files
from within the OP's own application is a good one . . ."

I also suggested that the OP could create the .pdf files from within his
application using raw code if he wished to do so, but that doing so would
need a lot more code than simply directing his output to a pdf driver. So
in both cases it is clear that I suggested that the OP should produce his
pdf files from within his own application. Why are you suggesting that I
said otherwise? Have you an axe to grind or something?

Mike

 

[James Hahn]

The switch to PDF will also involve a switch by the user from EXCEL to
Acrobat Reader (or similar) for viewing and printing the reports. As OP is
talking about 'reports' I presume that the XLS or CSV format is not being
used to create data to be manipulated, but is simply a means of getting data
into an application where the user can view or print it. For this purpose, a
PDF file, to be opened in Acrobat Reader, is just as much a 'data transfer'
file as an XLS file to be opened in Excel. Or, the CSV file is just as much
a 'report' as the PDF file - whichever way you want to look at it. It
would certainly be difficult (and quite impractical) to get PDF format back
into Excel, but the way I read it is that the point is to avoid using Excel
as the report viewer for this application.

 

[Mike Williams]

Your argument is with Patrice, not me. Go back and
read the post I was responding to.

I don't have an argument with Patrice. In fact I don't have an argument with
anyone. You were responding to MY post. Go back and check if you don't
believe me. As I have said, I am not arguing with anyone, I am just telling
things as I see them, but if you believe that it is an argument (as you
apparently do) then it is YOUR argument, and it is currently with me because
I am the person whose post you responded to. If you want to argue with
someone else then address your reply to them by responding to one of their
own posts.

Have a nice day

Mike

 

[Gillard]

merry christmas

I don't have an argument with Patrice. In fact I don't have an argument
with anyone. You were responding to MY post. Go back and check if you
don't believe me. As I have said, I am not arguing with anyone, I am just
telling things as I see them, but if you believe that it is an argument
(as you apparently do) then it is YOUR argument, and it is currently with
me because I am the person whose post you responded to. If you want to
argue with someone else then address your reply to them by responding to
one of their own posts.

Have a nice day

Mike

 

[Harry]

My understanding is that the current application create text, csv or xls
files. txt and csv files are usually used to exchange data so I don't see
any benefit to switch to PDF (it will be actually harder for third party
app to process).

Don't know what is the layout for the Excel file but :
- if this is also used as an exchange format then producing a PDF is also
IMO counter productive
- if this is a real "report" (i.e. something that the user can just
see/print without any additional processing) then the application (not the
user) could take an additional "print to pdf" step to provide the end user
with a PDF file...

For now I'm confused with the word "reports" (to me this is something with
the final layout) and the txt, csv format (which is used for interchange)
used in the same sentence. Hopefully the OP will clarify if needed.

Thanks for all your input guys.

Seems there is some debate on what constitutes a report. Wikipedia :
http://en.wikipedia.org/wiki/Report suggests reports are essentially
diverse forms for dissementating information. So, some numbers written on
the back of a piece of torn cardboard could be contrued as a report, as
could a letter/email from a business entity showing your current account
balance.......what is one mans report is another mans letter

In my case, the "reports" are all tabular in nature, but may contain a
header graphic or some footnotes. Many contain statistical data (eg Service
Usage Report). The company has decided these are all to be emailed in .pdf
format. Not my decision.

I have found a number of solutions, but discovered that the print control I
use (C1 PrintDocument) can also export to .pdf, so problem solved *blush*.

Thank you very much for your input. Happy New Year

 

[rowe_newsgroups]

"Patrice" <http://www..chez.com/scribe/> wrote in message







Thanks for all your input guys.

Seems there is some debate on what constitutes a report. Wikipedia :http://en.wikipedia.org/wiki/Report suggests reports are essentially
diverse forms for dissementating information. So, some numbers written on
the back of a piece of torn cardboard could be contrued as a report, as
could a letter/email from a business entity showing your current account
balance.......what is one mans report is another mans letter

In my case, the "reports" are all tabular in nature, but may contain a
header graphic or some footnotes. Many contain statistical data (eg Service
Usage Report). The company has decided these are all to be emailed in .pdf
format. Not my decision.

I have found a number of solutions, but discovered that the print controlI
use (C1 PrintDocument) can also export to .pdf, so problem solved *blush*..

Thank you very much for your input. Happy New Year

In a business sense, a report is what is defined by the customer as a
report.

Personally, I don't care what the customer calls something, if they
give me a well written spec of what that item is, I will deliver it
and call it whatever they want

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/

 

[Bill Strybos]

I am looking for good e-mail address for Harry Strybos. If he is alive.
It is just one of those things that about this time of the year I try to
make contact with all of those with my same last name.

Thank you and let me know if you do exist or have gone on.

Bill Strybos
Houston, Texas

(e-mail address removed)