Extension talk:EmbedPDF

= Degrading Gracefully - Mac OS X and inline PDFs =

Hi, this extension works pretty well, it's nice and simple, and does the job as expected. I have however made a small change to the code to help it degrade gracefully, for example:

Where I work currently has a mixed environment of Mac OS X and Windows. Firefox on OS X does not display inline PDFs, basically adobe haven't made a plugin, so it will show a 'this page has missing plugins' and searching will fail because there is no official one.

Sam Gross has made a Intel-only |a firefox addon quicklook plugin that allows firefox to view them actually in browser, so that scratches my itch.

but as it is currently, if any inline-pdf viewer is not found, it simply displays white space, which tells the user nothing if they were not expecting a pdf to be displayed inline on page and even if they were it does not help them in the slightest and provides no solution.

The same would go for a windows computer with adobe not installed.

I've modified the HTML output, just on line 26, i sourced this solution |from here.

That at least gives the user a bit more info. What does the developer think? I think that this(or something similar) should be integrated. feel free to use that. :)

To provide a more complete solution for users here I wrote a quick and dirty php file hosted elsewhere that serves my needs locally, that does some quick checks to see if they're using firefox, if they're on an intel or ppc mac (we only have 1), or if they're running something else.

if they're on an intel mac it'll redirect them to the plugin, ppc it'll tell them they're out of luck and anything else it'll tell them to install adobe reader.

But, for most MediaWiki projects, I wouldn't think it's appropriate to be directing to third party plugins for support or anything els, so telling them what the problem is and an alternative is enough :).

here's the quick and dirty php hack redirect if anybody finds it useful. it's literally the first code I've posted to the Internet, it works for me, sanity check it for your needs.

If anyone else than me finds this useful, dropping me a note on my userpage would be nice :).

Posty

update: i just had a look at some of the other issues on this page, you'll see that others are having the issue, and had no idea of the fix.

mine is similar to the solution down the bottom, except mine has some explanatory text, and a link to the file.

The icon for a pdf is interesting, but not supported by default in mediawiki, there's no pdf icon, but my text and link works.

= Docs from localhost = Hy there! I don't really have experience with this kind of extensions and I was wondering if you could help me. I am using your code and unfortunatelly it does not work when I want to embed docs which are on the local host. Do u have any idea why :(

Answer
Sorry--I just can't get you exactly...

What is the wiki code you're using? Is it something like " http://localhost/my/path/to.pdf "? Does any error occur? Is your Web server okay with PDFs (what does it show if you open "http://localhost/my/path/to.pdf" in a Web browser)?

--Dmitry Shurupov 16:20, 21 February 2009 (UTC)

As written, the regex insists upon a period character (&lsquo;.&rsquo;) in the domain name (like &lsquo;mydomain.com&rsquo;). Fix this by inserting a question mark after the period character: in EmbedPDF.php, change

to

Scorwin 15:31, 10 November 2009 (UTC)

= URI error (semantic forms extension) = Thanx for this extension, it works great here. However I got one issue that maybe easily can be solved. I like to use this extension together with the semantic form extension. In a form the user can upload a pdf-file which will be printed on the outputpage. I like to embed the pdf and not only the filename. I got it working with images but can't get it to work with EmbedPDF. The variable is called so  should have to do the trick. But I got the 'Error: bad URI in !' message after saving the page. I guess it means it doesn't recognize the '{'. Is there a way I can make an exception in the extension that it does read the whole text between and as a filename?

-Jos, 19-2-2009

Answer
Allowing "" in is rather simple--you just have to add few lines into the "embedPDFHandler" function. It will look like this:

However, it will make a trick if the "" string will be transformed to the URI by semantic forms extension. I don't know how it works--so, I'm not sure if it is okay.

If the problem still exists, please, let me know--I'll give the semantic form extension a try...

--Dmitry Shurupov 16:19, 21 February 2009 (UTC)

Still same error
Thanx for the answer. I added the lines though I still got the same error. I'm not quite an expert in php so forgive me if there might an 'easy' solution to my problem.

I guess I got images working because images in wiki got a special syntax: instead of the -tag. Perhaps there is a way to hack the code so that something like Pdf: can be made instead of ... ? --Jos, 26 February 2009

= Installed, no errors, just not displaying the PDF in Firefox =

I've installed EmbedPDF.php in the extensions directory. I added the requireonce line.

I created a new page, with one line:

http://www.mydomain.org/wiki/images/e/e0/Hr1.pdf (I've removed the domain name)

and the page is there, but the pdf isn't embeded in Firefox 3.06. It's Embeded in I.E. 7.x just fine.

Answer
Please, read the "Usage" section.

You have to add the lines like this for URLs:

And lines like this for PDFs uploaded to your MediaWiki:

= Suggestion = Thanks for this extension. It's only in Internet Explorer (tested on v. 8) I'm having difficulties viewing the embedded pdfs. But I still wanted to use this extension, since there aren't any other ones dealing with this problem. I've added a link to the object, so browsers that won't show the embedded pdf, come up with a link instead. Now Opera, Firefox and Chrome show the embedded pdfs properly, while Internet Explorer shows a link. This is an acceptable solution for me, and maybe this idea would work for others as well?

Add the following around line 25-27 in EmbedPDF.php:

It seems that the new feature compability view in Internet Explorer might have something to do with this problem. Any ideas, Dmitry? -- Marius, July 2009