Status update, August 2020

Rust image crate contributions

During the last weeks, I was able to propose several pull-requests to the image Rust library (Github repository).

I am currently working on a Plymouth theme previewer. One of the features that I want to implement is to generate a thumbnail for each and every theme. This way, the future users can get an idea about what the theme will look like. Then can then decide to trigger a real preview that will use plymouthd by the click of a button.

Generating previews is not an easy task, but for some modules it can be done quite easily.

First, the two-step module. Don’t ask me why it is not named two-steps. It is probably a typo that will never be fixed because of backward compatibility. This module is able to tile a background image all over the screen. I managed to implement a tiling function that has been accepted upstream. I now call this function to tile the background image over the thumbnail size.

This first contribution has been very valuable to me. The maintainer introduced me to the step_by function of the Iterator trait. It can replace the following “manual” approach:

for i in 0..(bottom.width() / top.width() + 1) {
    for j in 0..(bottom.height() / top.height() + 1) {
        let x = i * top.width();
        let y = j * top.height();
        overlay(bottom, top, x, y);
    }
}

By the simpler:

for x in (0..bottom.width()).step_by(top.width()) {
    for y in (0..bottom.height()).step_by(top.height()) {
        overlay(bottom, top, x, y);
    }
}

This last implementation is also more correct. It will not tile an extra tile if the bottom image is exactly a multiple of the top image’s size.

While creating this pull-request, I noticed that the compilation of this image crate was not warning-free. After this very first contribution, I created a warning-fix request in order to fix this issue.

Finally, the glow module and some others are using an horizontal gradient as a background instead of tiling a background image. This means that we need to be able to create gradients to be able to render the preview thumbnails. I managed to introduce gradient functions

This last pull-request is still open as of today. I had to introduce a new trait to handle linear interpolation between two colors (lerp). It is necessary for blending the start and end colors in order to create gradients.

HI-DPI thumbnails

This blog is going to be filled with photographies, as I do like to take shots. I recently noticed that the pictures from the articles were appearing very blurry on my recent Android tablet. This is because the pixel density of the screen is very high. The site was serving “normal” pixel density images to every device.

The solution to this problem is well-known: we have to use the srcset attribute (MDN) in order to provide different pixel density images. The devices will choose which one to use depending on their screen characteristics.

In order to automatically generate the srcset attributes, I have started to use the pelican-image-process Pelican plugin (Github, PyPI). I contributed back by creating a small pull request to fix a typo in the very complete README file of the project. Got no answer yet. The project seems to be abandoned (or finished?). No answer was received on this PR, nor on other more important ones.

This plugin is working quite well. I am facing some issues that I did not took the time to fix yet.

First, the RSS feeds will be served with the full resolution picture. It will be very slow to load in the RSS client. I tried to add srcset attributes in the ATOM feed with success. Then I realized that this attribute was not supported in the feed specification. So not supported by feed readers. One solution would be to serve the 1x or 2x resolution instead of the full resolution inside of the feed. Best solution would be to add support for srcset to the feed specifications. But I am afraid that I am not influent nor motivated enough to try to push this.

Another issue is that I have not managed yet to find a scheme for storing images in folders that relate to the articles I am writing. I am currently using a manual slug-based scheme, but it is not correlated to the article slug. Using the article slug as a directory name for the related media would be appropriate. This is not really related to the plugin, but maybe it can be adapted to get the article slug and concat the image name to it, instead of me (or a script) having to prefix the image names with a very long slug.

Well, lots more to do, and so little time as I did not yet found an occasion to reserve some days off work in order to spend time on personal projects. Probably in the next months!