Conditional load of PDF.js

"pdf.js is an HTML5 technology experiment that explores building a faithful and efficient Portable Document Format (PDF) renderer without native code assistance."

You need a browser which supports HTML5 well.

FYI it works perfectly well with IE9 (not with older versions)

Maybe integrate http://thecodeabode.blogspot.co.uk/2011/01/detect-adobe-reader-plugin.html in the future.

Sorry for the delay...
Pdf.js is still under heavy development so I regularly try to update it. But since the first version I tried (july 12) it was working with IE9.
So my advise would be to try an keep your pdf.js as up to date as possible (even if the process of downloading it from github and rebuilding is kind of long and painful)
Hope this helps.

I just integrated http://thecodeabode.blogspot.co.uk/2011/01/detect-adobe-reader-plugin.html to 7.x.
PDF.js will be loaded only without PDF reader (except Safari with default OSX Preview which can't be detected with JS).

@NadimBak maybe you can merge to 6.x

Sorry but for me this "solution" kind of defeats the purpose: the hole point here of using PDF.js is to have a " web standards-based platform for parsing and rendering PDFs", meaning a reader that would give same result whatever computer or local configuration is.
That being said, as PDF.js will not work with browser not HTML5 friendly, something nice would have been to detect for exemple browsers like IE8 (and older) and try to load the local native pdf reader. BTW, that local pdf reader is not always Adobe, can be foxit reader, sumatra... etc. So unless you make this a configurable option in PDF module's settings, I don't really agree...

Option setting is added. You can control whether always usd pdf.js now.

I don't feel like this really works the correct way that it should. By default we should try to use pdf.js. Failing that we should detect Acrobat/browser plugins. And failing that output a message telling the user that their browser is incapable of displaying a pdf inline.

Here is a patch that does just that.

At the moment it's testing to see whether the browser implements because this is the main feature missing from IE8 that prevents pdf.js from working. There may be a better way to check if pdf.js is going to work in a particular browser but I think this is going to solve most people's issues.

Sorry, changing this back to D7

Actually, scrap that last patch—it wasn't good enough. Here's a better one.

I tried patch #13 and found that I can't use browser default plugin by unchecking "Use pdf.js even users have PDF reader plugin".

It will only attempt to use the browser plugin if it detects that the browser is incapable of rendering canvas elements. Were you testing this on an old browser?

The latest Chrome, Firefox and Safari

All those browsers are capable of using pdf.js so they will.

The acrobat fallback is only for older browsers that can't use pdf.js. Try it in IE8. If you wanted to give users the option to only use browser plugins then you could but I think they way I have it set up is the best at ensuring the pdf is displayed in as many browsers as possible:

• any modern browser will use pdf.js
• any older browser that doesn't have canvas support will attempt to use the browser plugin
• any older browser that doesn't have a plugin will get a message saying the pdf can't be displayed. (This could probably be adjusted to add a link to the pdf so they can download it.)

If you wanted to give users the option to only use browser plugins

There has been such option "Use pdf.js even users have PDF reader plugin" to choose using pdf plugin or not since https://drupal.org/node/1804106#comment-6709240. So any patch should make it work correctly as usually.

That link doesn't go anywhere.

Nevertheless I don't think you're understanding what it is that I'm proposing. I know that you have added a setting that allows users to only use pdf.js regardless of browser plugins but this method doesn't degrade gracefully for browsers that are incapable of using pdf.js. The method that I am proposing uses the acrobat detector in the event that a browser is incapable of using pdf.js. This means users of modern browsers such as Safari, Chrome, FF and IE9+ will use pdf.js and IE8 and below will use acrobat if it's installed. This means nearly everybody will get a pdf displayed and only people with old browsers and no acrobat (pretty much no one) will get a message telling them that their browser is too old to display the pdf inline.

By the way, my patch does not interfere with your existing setting. As you can see by this code I am only adding the acrobat detection and the code that manages the graceful degradation (default.js) if the setting is off. So it will still work as previously for users that have this setting on.

function theme_pdf_formatter_default($variables) {
  global $base_path;
  
  $file_url = file_create_url($variables['file']->uri);
  $module_path = drupal_get_path('module', 'pdf');  
  $library_path = libraries_get_path('pdf.js');
  $iframe_src = $base_path . $library_path . '/web/viewer.html?file=' . $file_url;
  
  $force_pdfjs = $variables['keep_pdfjs'];
  
  // Build the iframe tag--D7 style!
  $content = array(
    '#type' => 'html_tag',
    '#tag' => 'iframe',
    '#value' => $file_url,
    '#attributes' => array(
      'class' => array('pdf'),
      'webkitallowfullscreen' => '',
      'mozallowfullscreen' => '',
      'allowfullscreen' => '',
      'frameborder' => 'no',
      'height' => '600px',
      'src' => $force_pdfjs ? $iframe_src : '',
      'data-src' => $iframe_src,
    ),
  );
  
  if ($force_pdfjs != TRUE) {
    // We're not forcing pdf.js on everyone so add the js that is going 
    // to do some feature detection and try to display the pdf anyway we can.
    drupal_add_js($module_path . '/js/acrobat_detection.js');
    drupal_add_js($module_path . '/js/default.js');
  }

  drupal_add_css($module_path . '/css/pdf.css');

  return render($content);
}

I understand what you are talking about, but your patch just doesn't work correctly.
Because in default.js you detect isCanvasSupported before browserInfo.acrobat.

(function ($) {
  Drupal.behaviors.pdf = {
    attach: function(context, settings) {

      var iframe = $('iframe.pdf');

      if (!isCanvasSupported()) {
        // pdf.js isn't going to work in this browser--let's try acrobat.
        var browserInfo = Drupal.settings.acrobatDetection;
        
        if (browserInfo.acrobat !== null) {
          iframe.each(function(){
            setIframeSrc($(this));
            $(this).attr('src', $(this).text());
          });
        }
        else {
          // Even Acrobat isn't going to work--output a message telling user to upgrade their browser.
          $('<p/>', {
            text: 'Your browser is not capable of displaying a pdf. Please upgrade your browser to view this page as it was intended.',
            'class': 'pdf acrobat-browser-messsage',
          }).replaceAll(iframe);
        }
      }
      else {
        // We have canvas.
        iframe.each(function(){
          setIframeSrc($(this));//If we allow PDF plugin and the browser has it, we shouldn't use pdf.js here.
        });
      }
    }
  };
})(jQuery);

The correct flow should be:
force_pdfjs(Y)>isCanvasSupported(Y)>use pdf.js
//I think this part should be handled by pdf.js itself rather then this module.
force_pdfjs(Y)>isCanvasSupported(N)>browserInfo.acrobat(Y)>use plugin
force_pdfjs(Y)>isCanvasSupported(N)>browserInfo.acrobat(N)>show 'Your browser is not capable of displaying a pdf. Please upgrade your browser to view this page as it was intended.'
//

force_pdfjs(N)>browserInfo.acrobat(Y)>don't use pdf.js instead of plugin
force_pdfjs(N)>browserInfo.acrobat(N)>isCanvasSupported(Y)>use pdf.js
force_pdfjs(N)>browserInfo.acrobat(N)>isCanvasSupported(N)>show 'Your browser is not capable of displaying a pdf. Please upgrade your browser to view this page as it was intended.'

I guess this means you see pdf.js as a fallback for browser plugins which doesn't make sense to me.

I see it the other way—I want to give my site visitors the best experience with a known set of features which is why I want to use pdf.js. If I wanted to use browser plugins I wouldn't need this module at all I would just need to use an iframe—modern browsers would use their built in plugins and basically every IE user has acrobat installed. This means only people with IE9+ that don't have acrobat installed will use pdf.js. I can't see this being more than 1-2% of users.

I could be wrong but I assume developers are using this module because they want to use pdf.js to display pdfs on their site. Therefore it doesn't make sense for the default behaviour to revert to browser plugins.

I see this as very similar to html5 video players like Flowplayer or Sublime. A developer chooses the video player they like based on their set of features and then implements it on their site. The video player is just some javascript that attempts to play video natively with html and javascript. If the browser doesn't support this then the js checks for Flash plugin and tries to play the video that way. Failing that, they output a message to the user telling them that their browser can't play the video. This is a tried and tested workflow that developers agree is the best way to reach the most amount of people with the content and this is the same methodology I used in this patch.

Im well aware of the current functionality but thanks for the screenshot to remind me.

I'm proposing a way for the module to degrade gracefully after attempting to give users consistent experience. You still haven't outlined why you think this is a bad idea and how your current method is better for users and developers.

Here's how it stands with your current solution:

The checkbox is on:
• Safari, Chrome, FF, iE9+ get pdf.js
• IE8, IE7, IE6 and a whole host of older mobile browsers get NOTHING

The checkbox is off:
• Most desktop browsers will use a plugin which provides a different experience/set of features per computer.
• A very small percentage of desktop users that don't have a plugin will get pdf.js
• Lots of older mobile browsers get NOTHING

And here is my proposed solution:
• No checkbox/options necessary (although I left the checkbox in for backwards compatibility)
• All modern browsers on all platforms will use pdf.js
• Any older browser with a plugin will use the plugin
• Only older browsers without a plugin will get a message informing them that their browser is not capable of showing the pdf.

Can you please explain to me and everyone else listening why you think your solution is better for users and developers than the one I am proposing?

If this works as designed then I guess it's just badly designed.

I try the patch of 13, it does not work on IE 8. could you update you patch to latest version.

Sorry g089h515r806,

The module developer has made it abundantly clear that he's not interested in my input on the way this works so I'm not able to spend any more time on it.

Some people need it, IE8 is still very important.

If to support old browsers is important for you, uncheck "always use pdf.js" or just use https://www.drupal.org/project/fileviewer which even works on IE6.

For sonictruth preferred "pdf.js first and plugins as backup" order, please check compatibility.js file in pdf.js. You can add a handler there for using plugins and keep "always use pdf.js". Within the pdf.js context, you can keep the UI more or less consistent. You can also ask https://github.com/mozilla/pdf.js to merge your work.

I'm with Sonic on this one. PDF.js provides the best UX and should be used on any browser that supports HTML5, regardless of whether or not a plug-in is installed. AND, the module should provide graceful fallback for browsers that don't support HTML5, using the plug-in if available or displaying a link to download the PDF if not. Perhaps you could come up with a set of configuration options that allows your preferred (and incorrect, IMHO) behavior and the suggested behavior to co-exist.

+1 for a more graceful decline... I'm kinda bummed because yeah = pdf.js is the best UI, but it crashes firefox for a lot of my users.... any other options on this?

I tried the patch from #13 however it doesn't look like that's running anymore at all... I could really use this feature, as it kinda makes the PDF module unusable ... i'm going to test fileviewer to see if that works any better

ok, yeah, and fileviewer is not really a viable option, although not a bad tool, just nowhere near as complete as pdf.js.... I really wish this module functioned with better degradation, but for now have turned it off as it crashed too much,

@alibama You can try to open a pdf file in Firefox and find out the built-in pdf.js version. My Firefox 43.0.4 has PDFJS.version = '1.1.469';
Using that version shouldn't crash the latest Firefox.

Hi Shenzhuxi - thanks for getting back to us.

I have 1,000+ users in 100+ cities. I can not tell each one of them to upgrade their browsers. It's not a good solution. the browser it failed in was Firefox 43.0.1 in windows 7 as well as Galaxy S5 Android v.5.0 Lollipop.

Not all of this has to do with the module - pdf.js needs some work on Android and they know that. I'm talking to the pdf.js people to see if they can develop a workaround to get this module working.

It's a good module in concept, but it doesn't work well enough for production... the module should degrade gracefully, we shouldn't have to tell people which browser to use.

fwiw there are almost 30 people on #irc.mozilla.org in the pdfjs channel, and Yury has been looking at your code and wants to help - might be a chance to swing this around.