I need to make some modifications for idrviewer.js and was wondering if there is a non-minified version somewhere?
The IDRViewer is provided as a closed, end solution for clients. We do provide a public API but the code is regularly updated and developed by us and so we discourage users from editing it and minify it. For clients looking to build their own custom viewers, we have a content mode and provide several of the building blocks (thumbnails, bookmarks, etc).
What modifications would you like to make?
Was just wondering since I am currently playing with jpdf2html5 to see if we are going to get a license and already had to make an edit to the minified source (which kind of sucks… since you know – its barely readable). My edit was to create a URL structure that was more inline with “progressive enhancement” (source: https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html / https://en.wikipedia.org/wiki/Progressive_enhancement) and I needed a hook to run at the top of setup().
As to other modifications – who knows – that’s the nice thing about having access to the source – I can make it happen. It would be nice if the viewer supported highlighting (end user could make highlights – like in Acrobat) and the API made saving/loading said highlights easy. Would be cool too if the hightlight/selection points could be read from the URL itself – perhaps stashed in the “#” part of the URL. If it did that, I would not have to write it!
But again, that’s what’s nice about having access to the source – easier to hack this stuff in at times. Might be nice if your licensing agreement made the source available with a requirement that customers not publish a non-minified version (i.e. non-minified only used for customizations – if any)
Ahh – I see in your blog post you guys are considering annotations too – that would be great as well – something else I would not have to hack in there. Highlights I think would be easier to add and useful to some of us.
Just had to hack on something else in the minified source…. And I am still only in the evaluation period.
Oftentimes the URL structure on the site does not match up or is not directly relative to the viewer source files – at least it is not for my use and I assume others as well. In fact, I could think of many reasons why we would need to something other than GET 10.html to load page 10. What if the site needs to verify the session is authenticated and wants all calls to go through PHP/ASP/etc. to check that first – maybe they are storing the HTML in some sort of database instead of files – the end GET URL might be /load_doc_page.php?docid=2page=10
Might be nice, if the non-minified source will not be made available, if we could define some JS function which would take the page number as the parameter and return the URL used by the viewer to load the HTML for that page.
Can you provide an example url to show how you have changed it to follow progressive enhancement principles?
I fully agree on the need to allow the pages to be stored at a different location to the viewer itself. We actually added this feature in the February release this year. It was flagged as experimental whilst our customers can test it and let us know if they encounter any issues.
It works by adding a ‘url’ property to the IDRViewer config which the IDRViewer will then use as the base location when loading pages.
You can either add to config.js, or set IDRViewer.config.url = ‘http:// your-url-here.com/location/’; before IDRViewer.setup(); is called.
You will need to ensure that the server hosting the pages is set up to allow cross origin requests from the domain hosting the index file.
e.g. Header set Access-Control-Allow-Origin “*” inside a .htaccess file if running apache.
This allows you to have the strucuture /load_doc_page.php?docid=2&page=10.html or an alternative that uses url rewriting.
The IDRViewer is actively developed and we discourage users from hacking in their own code as it is unsustainable in the long term whilst we are regularly making updates.
Annotation functionality is also possible using the pageload listener.
If there is something that cannot be done, we are keen to hear from our customers so that we can evaluate it as a future enhancement or make an alternative recommendation.
We accept that sometimes our customer’s requirements extend beyond what we are able to offer or do not fit with our own aspirations, which is why we provide the content mode and additional features to help our customers build their own viewer to their exact requirements.
It is our long term goal to open source the IDRViewer, but I do not foresee this happening in the near future.
Sure – so basically if someone loads page 11 via ?page=11 I want to load the page 11 content either inside the <div id=”idrviewer”> or some other node which is viewable by default. Then as soon as setup runs, I know that the viewer will be available shortly, I want to hide the node that had page 11 content and let the viewer load page 11. Perhaps there is a better way to hook into the viewer to do this – if so, I would love to know about it.
I don’t have any specific recommendation for how to achieve that.
If using the IDRViewer from scratch you can call IDRViewer.goToPage(11) before IDRViewer.setup() is called, which will load page 11 first.
The provided example UIs already use querystring navigation which loads page 11 first if ?page=11 is added to the url.
The difference between outright loading page 11 first and then loading the viewer versus loading the viewer into page 11 should be neglible.