Upgrading PDF.js

[Demian Katz]

Hello,

 

We’re investigating some problems with PDF.js (both cosmetic issues involving the toolbar collapsing badly in small embed situations, and problems with certain PDFs rendering incorrectly). The first thing I’d like to try is simply upgrading to the latest version. However, I wasn’t sure if we had a standard way of achieving this. The files created by building PDF.js don’t seem to exactly match up with those included with UV (for example, UV has .min versions that don’t seem to be built by default, and the build includes public resources that I’m not finding in an obvious place in UV).

 

What’s the best procedure for upgrading PDF.js? Is this something that could be automated with Bower? (I’m not that familiar with Bower, so apologies if this is out of scope). Any advice?

 

thanks,

Demian

[Edward Silverton]

These are the google closure compiler commands for minifying the files:

https://github.com/UniversalViewer/universalviewer/blob/master/src/extensions/uv-pdf-extension/lib/README.md

I can't remember how the pdf_combined.js file is getting created. It must have been on that github url in the readme that's now a 404.

Probably like this: http://stackoverflow.com/questions/3198915/any-ideas-on-how-to-use-google-closure-compiler-to-combine-multiple-javascript-f

Bower may be a better option for simplicity's sake:

https://github.com/mozilla/pdfjs-dist

It's been a while since I've tangled with this... uv-pdfcenterpanel-module has some of the necessary assets, including the l10n files and viewer.html which is the actual viewer app that uses pdf.js (if that makes sense).

--
You received this message because you are subscribed to the Google Groups "Universal Viewer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to universalview...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Demian Katz]

Thanks! I’ll play around a little bit and see if I can figure out a way to automate this. If nothing else, it will be a good excuse to learn more about Bower, Grunt, etc.

 

- Demian

[Demian Katz]

I’m making some progress on loading PDF.js using Bower. You can see my work so far here:

 

https://github.com/UniversalViewer/universalviewer/compare/master...FalveyLibraryTechnology:pdfjs-upgrade?expand=1

 

I haven’t opened a pull request yet as I’m still trying to reconcile our viewer.js with PDF.js’s pdf_viewer.js and sort out the CSS side of things. Hopefully I’ll get that done tomorrow when I have a bit more time… but in the meantime, if you see anything glaringly wrong with my approach so far, please let me know!

 

- Demian

 

From: Edward Silverton [mailto:e.sil...@gmail.com]
Sent: Tuesday, July 21, 2015 1:18 PM
To: Demian Katz
Cc: univers...@googlegroups.com
Subject: Re: Upgrading PDF.js

 

These are the google closure compiler commands for minifying the files:

[Edward Silverton]

https://github.com/UniversalViewer/universalviewer/compare/master...FalveyLibraryTechnology:pdfjs-upgrade?expand=1#diff-35b4a816e0441e6a375cd925af50752cR97

Instead of copy:build I'd use sync:bowerComponents to copy the files. This is run after every bower install/update.

https://github.com/UniversalViewer/universalviewer/compare/master...FalveyLibraryTechnology:pdfjs-upgrade?expand=1#diff-35b4a816e0441e6a375cd925af50752cR484

I've tried to avoid any extension-specific tasks, although a generic alternative for this doesn't immediately spring to mind...

https://github.com/UniversalViewer/universalviewer/compare/master...FalveyLibraryTechnology:pdfjs-upgrade?expand=1#diff-896f672f4e2fb6d921efb728f06e6f10R49

Will this work for dev builds as well as release builds? We want to be able to run the UV with sourcemaps for debugging etc.

I intend to do away with the window.DEBUG variable if/when preprocessor directives are available in TypeScript: https://github.com/Microsoft/TypeScript/issues/3670

[Edward Silverton]

Just thinking about extension-specific tasks.

Perhaps each extension could have a tasks directory that contains something like install.js and build.js files similar in design to these:

https://github.com/UniversalViewer/universalviewer/tree/master/tasks

