-
-
Notifications
You must be signed in to change notification settings - Fork 202
Description
Hello,
I am a GitHub amateur, so please pardon if I make any mistakes.
My institution uses the Universal Viewer as a part of our home-grown institutional repository. It doesn't seem like we've made changes to the Universal Viewer, as I was redirected here by our Repository Services Librarian, as they also were unable to figure out my issue.
Background:
I have recently come across the SingleFile browser extension for saving webpages (along with all of the assets needed to fully render offline) as a single HTML file, similar to the portability of a PDF file. I haven't seen too much discussion around SingleFile in the digital preservation/web archiving communities, but it is listed on a registry of tools maintained by the International Internet Preservation Consortium. SingleFile works great at capturing our webpages fully renderable offline, and the portability of it being one single HTML file is also a plus.
Base64 Issue:
The issue is that the Universal Viewer is having a hard time displaying the images captured in a SingleFile HTML file. To the best of my understanding, what SingleFile does to the images on a webpage is convert those images to the Base64 encoding scheme, allowing for the images to actually be embedded into the HTML file, like a PDF. These Base64 alphanumeric strings unfortunately do not work properly with the Universal Viewer. When I right-click on Inspect (I am using Google Chrome) and check what's going on in Console, it appears that the Universal Viewer may be adding an extra backslash "/" making the an invalid URL.
For example, an img tag may look like this:
<img fetchpriority=high decoding=async width=800 height=200 src="data:image/png;base64,iVBOR ... [omitted for brevity] VORK5CYII=" alt class=wp-image-7 style=width:1200px srcset sizes>
However, when going to Inspect > Console on Google Chrome, the same img's Base64 string looks like this:
data:image/png;base64,iVBOR ... [omitted for brevity] VORK5CYII=/
When removing the backslash "/" and entering the original Base64 string into my browser's address bar, I am able to retrieve the image file properly. So, I am not sure why these extra backslashes are getting injected.
Document's Content Policy Isssue:
On top of the strange backslash injection, I also came across another error message in Inspect > Console (Google Chrome) which I or my Repository Services Librarian do not know what to make of. I've attached an image of my Console down below:
Thank you all for reading and for any support!