No, that is the symbol compressor. Recent updates on GitHub are for programmers and only relevant for zipping. Please read the first post in this thread and the README. As the zero fat zip loader requires a Request, so it can’t be used with file:// (CORS). I might do an export script for it (allowing direct exports and previews)... also the ZIP-Edition drag‘n’drop online version I have on my server doesn’t support it yet but everyone has a zip application on their computer anyway. Implementing full-zip loading can be done with code and is documented on GitHub.
Okay I’m gonna try
@cartmuni let me link this example of a file he sent me to play around with. I put on my server: https://playground.maxziebell.de/Hype/Compressor/ziptest/
The ad folder only contains an index.html and runs directly from the zip-file:
He won't be using this as it requires some manual/technical steps, but I thought it was a fun demo to show that you can run entirely from a ZIP-file.
PS: This example uses HypeCompressor.min.js in an embedded way at only 5.2kb. (8kb with HTML).
Could also be linked from Content Delivery Network
Hi Max, I tried the compressor way on a document with two symbols. Google Lighthouse reported a better performace from 86 of the normal document to 99 of the compressed one. You can find it here:
Cannabis FR uncompressed
Cannabis FR Compressed
Let me know if You like to see the complete report. Duplicated symbols would probably more profit from this technique but I was surprised anyway. Good work!
2 Likes
Hello Olof,
that is great. Thanks for the feedback. Looking at the source I saw that there seems to be a slight oversight in the string compression (not symbol compression). As seen in the following screenshot. This is not a big issue but once I fix the lookup routine, it should only contain the repeating SVG string once. My guess is the lookup key comparison fails because of the escaped character. So, I need to make sure both ends of the lookup comparison are escaped or unescaped the same way.<s/trike>
The small glitch in the string lookup is now fixed. I made a classic error when determining the lookup index, and if it turned up as the first index (being a 0 in an array context) I only checked against a simple false statement !$fid (being my found id) and a 0 index would also be considered a false and return a not found from the lookup. That resulted in the optimization creating repeated entries for strings at index 0. Now, I am checking against $fid===false. But either way no harm done as the strings have been anyway repeated as is and that was what we wanted to fix in the first place. Hence, older symbol optimizations run just fine … newer ones will get a minimal better compression from now on.
1 Like
Interesting topics you´re working on... 
2 Likes
Maybe someone is wondering about the cannabis project and the untidy resource folder. We used Hype for a couple of social media posts of different topics as videos and did't use it as a HTML. Hypes Video export helped a lot to produce these videos in a very straight forward way. Max Ziebells Hype Data Magic on top makes the adaption process in six other languages a finger snap.
5 Likes
Much appreciated feedback!
2 Likes