About HTML to PDF

As a memo, note the problems encountered in HTML to PDF.

Do not specifically do this thing at the time do not know, the network can convert HTML to PDF resources are not too much, there are a lot of use there are some problems. Can perfect the page in a site (this is said that the page in a site refers to the non-intentionally made to contain only simple HTML elements of the page) converted to PDF is a lot of items are charged.

Itextsharp is not discussed here, because we indicate that the source is an HTML page, ITEXTSHARP support for HTML is a bit of a chicken, his flexibility is reflected in the manual drawing of the PDF.

Our system was originally used Pechkin this open source product, this product is simple to use, and the converted PDF and the original page can not see the difference. However, Pechkin relies on many 32-bit DLLs so that applications must run in 32-bit processes.

In order to make the program run in a 64-bit process, a lot of attempts were made, and finally found this project: HTTPS://GITHUB.COM/VILPPU/OPENHTMLTOPDF

Openhtmltopdf is the same as the internal principle of Pechkin, which encapsulates the wkhtmltopdf to achieve the transformation.

Wkhtmltopdf internal contains a browser engine: Webkit, so it can restore the HTML page is more realistic, the official view Wkhtmltopdf has also published the use of other browser engine branch projects, interested can also go to try.

The openhtmltopdf contains 32-bit and 64-bit wkhtmltopdf two applications, using commands to invoke different EXE to achieve compatibility in both processes.

It also provides rich invocation parameters to use: http://wkhtmltopdf.org/libwkhtmltox/pagesettings.html

Of course, because the wkhtmltopdf itself is relatively old project, there are some parameters I tried and did not get any effect.

Examples of Use:

using(WebClient WC =NewWebClient ()) {WC. Encoding=Encoding.UTF8; stringHTML =WC.                downloadstring (URL); varDocument =pdf.from (HTML). Ofsize (OpenHtmlToPdf.PaperSize.LetterRotated). Withglobalsetting ("Margin.top","0.4cm"); if(Intptr.size = =4) {document= document. Withobjectsetting ("Load.zoomfactor","1.5"); }                varresult =document.                Content ();                HttpContext.Current.Response.Clear (); HttpContext.Current.Response.AddHeader ("content-disposition","attachment;filename=pdf"+ DateTime.Now.ToString ("YYYYMMDDHHMMSS") +". pdf"); HttpContext.Current.Response.ContentType="Application/octet-stream";                HttpContext.Current.Response.BinaryWrite (result); HttpContext.Current.Response.End ();}

This thing also encountered some problems in use.

Look at the code can be found in the 32-bit process, I made a special processing of the document, using Load.zoomfactor to zoom in.

Since the PDF generated in the 32 bit in use is smaller than the PDF generated in the 64 bit, I did not find and directly solve this weird problem, and finally found this magnified parameter (which should be a parameter to the browser engine operation) so that the PDF generated in both environments looks the same size.

Of course, in fact, we generally do not use a Web program to support two CPU processes, just to make different developer machines present the same content during the development and debugging phase.

About HTML to PDF