Hype ImageBaseEncoder (Hype Resource / Image Extension)

Extension Project
1

HypeImageBaseEncoder
HypeImageBaseEncoder1280×905 230 KB

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. Turn those beautiful images into ugly little code frogs. 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 in-lined 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 optimization 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!
    A reminder to everybody: These mentioned compression tools are Open-Source and maintained by the great Image compression tinkerer ⇨ https://twitter.com/kornelski! If these tools have made your life easier and or helped you finish a job and meet its restriction … in present day or in the past: Show the author and maintainer some love and support him with a sponsorship or a one-time payment
  • 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 anyway restricted to local development.

Examples:
HypeImageBaseEncoder.hype.zip

Code repository on GitHub

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

Content Delivery Network (CDN)

Latest version can be linked into your project using the following in the head section of your project:

<script src="https://cdn.jsdelivr.net/gh/worldoptimizer/HypeImageBaseEncoder/HypeImageBaseEncoder.min.js"></script>

Optionally, you can also link a SRI version or specific releases.
Read more about that on the JsDelivr (CDN) page for this extension at worldoptimizer/HypeImageBaseEncoder CDN by jsDelivr - A CDN for npm and GitHub

Learn how to use the latest extension version and how to combine extensions into one file at

4 Likes
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

2 Likes
3

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

1 Like
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!

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

2 Likes
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.

1 Like
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.

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.

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.

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.

1 Like