Hype ImageBaseEncoder (Hype Resource / Image Extension)


(Loves Hype) #1

This little extension helps you inline images and reference them without any efforts in your Hype projects. This reduces further request to any files on the server. It works the following way:

Instruction:

  1. Use any images as always in Hype
  2. On export (only local) the extension writes your images as Base64 code to your console
  3. Copy and paste the images you want inlined from the console (Chrome has a copy button) and paste them to your Head-HTML
  4. Requests to that file will from then on be served from that inline content (in previews and exports)
  5. To update a file that has been previously inlined repeat the process

Hints:

  • Doesn’t support automatic retina switching
  • You can disable preload for inlined images (but isn’t a must)
  • Disable automatic image optimisation to keep your original file (sometimes Hype converts PNG to JPG if enabled)
  • Use for small images as Base64 isn’t the most size efficient! You can ignore this hint if your app runs local and size isn’t a matter.
  • Use ImageOptim (lossless compression) and ImageAlpha (reduction of colors in PNG) on your files before using this extension to further reduce size before inlining files!
  • If you have inlined all images and don’t want any local console output you can disable it with <script>HypeImageBaseEncoder.localConsoleOutput(false);</script> in your Head-HTML (after including the script). The console output is anyways restricted to local development.

Examples:
HypeImageBaseEncoder.hype.zip
HypeImageBaseEncoder_code_inlined.hype.zip
HypeImageBaseEncoder_code_in_ressources.hype.zip

Source:
HypeImageBaseEncoder.js
HypeImageBaseEncoder.min.js

Version:
1.0 Initial release with simple example
1.1 Added .svg support, jpeg extension and outputOnce


Data URI images
Reusing Base 64 code for the same image multiple times so that the output size does not increase
(Loves Hype) #2

↑ look at project
Updated to version 1.1
1.1 Added .svg support, jpeg extension and outputOnce

PS: Was playing around with inlining mp3 and ogg and it works from the browser but Hype Sound Buttons demand a URL (the Runtime can’t handle data: as return) so I left sound be for now


(Kalle) #3

Hei Max, I‘m working A LOT with SVG. I‘m excited to test your extension… :blush::+1:t3:


(Dan) #4

Is this ready now? I see the download links for the .JS files, but was wondering if there are install instructions, or a downloadable extension to make it work. Thanks!


(Loves Hype) #5

I added different ways to include the JS in the examples above …
Also here is a video demo how to use it using the code inlined example


Reusing Base 64 code for the same image multiple times so that the output size does not increase
(Jonathan Deutsch) #6

Cool!

I would speculate you might also be able to do this as an export script since there is support for overriding resource URLs and preloading.


(Loves Hype) #7

I would make an export script if they would be easy to install for newbies and without me having to create a installer package and sign it etc… How about a “Navigate to export-script-folder” under Help… on future Hype Versions.


#8

Wow, I was just thinking that as I was reading this. Until I watched the video, I was wondering if this was an export script.

Theoretically, doesn’t this mean Hype could export to a single file. :thinking:

It’s in the preferences… but yeah, that is a bit hidden.


(Loves Hype) #9

Ah! So all is good… that is sufficient for me to point a newbie to.

Not really as Audio in the browser accepts Base64 but the Runtime wants a filepath (as it still does some stuff, caching, audio context etc.). So Audio is a problem but for the images that should work.


(Loves Hype) #10

Was playing around with an implementation today. Still looking for a good way to collect my base encoded files in each --replace_url and write them in --modify_staging_path. Was thinking on some temp file to collect my additions for the later occuring --modify_staging_path

Is there a way to disable the file completely (like url_info['url'] = None)?

Another approach would be to wait until --modify_staging_path and the walk over the files in the outputted directory and brute force my way (reading them, writing them to index, removing files etc.) based on filetype etc.


(Jonathan Deutsch) #11

I have a script that automates this whole process I can send you.

In fact, the full version pulls from the hype-export-scripts github repo, packages the scripts, and then uploads to tumult.com, so potentially if you send a pull request (that looks good to me :wink: ) it could just be built as part of that.

Correct-ish with the audio caveat (and possible some other edge cases I can’t think of at the time).

The export script would also need to set export_options of:

"exportShouldInlineHypeJS" : true,
"exportShouldInlineDocumentLoader" : true,

And most likely:

"exportShouldIncludePIE" : false,
"exportSupportInternetExplorer6789" : false,

Additionally, my recollection about exportShouldInlineHypeJS is that it just provides a <script> link at the top, and so you’d want to replace this with the actual contents of the Hype runtime file.

Yeah, I guess the main problem is that you should be able to replace the "url" field with the base64 data at this time, but you don’t have access to the file yet since it hasn’t been written.

I think this is how I’d take a stab at approaching it:

First, at replace_url time, return the dictionary as:

{"should_preload" : false, "is_reference" : true, "url" : url}

What you’ll do is keep track of the urls. You can use the export_uid argument for example to append to a file all the urls you come across.

Then when it is --modify_staging_path time, you can read back that file, and basically do a string substitution on the .html file looking for the url and replacing it with a base64 version of the data then. Alternatively you could still use the dynamic HypeResourceLoad approach and keep the url in tact and just set the global variable as you are doing.