Optimised Image type changes on export

Feature Requests
1

Hi @jonathan,

I and many other run into the issue of optimised images not being found when the original image url is hard coded.

Please see this latest example.

Is it possible to have a new API place holder like this ${original extension,optimisedExtension}

So this :

url(${resourcesFolderName}/image1.png)

would become this:

url(${resourcesFolderName}/image1.${png,optimisedExtension})

or maybe. ${optimisedImage,image.xxx}

This :

url(${resourcesFolderName}/image1.png)

would become this:

url(${resourcesFolderName}/${optimisedImage,image1.png})

The extension would be rewritten at time of export to what is needed to match the actual exported image types/names.

I included the original extension part because I am sure we will need to know how to find the original file during the export and for display in the Hype editor.

1 Like
2

Thanks for the request! Ideally the syntax could just have the resource name and it would do the proper substitution.

The extension is one part of the problem, the other is that Hype writes out a _2x variant as well that often should be used instead. The ${resourcesFolderName} macro pretty much has to be written out at export time but deciding to use the 1x or 2x version of the resource is at run time, so there’s a conflict here.

I don’t know what the best solution is yet, but it might be that if we find a reference to files using ${resourcesFolderName} to just disable optimization in this case all together.

2 Likes
3

Doh.

I can see how that is a conundrum.
I was thinking you could write out a place holder that the run time fills in.

But then in the end this is over thinking things.

The fact is we are explcitly defining a file to use. So I think this should be honored.

Then it is all about documentation explaining that if a image is checked to be optemised in the UI, it will not be if it is also referenced else where using the API.

This does seem the lesser of two evils..

1 Like