Caution: a very large project, may cause trouble to your browser.
Snap uses "image/png" as the default format for storing images in the project. The new format "webp" has a much better compression ratio and acceptable compatibility. For the users, this change should be fully transparent.
To get some estimation I created a project with ~70 large costumes
from an image hosting site. The nominal project size is ~16MB.
But I instructed Snap! to store costumes as "image/webp". The size of the project is now 2.6MB and can be stored in the cloud or exported.
There is a block
to change image format before storing a project.
I made a proof of concept (Chrome only) picAsXML
You can create a script picture with XML attached - menu "script pic & XML".
When you Shift + drop such picture, attached script is imported.
Dropping from the forum and local filesystem is possible.
Examples to drag&drop : (Updated to the current version)
JS from "menu script pic & XML" and "accept pic & XML" can be also injected into with user script managers, like Tamper Monkey.
For offline processing XML can be extracted by looking for "Snap\tBlocks\tEmbedded".
An image must be intact - not distorted by any browser optimizer/accelerator.
This is neat! It looks like the current project still uses PNG? On my Mac, the files are .png, and the XML is there.
My understanding is that data like this would need to be in a structured block in the PNG file. Do you know if it's spec compliant to just ignore data after the end of the file? I couldn't find something obvious about how consistent this behavior is.
Image file type is parametrized inside "menu script pic & XML". To separate concerns, the default is "png".
So am I.
Data beyond logical "EOF" for a given format can be verified by some kind of sanitizer.
Taking into account, that even legit metadata are already considered a privacy threat and vector to iframe incjection, I think that this kind of appending data is only slightly inferior, as compared to EXIF.
Depending on expected use data can be split right before use.
That's because the current version of that block has a dropdown and no " , with badge" Title text, whereas the older version has a boolean and the Title text " , with badge".
Brian reminded me yesterday that you need a more formal way to embed scripts into image. I updated project. Now XML is added as an iTXt chunks, fully compliant with PNG spec. Also non US-ascii characters should be handled.
Hi @dardoro ! I'm Dan Garcia's student that is working on this script-embedding project within his group. I have looked through your code and its amazing! I think that this project is great, and would love to help you anywhere that I can, so if I can, please let me know!
Hi,
Feel free to use it for whatever purpose and modify it to suit your needs.
Code is over-compressed to fit into a single screen Also, I prefer code base reuse by extending the original function with "pre-" or post-processing. If you are able to make PR to the code base those can be inlined.
You are interested mostly in embedding or UI aspects?
There are two most obvious problems:
Exporting definition of the custom blocks
Remove "shift" modifier. It's hard because drag'n'drop event data is volatile if used in asynchronous code.
There is also room for improvements like a network shared backpack and online blocks decoder.
Hi @dardoro. We are definitely trying to get this integrated and into a PR as soon as possible. We're interested in using this for the embedding aspect, to make the CS10 course more efficient with a ready-to-go code library. I will look into those two problems that you pointed out because those are also Dan's two largest concerns.
I'll be sure to get back to you if I ever run into a wall and need your guidance!
with user script managers, like Tamper Monkey.
Also, I prefer code base reuse by extending the original function with "pre-" or post-processing. If you are able to make PR to the code base those can be inlined.