Is it possible to set format of PDF to generate in wkhtmltopdf?
From my PC wkhtmltopdf generates format "PDF-1.4"
But remote Ubuntu 14.04 server that is generating pdf with a 'virtual' X server using xvfb giving format PDF-0:
The only problem is opening generated pdf file in Chrome :)
Chrome cannot open PDF-0.
Thanks
It looks like the resulting PDF from xvfb might not be 100% correct. There are some problems with the meta data. It's missing the creator for example. Also PDF-0 does not appear to be a valid PDF version. There might be other problems with the document. This would be a possible reason why the generated file does not appear in Chrome.
A good way to examine the document would be using Acrobat's preflight tool. It will inspect the document for potential problems, and that could give provide a clue on what's going on. The tool is located under "Print Production" in Acrobat. The profile to run is called "Report PDF syntax issues". I'm sure there are other tools out there that can also explain what is wrong with the document.
This section should provide a resolution to the problem. As mentioned in the comments below, updating the QT version from 4.8.6 to something newer should resolve the issue. The working setup appears to be running 5.3.2, while the non working one is under QT 4.8.6.
May i recommend phantomjs as an alternative (headless tool, no server x needed at all) to xkhtmltopdf.
HTML to PDF rendering is very straight forward (e.g. http://phantomjs.org/screen-capture.html )
Bounty answer:
Apparently QT 4 and QT 5 behave differently when printing to a PDF. Thus, your problem can be solved by upgrading the QT libs on your server.
You may consider filing a bug against wkhtmltopdf since your described behavior obviously renders it incompatible with QT 4.
See also original comment here.
Related
I'm on a Linux environment, and I'd like to make standalone HTML widgets in R using Leaflet and DT, and generating the HTML with htmlwidgets plugin. The problem is that when I try to open these generated HTML files, the browser is blank, and some sort of JSON parsing error occurs according to the console.
It only happens in Linux. I've already tried it on Windows with Rstudio, and it worked just fine.
I also found out that on Windows, the javascript widget is base64 encoded inside the HTML file, unlike on Linux.
I don't think it's a problem with htmlwidgets, since there are other widget libraries that I use (rPivotTable, plotly, etc.), and they work just fine on Linux with htmlwidgets.
R sessionInfo() output:
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.4 LTS
The R packages and versions:
plotly_4.5.6
ggplot2_2.2.0
rpivotTable_0.1.5.10
htmlwidgets_0.8
DT_0.1
leaflet_1.0.1
Any idea what causes this? Have anyone ever experienced something similar? I've read questions with similar symptoms, but none of the answers solved the problem for me.
Couple of items here: first look at your html output code in the browser for error and second, try updating d3r package. I ran into similar issue where we have security that blocked the packages going out and fetching the javascript packages. Since, d3r was updated to make internal lookup the default option which solved our problem.
I have recently downloaded my facebook archive, which is a very old account I started in 2009.
There is some conversations I would like to read, the main problem is that messages.html inside the zip weights 98 mo.
Unfortunately,neither mozilla or google chrome can open those 21109 lines of codes in a webview without crashing.
I could open the document with Notepad++, but it's just like searching for a needle in a haystack.
Could you help me please ?
Further to the LINUX comments, we can only assume you are trying to look (or search) inside the html file. You can use any good, text editor like: TextPad, EditPad, etc. You can also download "Unxutils" (not it is not mis-spelled) and use the Windows ports of grep/sed/awk/head/tail/cut etc. There maybe comments or answers posted to use Cygwin which work fine, but require the use of DLL libraries and such. The UnxUtils are stand-alone exe files are work right out of the box with no installation required.
If you are interested in getting some readable files for each conversation you can use the first part of this tutorial which generates csv files which are easily searchable.
http://openmachin.es/blog/facebook-messages
I am working on a local project (read: offline) and I am trying to get Brackets' live preview to work since it comes in handy quite often.
Right now I have opened my project files using Brackets' "open file" option since it supposedly maps the path to the source files. Although I am getting an error saying In order for Live Preview to connect, Chrome needs to be relaunched with remote debugging enabled.
I have read else where that Chrome, by default, does not need to be relaunched for that change and that Brackets force this flag by itself.
I have tried reinstalling Brackets, launching with another project and searched all over Chrome for this flag and did not find any thing.
Any tips?
This page shows you how to instal remote debugging! It's a Chrome dev tool. It's geared towards android apps for whatever reason, but I had that same error, and following the instructions on that page helped me launch the brackets page.
If that doesn't work, here are some troubleshooting tips that have helped me out with live preview:
1) Make sure your filename has a .html at the end
2) Use different browser (I've found chrome to be a bit finicky with brackets)
3) Make a different blank file, launch that, then launch the file
Open the folder, not the file, and then select the file.
I'm trying to debug some JavaScript for a Rails project and its incredibly frustrating to go line by line when the source code is compressed in the Sources developer tab.
I know this compression is done by Chrome through the body variable. What I want to know is if there is any way to stop Chrome from compressing files in source view, i.e:
\application.js?body=1 --> \application.js
Thank you for your time.
Compression is being done by Rails. Disable it in your configuration:
# config/production.rb (or whatever environment you're in)
config.assets.compress = false
You might want to investigate a new feature in Chrome called Source Maps.
Source Maps allows Chrome to map the compressed source code it receives to the uncompressed original, which in turn means that you can debug the code, even though it's been compressed.
This feature should help you get around this kind of problem without having to change the compression settings on your server.
You can read more about it here: http://blog.mascaraengine.com/news/2012/4/16/sourcemap-support-in-chrome-greatly-improves-debugging.html
I believe this feature is still in test and not yet in the final release version of Chrome. I'm sure it will arrive in due course, but for the time being you may need to install the "Canary" version of Chrome, ie the pre-release version that includes all the forthcoming features that they're still working on.
I'm trying to get TypeScript source debugging working in Chrome, but I'm running into two specific and perhaps related problems.
The first is that the comment generated by the TypeScript/WebEssentials compiler that's supposed to identify the location of the source map file looks like this:
//sourceMappingUrl=MySourceFile.js.map
But Chrome won't read that file. It seems expect that the comment will look like this:
//# sourceMappingUrl=MySourceFile.js.map
If I manually change the comment to that, and refresh my page, then magically the references to all the .ts files show up as sources in the Chrome Developer Tools.
However, that leads to my second problem, as the files don't actually get loaded. The .ts source file that Chrome should be trying to download is http://localhost/MySourceFile.ts, but the one that it's actually trying to download is http://localhost/C:/source/web/MySourceFile.ts. That sort of makes sense, as the opening attributes of MySourceFile.js.map look like this:
{"version":3,"file":"tmp1523.tmp","sources":["C:/source/web/MySourceFile.ts"
But that obviously doesn't work with Chrome, as it interprets the source-map location to be entirely relative, and IIS (quite correctly) won't serve up any URL looking like http://localhost/C:/source/web/MySourceFile.ts.
So, with respect to these two problems, is it Chrome or the TypeScript source-map feature that's doing it wrong? And what's the recommended way of doing this?
I'm using Chrome 25.0.1323.1 dev-m, with TypeScript 0.8.1 and WebEssentials 1.8.5.
This is an issue with version 1.8.5 of Web Essentials (the version currently available from the Visual Studio Gallery). The latest nightly build (at time of writing http://madskristensen.net/custom/webessentials2012.vsix) fixes the problem and generates the map linkage correctly.