high dpi versions for PNG?

[ewjoachim]

📋 Description

Hey :) I'm the maintainer of https://github.com/py-cov-action/python-coverage-comment-action which provide comments that look like this (using shields)

But when users receive an email notification for those comments, on gmail, they look like this:

This is because GMail doesn't support SVG.

So I've tried using pngs, and the problem is that with a high dpi display (retina, ...), they look like this:

So I'm wondering if there could be a way to get bigger PNG images (e.g. 2x bigger) for which I could then use with height=20 and get a pixel-perfect badge as png that would look awesome on Gmail notification too ?

[ewjoachim]

Just for curiosity, I was wondering

1/ where the size of 20px comes from for SVG badges: here
2/ and for png: here

[ewjoachim]

@chris48s I could imagine having a go at this PR, but I'd need first that we agree on the specs:

• Either we need to have the original image declare larger dimension on the shields server (e.g. if the image name ends with @2x or with &scale_factor=2 (or dpr, or pixel_ratio)
• Or we need to add that param to the squint server, in which case, we'll both need to extract it and to not send it back to the shields server, or to ensure it's ignored by the shields server.

It would make sense that the squint proxy stays as a dumb proxy as much as possible, so that would point to solution 1, with @2x (or 3 or 4, I don't think it's worth supporting other values than 2, 3 and 4, at least to avoid people requesting very large values and DDoSing the squint server). That said I could understand if you were to judge that it's a rasterization issue and not an attribute of the badge.

Having it on the shields side would probably make the doc easier to write so as for this feature to be used by people ? I'm noting that it's very hard to get info about the squint server in the current doc. The only mention I find is in the old doc, so maybe there's something to do about that anyway.

Lastly, we could also use a HTTP header, either a custom one or a standard one. In terms of standard, the only thing that seems to exist is Sec-CH-DPR which is implemented by some browsers, so it could make sense too. While this might seem like the ideal solution, I'm somewhat slightly afraid that using that would mean anyone using the PNG images today would start receiving images twice as big, but the specs seem to indicate that we could use EXIF metadata on the returned image to express that it's a 2x image.

I'll be waiting for a indication on your part before starting the work.

[ewjoachim]

In case it helps: here's a PNG image that's x2 but doesn't have the exif attibutes yet (I'm trying to set them and exiftool is reticent). If anyone manages to get an image where most browser understand they need to scale it down, then great ! (let us know)

To get it, I download a svg badge and editted it:

<svg xmlns="http://www.w3.org/2000/svg" width="216" height="40" role="img"
    aria-label="any text: you like" transform="scale(2)">

(so I changed the width and height x2 and added transform).
(then made it a PNG)

[chris48s]

Hi. Since this issue was originally posted in May I have stepped down from maintaining shields so someone else will need to take this forward with you if it is going to happen.

Since you've @mentioned me, I think my 2c is that requesting a larger image should be opt-in via a query param (not the default) and implemented on the squint side since this is a consideration only relevant to raster images.

[paulmelnikow]

I'm hopeful someone will have the bandwidth to review this.

I'm happy to chime in on the design. I do agree with Chris. If there's an elegant way to put @2x in the badge URLs in a consistent way I could see doing that, and otherwise using a query parameter that is stripped off instead of being forwarded to the Shields server.

If you're up for adding some notes to the new docs about the raster images that's a plus too!

[ewjoachim]

I have badges/shields#11148 from maintaining shields

Oh sorry for that, and thanks for your input.