Placeholder Images

[DanSnelson]

HI,

I am wondering how the placeholders work fro the images that you can change the height of.

I really like the way the placeholders change with the height so was wondering how that has been done as i cant see anything that stands out in the versafix code.

Any advice would be useful

Cheers

Dan

[bago]

<img data-ko-editable="leftImage.src" border="0" hspace="0" vspace="0" width="166" height="90" src="http://mosaico.io/srv/f-default/img?method=placeholder&amp;params=166%2C90" class="mobile-full" alt="" style="vertical-align:top; width: 100%; max-width: 166px; height: auto; -ko-attr-height: @imageHeight; 
                               -ko-attr-alt: @leftImage.alt">

You can see the "-ko-attr-height: @imageHeight" is the way versafix tells to mosaico the height of this image is "user-defined".

The image "cut/resize" is done by the backend using the "image processor backend": you can see a sample nodejs implementation in the "backend" folder.

[DanSnelson]

Yeah i knew how to make the image height editable i was wondering how you had made the image placeholder with the dimensions change dimensions with the height of the image. If it is a back end job i will have to look further i was just wondering how easy it was to implement

[DanSnelson]

Hi, After adding the image processor into our version of mosaico we realised when the template goes responsive the images stretch and become pixelated from the "cut/resizing". This happens on the Demo on the mosaico website as well.

For an example of this you cna use the triple Article Block,

Upload an image into each of the three columns and then either send a test to a mobile or use the mobile preview on mosaico.

From the crop, the images are then pixelated from being stretched for the mobile.

Any ideas on how to get round this as the images dont look brilliant on mobile which is quite a problem...

[bago]

One thing you could so is "doubling" the size of resized images: Here is the function (see app.js) being called to create the "remote image url".. just pass width_2 and height_2 to have 2x images.

  ko.bindingHandlers.wysiwygSrc.convertedUrl = function(src, method, width, height) {
    var imgProcessorBackend = options.imgProcessorBackend ? options.imgProcessorBackend : './upload';
    var backEndMatch = imgProcessorBackend.match(/^(https?:\/\/[^\/]*\/).*$/);
    var srcMatch = src.match(/^(https?:\/\/[^\/]*\/).*$/);
    if (backEndMatch === null || (srcMatch !== null && backEndMatch[1] == srcMatch[1])) {
      return imgProcessorBackend + "?src=" + encodeURIComponent(src) + "&method=" + encodeURIComponent(method) + "&params=" + encodeURIComponent(width + "," + height);
    } else {
      console.log("Cannot apply backend image resizing to non-local resources ", src, method, width, height, backEndMatch, srcMatch);
      return src + "?method=" + method + "&width=" + width + (height !== null ? "&height=" + height : '');
    }
  };

Another option is to let the template author decide the real resolution of each editable image so that only images that are being "responsivized" are included at an higher resolution.

In this case we should add some "control-attribute" to the img tags so that parser.js dealing with "[data-ko-editable]" will be able to add custom logic.

Finding the best solution is not trivial. Maybe a "data-ko-density" attribute is easier, but I'm not sure it's the right solution. Maybe a "data-ko-resize-width" or "data-ko-resize-height" is better...

I think "mosaico" should not make assumptions on the best way to deal with resolutions and responsiveness, so the template language could be improved to let the template make this choices.

Another option would be to change the backend so that it only fixes the aspect ration but keeps the original size, so that you let the final user decide the resolution (but most "dummy" user will probably include very large images that are not good for email).

Ideas?

[DanSnelson]

How would I set it up witha control attribute? If I was to go down the route of letting the template author decide the real resolution would there be any extra element needing implemented into the backend? or would it all be within the template creating new tags for the template?

[bago]

I close this. This is old and the subject is about placeholder images, while the real issue is mainly related to the size of image resizing (that is valid not only for placeholders, but mainly for real images).

We evaluated options for different image sizing and/or for retina images support but we didn't identify a good general purpose option that won't increase the weight of the email too much.