IE Display Data URI - html

I'm currently using a solution which converts a pdf file to a data URI. The data URI is then set as an iframe's source and displays the pdf on almost every major browser, I have learned that IE 11 does not like this though. After reading up on it, i realize that iframes don't support data URI's as the source (nor do any elements other than an image URI) and that I can't set a source for an element so I'm unsure how I could achieve the same with Internet Explorer.
I've tried using an embed (learned that it doesn't like data URIs either), an iFrame, initiating a download in a new tab of the file itself (to mimick viewing a it in the browser - no avail) and I'm running out of ideas but unfortunately a lot of people still use Internet Explorer so I'd like to make it compatible. Is there any way to recreate this behavior in Internet Explorer like other browsers do?
Thanks in advance :)

I ended up giving up on this for lack of time to research/test. The final solution was just as well I suppose. I ended up writing the PDF to subdirectory in the website and then setting the source ofthe iframe to the download method of the file. Tad slower than my original implementation but it works for legacy purposes. When will IE die!

Related

Reference local file image file in HTML

I am looking for suggestions on how to reference a local image file in HTML. The HTML code will only ever be used locally and never be published on a network of any type. I find that this code
<img src="file://l:/Test FFHP data/1042545.tif">
works well in Internet Explorer and Edge. It does not work at all with Chrome or FireFox.
Please give me some direction. I am hoping my users will be able to use their preferred browser.

FireFox appears to not support IFrame Data URIs

When I try to load a PDF Data URI into an iframe (eg, src="data:application/pdf;base64,...") in FireFox (18.0.2 [current release], OSX) it instead opens a download window.
For an example, check out the website JSPDF.com
The same site works fine in Aurora (20.0a2)
Is this a known issue with Firefox? Is it not conforming to the spec...?
Aurora has a built-in PDF renderer that can render PDFs inline.
Current release as of yesterday does not have that; it first appears in Firefox 19, which is about to be released.
A browser without a PDF plug-in or built-in PDF renderer will simply offer to download or open in a helper app a PDF that's loaded in a window as you're doing, which is exactly what you see.
As far as the spec goes, both behaviors are compliant. Nothing says a browser needs to support inline rendering of PDF.
You need to modify the options :
To :
I had a very similar problem with Firefox, iframes and data URIs. I resolved it by checking that there was no spaces in the data type definition. Mine was text/html, so instead of writing this:
src="data: text/html, ..."
it had to go like this:
src="data:text/html,..."
I conclude that firefox didn't understand the content type with spaces, thus considering it was a downloadable file.
This might be caused when there is no adobe reader installed. I'm not sure though. As I can't test it here as I don't have a Mac with Firefox running.

Linking from a web page to a specific section (anchor) in PDF document

