Currently using pdfkit, for the most part it's been great to use.
The only issue is line thickness. Borders on the source html look great, on the pdf generated look much thicker.
Also thickness varies in the document. On lines of the same width, it appears thicker in places. Even borders on the same div may appear thicker on the 3 of the 4 borders, even though they have the same CSS.
Any way to remedy this?
Well if you explore the extended help -H on wkhtmltopdf you would find a options called dpi
So perhaps you can set a dpi in pdfkit something like this
PDFKit.configure do |config|
config.wkhtmltopdf = '/path/to/wkhtmltopdf'
config.default_options = {
:page_size => 'Legal',
:print_media_type => true,
:dpi => [your dpi setting]
}
# Use only if your external hostname is unavailable on the server.
config.root_url = "http://localhost"
end
Note
Having said that it you examine the help deeply you would know that that it states
-d, --dpi <dpi> Change the dpi explicitly (this has no
effect on X11 based systems)
I clearly state it has no effect on system that based on X11 so I would rather see that of any help for you
Other options
So dpi options is hardly of use what are other options ?
Well in fact there is one check this link and trace to last comment and see some of that help in your quest (i.e try increasing the resolution of the xvfb in case if your running an xvfb server)
Hope this help
Related
When searching for the word find in the PDF file in this Link before Ghostscript optimization the results will give pages number 4,7 and 13 but after the optimization it gives only pages 4 and 13 ignoring page number 7, the script im using for the optimization :
D:/gswin64c -sDEVICE=pdfwrite -dMaxSubsetPct=100 -dAutoRotatePages=/None -dMaxInlineImageSize=0 -dPDFSETTINGS=/ebook -dColorImageResolution=96 -dDetectDuplicateImages=true -dColorImageDownsampleThreshold=1.1 -dDOPDFMARKS -dUseTrimBox -sOutputFile="D:/temp/search_text.pdf" -dNOPAUSE -dNOGC -dBATCH -dNumRenderingThreads=8 -c 50000000 setvmthreshold -f "D:/temp/iphone_user_guide.pdf"
I've tried to add several fonts related parameters to the script such as -dEmbedAllFonts=true and pointing to fonts path also I've tried to play with the parameters by eliminating some but with no result
what could be the cause of this problem?
Ghostscript doesn't do 'optimization'. See my answer here:
GhostScript issues with a CropBox
for some details on what it does do.
Wihtout seeing your file I cannot tell you for certain what the difference is, but most likely the missing text has been drawn as images instead of text for some reason.
By the way, a lot of the options you are sending have absolutely no effect (eg NumRenderingThreads, for a device which doesn't do rendering). You should NOT select -dNOGC, that's a really bad idea, -dDOPDFMARKS is already set for the pdfwrite device.
I'm using highcharts-convert.js with phantomjs, and I'm having some text-overlapping issues when exporting the charts.
I believe the reason is Chrome on OSX renders fonts differently than my ubuntu server does. So when the client's browser builds the SVG the text does not overlap (I have indeed confirmed this by capturing the POST and rendering the svg in Chrome), but when phantomjs renders the text on ubuntu its slightly wider so there is overlap.
I believe that if I export the options JSON rather than SVG, ubuntu will lay out the text according to its own font rendering, and nothing will overlap.
Does that make sense? If so, how can I get highcharts to POST the options JSON rather than SVG?
I have this process that I can use to rig everything up, but it feels like there should be a better way...
var chart = graphContainer.find(".graph-body div").highcharts();
var chartOptions = chart.options;
delete chartOptions.chart["renderTo"]; // this creates a circular reference
// provide extra options to override the chart's defaults here...
$.extend(chartOptions.chart, {backgroundColor: "#FFFFFF", spacingLeft: 30, spacingRight: 30});
// wrap this up and POST it to the server...
console.log(JSON.stringify(chartOptions));
We have a Ruby on Rails application that needs to convert a PDF into a PNG with a transparent background. We're using rmagick 2.13.1. On our development machines the following code works exactly how we want it.
pages = Magick::Image.from_blob(book.to_pdf.render){ self.density = 300 }
page = pages[0]
image_file = Tempfile.new(['preview_image', '.png'])
image_file.binmode
image_file.write( page.to_blob { |opt| opt.format = "PNG" } )
We thens save the image_file and all is peachy. When we deployed to a review server on Heroku, though, the generated image has a white background. It turns out that Heroku's cedar stack is using imagemagick ImageMagick 6.5.7-8 2010-12-02 where we're using ImageMagick 6.7.5-7 2012-05-08 on our development machines.
I've scoured the net for older posts that might apply to the older version to try and figure out how to generate the transparent PNGs. It's surely supported, but, so far I haven't been able to figure out the right combination of settings.
To verify that it wasn't the PDF generation that was the problem, I downloaded a PDF generated on Heroku and successfully converted it using the above code (slightly modified to read the file in instead of generate it) to a transparent PNG.
Some of the things I've tried in various combinations are:
page.matte = true
page.format = "PNG32"
page.background_color = "none"
page.transparent_color = "white"
page.transparent("white")
So, the question is "is this possible?". If so, which settings do I need to set on the image before writing it out?
I'm also investigating including a compiled binary of a more up to date Imagemagick on Heroku.
Any help is appreciated.
This should no longer be an issue, as Heroku has ImageMagick versions 6.7-6.9 on their various stacks.
I have been looking in the documentation but can't find the answer. How can I specify the page size of my pdf document and what are the available page sizes? I keep on looking and looking but I can't find good documentation. Please point me to a URL or let me know how can I code some page size into my PDF document.
Oh and I don't want to do that on any config file because I need to generate PDf documents of different sizes.
NOT in config file...
PDFKit.configure do |config|
config.wkhtmltopdf = `which wkhtmltopdf`.to_s.strip
config.default_options = {
:encoding=>"UTF-8",
:page_size=>"A4", #or "Letter" or whatever needed
:margin_top=>"0.25in",
:margin_right=>"1in",
:margin_bottom=>"0.25in",
:margin_left=>"1in",
:disable_smart_shrinking=>false
}
end
You can set the page size when creating a new PDF like this:
kit = PDFKit.new(source, :page_size => "Legal")
PDFKit uses WKHTMLTOPDF which in turn uses QPrinter. You can find the available sizes in the QPrinter documentation (there's a bunch), but its pretty safe to say that any size paper you want is available. Also, you can set a custom size if you can't find what you need.
NB: If you don't set a default option for page_size in a config somewhere AND don't supply one in your method call, PDFKit will use its internal default (Letter). See line 10 of lib/pdfkit/configuration.rb
Pdkit accepts custom sizes:
PDFKit.configure do |config|
config.wkhtmltopdf = `which wkhtmltopdf`.strip
config.default_options = {
:page_width => '1682',
:page_height => '2378'
}
end
The sizes must be in milimeters (wkthmltopdf documentation).
Since it's using wkhtmltopdf to generate the PDFs I'm assuming you can use the same options that it supports. In a wkhtmltopdf manual I found, it mentions the following site for a list of sizes:
http://doc.trolltech.com/4.6/qprinter.html#PaperSize-enum
To set the page size, you can use the :page_size option like so:
PDFKit.new(html, :page_size => 'Letter')
I am using ABCPDF to print a PDF file to a local printer via EMF file. I've based this very closely on ABC PDF's sample "ABCPDFView" project. My application worked fine on my Windows 7 and Windows XP dev boxes, but when I moved to a Windows 2003 test box, simple embedded fonts (like Times New Roman 12) rendered completely wrong (wrong spot, and short and squat, almost like the DPI's were crazily wrong).
Note that I've hardcoded the DPI to 240 here b/c I'm using a weird mainframe print driver that forces 240x240. I can discount that driver as the culprit as, if I save the EMF file locally during print, it shows the same layout problems. If I render to PNG or TIFF files, this looks just fine on all my servers using this same code (put .png in place of .emf). Finally, if I use the ABCPDFView project to manually add in a random text box to my PDF, that text also renders wrong in the EMF file. (Side note, if I print the PDF using Acrobat, the text renders just fine)
Update: I left out a useful point for anyone else having this problem. I can work around the problem by setting RenderTextAsText to "0" (see code below). This forces ABCPDF to render the text as polygons and makes the problem go away. This isn't a great solution though, as it greatly increases the size of my EMF files, and those polygons don't render nearly as cleanly in my final print document.
Anyone have any thoughts on the causes of this weird font problem?
private void DoPrintPage(object sender, PrintPageEventArgs e)
{
using (Graphics g = e.Graphics)
{
//... omitted code to determine the rect, used straight from ABC PDF sample
mDoc.Rendering.DotsPerInch = 240 ;
mDoc.Rendering.ColorSpace = "RGB";
mDoc.Rendering.BitsPerChannel = 8;
mDoc.SetInfo(0, "RenderTextAsText", "0");//the magic is right here
byte[] theData = mDoc.Rendering.GetData(".emf");
using (MemoryStream theStream = new MemoryStream(theData))
{
using (Metafile theEMF = new Metafile(theStream))
{
g.DrawImage(theEMF, theRect);
}
}
//... omitted code to move to the next page
}
Try upgrading to the new version of abcpdf 8, it has its own rendering engine based on Gecko and so you can bypass issues like this when abcpdf is using the inbuilt server version of IE for rendering.
I was originally RDPing in with 1920x1080 resolution, by switching to 1024x768 res for RDP, the problem went away. My main program runs as a service, and starting this service from an RDP session w/ 1024x768 fixes it.
I have an email out w/ ABC PDF to see if they can explain this and offer a more elegant solution, but for now this works.
Please note that this is ABC PDF 7, I have no idea if this issue applies to other versions.
Update: ABC PDF support confirmed that its possible the service is caching the display resolution from the person that started the process. They confirmed that they've seen some other weird issues with Remote Desktop and encouraged me to use this 1024x768 workaround and/or start the service remotely.