I am thoroughly confused with something I want to do and am looking for some advice.
One of my client has to produce monthly invoice detailing all of the company expenditure, and two other such invoices. The client is sure that he only needs these invoices - and they are extremely simple enough to produce as far as logic is concerned.
Now, to make the actual invoice, I don't really want to use reporting solutions like Telerik, SSRS etc.. as I think they are an overkill for my purpose. At the same time, I am not sure how I can get the printer to print the invoices in a neat pages without cutting off anything.
I am very tempted to just give the output in a webpage and ask my client to print them off from there.
Am I not looking at this the right way? Is this possible?
I could use ITextSharp or something to produce pdf's.. In fact, I think I will go ahead with this if it isn't possible to just output to html page and get the printer to recognize the page breaks somehow.
Because this is a very small job, I don't want to spend too much time on it as the cost of this freelance project is minimal too.
The reason printing to a new page is important is that my client has a few shops he deals with and he would want to print each of his customers their own invoices. I can get him to produce each customer's invoice separately and print them but it is not ideal way to deal with it.
thanks
There is a css property which should tell a browser to break a page: page-break-before.
But if you have a a wide list of browsers to support, it would be better to get some HTML to PDF conversion library or really use iTextSharp (as far as I know there is even a module/class which allows to conver HTML to PDF with iTextSharp) as printing web pages has many issues.
In the past, when I wanted to create a reusable document, I used Word or Excel XML formats.
See: http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats
They are easy to create and tweak, then all you have to do is recreate the dynamic parts in your code. All you have to do is save the document in Office XML format, then open it up in word pad to see where to make your changes.
SSRS has a drag and drop interface for designing reports and has a PDF output option. If the data is in a SQL server database then even with the learning curve it should be easier to do SSRS reports.
Related
The software I am working with gathers data, processes it into an xml, and then sends that xml to be printed out in pdf format. Right now, I am using ActiveReports as my report builder for the pdf. However, I am unhappy with some things about active reports and am looking into other options. Is there any xml-based report generator out there that includes a "layout manager" or some kind of UI that allows easier building of reports? I would like to be able to somehow dynamically put these reports together based on what fields I choose on my WPF form, etc.
take a look into List&Label, it has a lot of options available. there is a nice layout-manager but you can do a lot things programmatically too. just try it out, it has helped us a lot in the past
I was searching the web with a few results, but none of them seems to fit the task. I was looking für possibilites for .NET, but would also like to know how Java/PHP/etc. developers finish tasks like this.
As far as I found out, I have the option to:
Use MigraDoc/PDFSharp and go the "code" way, without any visual designer
I could use HTML and convert it to a PDF (which is the best approach in theory, but practically it's awful to get good looking HTML 1:1 into a PDF file)
I could use some weird MS Word templateing/batch stuff
LaTeX?
What are your solutions?
We use SoftArtisans OfficeWriter
A solution that we settled on in a previous project was XSL-FO. Although it did not have a visual designer, we found it to be very developer friendly and more suitable to run in a server type environment. It also deals with document "flow" a lot better than most of the reporting software that offer a designer. I do know that we had a lot of trouble with Crystal Reports around deployment, COM exceptions being thrown and limitations on how many reports can be generated concurrently. One downside to using XSL-FO is all the syntactic sugar that comes with XML.
This question lists a few XSL-FO engines.
Regarding your "3.) weird MS Word templateing/batch stuff":
I love to use Aspose.Words, a commercial package to create/edit/export Microsoft Office Word documents, without any Office components being installed.
Aspose.Words is capable of doing Mail Merge stuff and write PDF files, so I often start on my desktop computer with a DOC that I edit in Word and use this with Aspose.Words on my server to produce PDFs.
One method I've used before for Windows desktop applications is to use XAML/WPF. The nice thing about this solution is that there are a lot of good tools and documentation around building layouts with XAML. Then you just pass the canvas to a PrintDialog and you're done. If you've been doing a lot with WPF/XAML already this is a very easy solution and I've had a lot of success with it. I learned most of what I needed to get started here: http://www.switchonthecode.com/tutorials/printing-in-wpf
The downside, of course, is your dependency then on .NET and WPF.
Similar to Matt Fs solution of using Crystal Reports, I use SQL Server Reporting Services. You can create add a rdlc file to your solution and use the WYSIWYG editor to design your report. Then in your code, all you have to do it assign your data source to your report in code and it should work. This even supports exporting to PDF.
Seems as no-one has mentioned Latex-based solutions, there was a stack overflow Tex question answered by jason. Short version: uses MikTex, beautiful documents, big hassle to use build/maintain.
Thanks for all your answers...
I finally decided to implement my own solution using Visual Studio 2010 and the Office-Tools... This is not the "perfect" solution, but it was easy & fast to implement, while i still have the flexibility to change the documents witch excel or word...
Downside of course: You need Office installed.
It depends on how you get your template documents. For example, if you have others in your organization responsible for generating the "standard" invoice document, you'll probably have a solution that involves mail merges in the Microsoft Word API, because you need to work with Word-formatted input files. Alternately, if you are merely given the specs for the appearance of the document ("Logo in the top-right, 5 inches down, then a horizontal line two inches below that, then... etc.") You could do it entirely in code. Even if you're designing a solution from scratch, take into account who your document suppliers WILL be, and plan accordingly. Finally, if this is from-scratch for a small set of documents that won't change much (i.e., you're starting your own software company and want to send invoices) don't do it. Just buy something off the shelf or use Word :)
We use xaml FixedPage, can use a designer like Kazaml, it has a lot of layout flexablity, and databinding works great with dynamic objects like expando. In code we bind a datacontext and then render that to XPS, since we need the final output to be pdf we use GhostXPS which is free but has to be executed in a separate processs, there are third party fully managed converters for xps to pdf though.
We use Crystal Reports which comes free with Visual Studio. You can easily create a report/document that is bound to a database or unbound.
For example you could suppress the header and footer, expand the details section to be approx. A4 size, then add either bound fields or use parameters for unbound content. Then at runtime for bound documents set the selection formula to only pull in data for one transaction or for unbound documents just pass in the parameters.
A nice feature of Crystal Reports is there are export features, so export to PDF, Word, etc. Also it's easy to auto print to a specified printer.
Crystal reports can be a pain! On a basic level the outsourced developers for our in house software for Works Order, Invoices etc we use Dev Express although I think it can be pricey.
For reports being generated by the software I ended up choosing to have exports into a raw CSV which of course can be opened up by any spreadsheet software
Where I work we get PDF templates from our clients and we convert them into html templates that we can change out tokens in the page with other info and mail them out to their clients.
The reason we convert them into html is because the text can wrap if any of the info is too long.
The process can be slow since we can only do 1 at a time on a single computer because of a GDI problem. So we have a farm that creates the pdf docs that need to be mailed out.
The GDI problem.
http://support.microsoft.com/kb/939884/en-us/
The hotfix does not seam to fix the problem.
Is there a better way of doing this that would be more efferent or easier to do with out having to change from pdf->html->pdf
Have a look at iTextSharp. You can use the PdfStamper object to dink with the original PDF and spit out customized versions very quickly. You might need to do a little massaging of the source PDF (define some form obejcts in Acrobat, etc) to get it to do exactly what you want, but it's very high performance compared to the process you're describing. We use it to generate thousands of PDFs a day (with customized info inserted for each customer), and it's free. A little tricky to get your head around (steep learning curve). I'd highly suggest buying the eBook "iText In Action"- the samples there make the whole thing much easier to grok.
I need to have the ability to convert and merge various documents into a single Pdf.
The documents could be of varying types, such as Word, Open Office, Images, Text, Web pages (by URL) and the PDF would usually consist of 2-3 documents.
At the moment, we are using BCL Technologies easyPDF with Microsoft Office installed onto the Server. This handles most documents but we haven't had it doing Open Office ones yet.
We currently produce around 100-1000 of these PDF's per day.
The reason I am asking the question is that performance is a key issue. The PDF is generated for users on the fly and so the waiting times we are currently getting of 30-60 seconds is becoming unacceptable.
We have done some caching around documents when they are intially uploaded so the main tasks that happens when a User requests a Pdf is merging a number of already generated Pdf's.
Does anyone else have any other tools they have used that work reliably for most common document types and above all, quickly? When put like that, it seems like I'm asking a lot!
Edit:
Thanks for all the great advice, I'll look into some of these and compare performance.
Just to add to all this, money is not really an object. We're more than happy to pay for different applications to perform each task as well as looking into various hardware options to distribute the load as much as possible.
Merging multiple PDF documents is normally simple enough (as long as they don't need to be merged on the same page) - you could compare your merge performance with something like iTextSharp (.NET version of iText) to be sure it isn't a bottleneck - otherwise the conversion from other formats to PDF is likely the bottleneck.
In almost all cases, the method used to convert X to PDF is to execute the applications print command, targeted at a software PDF printer, to create a temporary PDF file.
This means:
The target application (for example Office) is opened and closed
The document has to travel through the printing service
In your situation, are you converting arbitrary documents submitted by the users, or do the documents come from a stored library of files? If it's a library, you could make a PDF copy of each file as it is added to the library (instead of when the user makes a request), and then only merge the PDF files.
We use ABC Pdf. I don't know if it will be fast enough for your needs, but it seems to work for our use.
I had a very similar issue where we had documents that were already existing in PDF format and needed to allow the user to see them all combined together. We purchased the PDF4NET product which was about $500 from what I recall. It was extremely easy to use and they provide awesome examples of how to use the tools.
O2 Solutions - PDF4NET
Here is the code sample that they provide for merging. The top line looks like it just outputs the file, the second 2 lines allow for streaming the content back to the user.
PDFFile.MergeFilesToDisk( "append.pdf", "unicode.pdf", "multicolumntextandimages.pdf" );
PDFDocument doc = PDFFile.MergeFilesToDoc( "append.pdf", "unicode.pdf", "multicolumntextandimages.pdf" );
doc.SaveToStream( stream );
You say you're using Microsoft Office to open these files, I would imagine this is the bottleneck rather than the actual PDF creation.
Is it possible to distill these documents into a more accessible format (html/xml/database), so that it's not necessary to open office every time a PDF needs to be created?
While I have no PDF conversion suggestions I can say that this problem sounds like one which could be distributed over a number of nodes. Do you find that the PDF generation is CPU-bound or are there other limiting factors? Before expending too much effort on rewriting the PDF library interface you might want to see what the bottlenecks are.
I have a situation where in a web application a user may need a variable list of PDFs to be printed. That is, given a large list of PDFs, the user may choose an arbitrary subset of that list to print. These PDFs are stored on the file system. I need a method to allow users to print these batches of PDFs relatively easily (thus, asking the user to click each PDF and print is not an option) and without too much of a hit on performance.
A couple of options I've thought about:
1) I have a colleague who uses a PDF library that I could use to take the PDFs and combine them on the fly and then send that PDF to the user for printing. I don't know if this method will mess up any sort of page numbering. This may be an "ok" method but I worry about the performance hit of this.
2) I've thought about creating an ActiveX that I would pass the PDFs off to and let it invoke the printing features. My concern is that this is needlessly complex and may present some odd user interactions.
So, I'm looking for the best option to use in this scenario, which is probably not one of the ones I've gone through.
The best solution I have for you is number 1. There are plenty of libraries that will merge documents. From the one I've used the numbering should not be an issue since all the pages are all ready rendered.
If you go with ActiveX you are going to limit yourself to IE which might be acceptable. The only other idea would be to use a smart client so you can have more control...then you could serve up the PDF's via a web service.
I think concatenating the documents is the way to go.
For tools I recommend iText#. Its free
You can download here iTextSharp
iText# (iTextSharp) is a port of the iText open source java library for PDF generation written entirely in C# for the .NET platform. Use the iText mailing list to get support.
I agree with #1. You could do some tests to see what the performance hit would be like.