There is a standard from Adobe that in theory specifies opening PDF documents from a link clicked in a browser in a way to open specific sections (AKA "anchor", "named reference") of PDF document. This functionality should be of great help if one would like to refer to a specific portion of large PDF (such as some standard or specification).
However, from what I see now, support for this standard is close to non-existent.
For example, these links should open Scala Reference PDF at section 3.2.6, "Annotated Types":
http://www.scala-lang.org/docu/files/ScalaReference.pdf#subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#nameddest=subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=23
(Techincally, variant #3 should open page #23, which is essentially the same destination)
Is there a working way (may be with a couple of shims, proprietary wrappers or whatever else) to make this work on majority of systems? What is the usage share of Adobe Reader plugin, should I care about other systems?
If it's not possible, at least I'd like to find a working solution for every platform (i.e. Windows, Linux, Mac) that I could recommend to my site's users if they want to be able to use named destination links.
From what I've tested:
Windows, MSIE/Firefox/Chrome, Adobe Acrobat Reader plugin - all variants work with version 9+, but:
MSIE has a weird caching issue (i.e. anchor does not work until document was cached)
Older versions do not work
It has issues with link format: generally, it should be regular absolute link to a real web server, starting with "http://". Relative links, samba-style links (\\HOST\dir\file.pdf#something), anything else besides "http" (or probably, "https") scheme won't work
Windows, any browsers set up to run Adobe Acrobat Reader as a separate process - does not work
Windows, any browsers, FoxIt Reader - does not work
Windows, any browsers, CutePDF - does not work
Linux/Konqueror/Okular - only variant #1 works
Linux, any other browsers set up to run Okular or any other PDF viewer as external process - does not work (as browser does not pass any "#arguments" in a command line)
Any OS, Firefox 15+ PDF.js internal PDF viewer - does not work
I'd appreciate if you'd try it to test in various different combinations.
What seems to work in general is variant #4 but using the number of the page as in actual division into pages in the PDF document, in this case
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=31
The PDF document has page numbers that start from the content proper, after the table of content, but that numbering differs from the one to be used in #page=...

Problem with displaying Smarty template in Internet explorer

I have converted my existing website to Smarty template (my very first project with 1 day of smarty experience under the belt)
Prior to conversion my website looked fine in IE and FF.
After the conversion FF still looks okay however in IE everything falls apart.
I have tried comparing the source code in IE and FF and everything looks exactly the same.
Any help is appreciated.
Since Smarty is just the templating system that generates the HTML sent to the browser, the issue probably occurred when you split up your existing site into parts. Unfortunately it isn't very easy to find out what is wrong with a full project on SO. That said, here are some tips on debugging the issue.
Load your old site and copy the source from the browser (doesn't matter which browser as the server sends the same HTML*).
Load your new site and copy the source from the browser.
Diff the two sources to find the differences.
I think that's the best place to start. If the new site is sending the exact same HTML to the browser, then it would seem that some resource isn't being loaded (bad link) or javascript isn't being executed in IE, which should be separate from Smarty. For that check IE's Developer Tools and make sure no CSS is getting a 404 and no js exceptions are being thrown.
*As long as you aren't modifying things on the server based off the User-Agent sent, which is not common.

.png images display in IE8 alone but not inside a page

It's been a while since I did serious web development. Now I meet a host of brand new problems I'm no longer familiar with..
I have some .png images for various icons in my web page. What I find is that whenever I edit these images, they stop working inside a page in IE8. That is, they (usually) display OK when I first open the page, then are replaced by the placeholder icon on refresh. Sometimes, some of the icons display and others, with the same src, don't.
My image tags are nothing fancy, typically:
<img src="images/misc/smallreport.png" alt="Report" />
When I right-click an icon in the page and select "properties", protocol, type, address and size are shown as "Not Available", and dimensions are incorrect (size of the placeholder, I bet).
If I open the images directly in IE (ie. not within the page), they work just fine.
I have used Paint.NET to edit the images, but have also tried saving them with Paint.
Right now, I am working right off the hard disk (ie. not through a web server). And, oh yes, none of this happens in Google Chrome.
What's going on here?
check the path to the file is correct - can we see the tag please.
Well, we learn something new every day..
I mentioned that I'm running this directly off the harddisk? Now, it turns out the html page (which I had gotten off a coworker) was blocked "to help protect my computer", as Windows does.
This is no big surprise, lots of files I'm working with originate on other computers, and I usually don't worry much about it (except with executables, which won't run until unblocked).
It seems, however, that when IE8 loads such a blocked HTML file, its security settings adjust somehow, and - well, I can only guess at the details, but as soon as I right-clicked the HTML file, selected Properties and clicked the "unblock" button, the problem went away.
Something similar happened to me once, I tried hard to find what was wrong, then I realized I was saving (from Photoshop) the file as PSD but with extension .png. Make sure you're not doing the same.
Also:
Clear temporary Internet files
Verify that the Show Pictures option has not been turned off
Make sure that the Toggle Images.exe Web accessory is not present and disabling images
Make sure that a third-party Internet security, firewall, or cookie-blocking program is not causing the problem
Enable the Auto-Select encoding option
Source
It might be that the website you have browse has a lack of support
for an IE browser. IE is a nightmare for all web developers & Web designers.
It might be the developer of that website didn't care for an IE display because
of IE issues. Perhaps IE is trying to create a web standard to increase their
sales and marketing strategy. That's why don't care the modern Web development standard.
Why Chrome or Firefox or Safari, it's a free anyway.