install.js could combine a bunch of bower files into a single file and copy to src/lib, build.js could minify this file for production. Any arbitrary extension-specific stuff could happen in these files. The UV'a grunt file just knows to look for files named [extension]/tasks/install.js and [extension]/tasks/build.js and to execute them during the bower post-install and build phases.

I'd like to port the UV to gulp at some point. Here's a project where I'm using require-dir to load the tasks in a given directory:

https://github.com/edsilv/utils/blob/master/gulpfile.js#L12

There may be a way to dynamically load these extension tasks so we don't have to hard-code the extension names into the grunt file. The UV should be able to discover them. 

[Demian Katz]

I’ve spent some more time on this, though I’m a bit frustrated with the pdfjs-dist repository, as it does not include the full viewer example that forms the basis of the PDF extension. Thus, I can only get so far with Bower alone.

 

Thanks for the tip about sync:bowerComponents – I was trying to use that yesterday but didn’t realize it was triggered by bower; I was just scratching my head over why it wasn’t being triggered by grunt build. Now that I understand, I’ve moved the copy command back.

 

Regarding the extension-specific commands, I’ll give that some more thought once I’ve actually got everything working to my satisfaction.

 

Regarding dev builds vs. release builds, how do I test each type? I always do “grunt build ; grunt serve” – is there a different way to get the dev version? In any case, I made the change to PDFCenterPanel.ts to eliminate the conditional clause around the location of pdf.worker.min.js because that file will now always be in the lib directory due to loading from Bower. The previous code loaded the minified version regardless of mode, it just loaded it from different directories. If the goal of development mode is to load a non-minified version, then we need a different conditional there.

 

My biggest step forward today is to update the viewer.js file to a newer version. However, because of the limitations of pdfjs-dist mentioned earlier, I had to checkout the main pdf.js repo and build it in order to get the latest file. This revealed to me that the previous viewer.js had been slightly customized inside UV. I’ve made some changes here to eliminate those customizations so we can upgrade in future with drop-in replacement:

 

https://github.com/FalveyLibraryTechnology/universalviewer/commit/33fcfeaa1032582f4dd6436b0e6acb8dab991f51

Using the DEFAULT_URL global isn’t pretty, but I think it’s more maintainable long term. If we want a better approach, maybe we can open a pdf.js pull request to add a better mechanism for overriding this value.

 

My next step is to update the viewer.html and related CSS/image files. This is going to be trickier, I suspect, because the pdf.js viewer.html has a complete <body> tag, and the UV version needs to strip off that stuff. It would be nice to have a way to automatically update this, but there may not be an adequate solution.

 

I also thought about the possibility of trying to load the regular pdf.js repo through Bower, then compile it and move the pieces into position… but I couldn’t get that to work, so maybe this just needs to remain a manual process for now. If you agree, we should at least write up some documentation on the steps – I’m happy to do that, either as a README.md in the PDF extension or as a wiki page. Let me know your thoughts!

 

thanks,

[Edward Silverton]

To view the dev build you just need to run 'grunt', then 'grunt serve'.

https://github.com/UniversalViewer/universalviewer/blob/master/Gruntfile.js#L426

This will compile the typescript with sourcemaps to aid in debugging. Sometimes a 'grunt build' is necessary if you have updated the config.json files and want to see their content in the config editor, or if you're deploying to the demo site - otherwise I always use a dev build.

Perhaps a jquery.load with selector will be able to extract the content you need from viewer.html?

http://api.jquery.com/load/

PDFCenterPanel is already using this mechanism, but without a selector:

https://github.com/UniversalViewer/universalviewer/blob/master/src/modules/uv-pdfcenterpanel-module/PDFCenterPanel.ts#L48

Yep, I tend to just put a guide in a readme in the project itself for technical steps such as these. I think the best way to get pdf.js automation will ultimately be extension-specific tasks. This will also open up a raft of possibilities for other extensions.