I have a XSLT sample copied straight from http://www.w3schools.com/xsl/xsl_transformation.asp, which I can't seem to view in Google Chrome. However, it seems to work fine in IE.
Does anyone know why this would be?
EDIT:
The online version works fine, but the local copy does not.
I had same issue with Google Chrome (tested on 13.0.782.215) and (non-JavaScript XSL transformation):
<?xml-stylesheet type="text/xsl" href="simple.xsl"?>
Online transformation works well e.g. http://www.w3schools.com/xml/simplexsl.xml
Local transformation (without server like Apache) show just blank page
I found solution that works for me is to run Chrome browser with --allow-file-access-from-files switch:
// By default, file:// URIs cannot read other file:// URIs. This is an
// override for developers who need the old behavior for testing.
const char kAllowFileAccessFromFiles[] = "allow-file-access-from-files";
Yeah, if you copied the sample down to a file on your computer, the xml won't work with xslt on chromium because it can't find your xslt file provided by just its filename. I've tried put both the xml file and the xslt file to a web server running on my computer and it worked.
If you don't have a web server on your computer, I have no solution with chromium. But maybe you can try a full path, maybe begun with "file:///C:/". Use other browser if that doesn't work...
Good luck,
Max Xie
Related
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.
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 have to open a file via a HTML-link.
The file's location is on another computer and adressed by the IP adress (passing through a custom server tool)
EG:
<a href="http://localhost:PORT/FILE.dotx" download>Download</a>
This works in firefox and chrome just fine, but IE (Version 8) interprets the file as a xml-File and tries to open it directly.
There is no possibility to upgrade or change the client's browser.
Is it possible to force IE to download the file without using PHP, VB or Rails?
(as we don't have a apache server or something like this)
lighttpd.conf sample, requires mod_setenv:
$HTTP["url"] =~ "\.pdf\?dl$" {
setenv.add-response-header = ( "Content-Disposition" => "attachment")
}
This is the only reliable way. IE won't trust MIME types because of an old Apache flaw workaround where Apache sent wrong MIME types and Microsoft "fixed it".
While all pdf files could simply be given the downloading header, I have chosen to show a neater way - only the parameter ?dl activates this behavior. Plain pdfs will still display in-browser and only a link which has ?dl appended gets the special treatment.
I am actually using this technique on my server, but it is implemented in php because I can't make do with the static handlers alone. Since I offer images through this, I also add the Cache: no-transform header to prevent Opera Turbo from recompressing the file to be downloaded.
EDIT: Fixed the Disposition word - has to be capitalized to also work in Webkit-based browsers.
I accidentally deleted a HTML file with dreamweaver. I really would like to get this file back, my backup was not ok. So I would like to retrieve the file using the cache of my browser Chrome. I Googled and found this: LINK But it doesnt work for me, when I download the file and look at it in Notepad all I see is strange characters.
What else can I try to get my file back with Chrome cache?
NirSoft's ChromeCacheView worked perfectly for me.
http://www.nirsoft.net/utils/chrome_cache_view.html
Note that the option to restore the actual files is not that obvious. F4 does it.
It would not be easily extractable from it's hexadecimal representation.
I have recently created a script for extracting files from Chrome and Firefox cache. Check it out at this gist.
See the usage guide in this post.
What you download on this site is a gzip file, if you open that in notepad you will get much the same as on the chrome://cache site. You need to extract it with 7zip or a similar tool first.
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.