Tag Archives: html

Powershell srcset image generator

If you have a website and SEO matters for you, then you probably had to optimize images. To this aim, you may want to have responsive images. As explained here,

a responsive image is an image which is displayed in its best form on a web page, depending on the device your website is being viewed from.

One of the modern way to serve quickly responsive images is to benefit from the srcset html attribute. Shortly, depending on parameters and your viewport (i.e. browser window) the srcset attribute will tell the browser to download the best appropriate image for the current display.

For example, if you put the following HTML element

<img src="images/fcnantes-champions-95.jpg"
srcset="images/fcnantes-champions-95.jpg 200w, images/fcnantes-champions-95-400.jpg 400w,
images/fcnantes-champions-95-600.jpg 600w,
images/fcnantes-champions-95-800.jpg 800w">

Your server logic can serve up to four different images representing the same pictures.

You may guess that creating all this different resized pictures can be painful manually. In this blog post we propose the following Powershell script to help you for the automation of this task.

Param ( [Parameter(Mandatory=$True)] [ValidateNotNull()] $imageSource, [Parameter(Mandatory=$true)][ValidateNotNull()] $quality )

if (!(Test-Path $imageSource)){throw( "Cannot find the source image")}
if ($quality -lt 0 -or $quality -gt 100){throw( "quality must be between 0 and 100.")}

$resolvedPath = Join-Path $PWD -ChildPath $imageSource
$bmp = [System.Drawing.Image]::FromFile($resolvedPath)

#hardcoded canvas size...
$canvasWidths = @(200, 400, 600, 800)

foreach($canvasWidth in $canvasWidths){
    #Encoder parameter for image quality
    $myEncoder = [System.Drawing.Imaging.Encoder]::Quality
    $encoderParams = New-Object System.Drawing.Imaging.EncoderParameters(1)
    $encoderParams.Param[0] = New-Object System.Drawing.Imaging.EncoderParameter($myEncoder, $quality)
    # get codec
    $myImageCodecInfo = [System.Drawing.Imaging.ImageCodecInfo]::GetImageEncoders()|where {$_.MimeType -eq 'image/jpeg'}

    #compute the final ratio to use
    $ratioX = $canvasWidth / $bmp.Width;
    $ratioY = $canvasWidth / $bmp.Height;
    $ratio = $ratioY
    if($ratioX -le $ratioY){
        $ratio = $ratioX

    #create resized bitmap
    $newWidth = [int] ($bmp.Width*$ratio)
    $newHeight = [int] ($bmp.Height*$ratio)
    $bmpResized = New-Object System.Drawing.Bitmap($newWidth, $newHeight)
    $graph = [System.Drawing.Graphics]::FromImage($bmpResized)

    $graph.DrawImage($bmp,0,0 , $newWidth, $newHeight)

    $targetFileName = [System.IO.Path]::GetFileNameWithoutExtension($imageSource) + "-" + $canvasWidth + ".jpg"
    $dir = [System.IO.Path]::GetDirectoryName($resolvedPath)
    $targetFilePath = Join-Path $dir -ChildPath $targetFileName
    Write-Host "Saving file" $targetFilePath
    #save to file
    $bmpResized.Save($targetFilePath,$myImageCodecInfo, $($encoderParams))

Now you can simply invoke the script like this: .\SrcsetBuilder.ps1 "..\images\MyImage.jpg" 85. Then all generated images: MyImage-200.jpg, MyImage-400.jpg, MyImage-600.jpg, MyImage-800.jpg are located next to MyImage.jpg.
You can modify the generated images widths by changing the values in the array $canvasWidths (line 11).

Organize a multilanguage Jekyll site

In this post I will describe a simple organization of Jekyll sources to get a mulitlanguage website.

EDIT: In the post below I suggest to use a ‘translated’ tree structure under the /fr directory. e.g. /about/about.html becomes fr/apropos/apropos.html. This leads to complication and nobody cares if the url is translated. I suggest you to keep the exact same tree structure in base site, _layout and fr directories.

What is Jekyll actually? Jekyll describes itself as a “a blog-aware static site generator”. If you know the product you’ll find this description totally fitted but still obscure if you are a newcomer. Let me introduce Jekyll in my own terms. Jekyll helps you to build .html pages, they are created when you publish (or update your site). Contrary to traditional dynamic webservers (e.g. ASP.NET, PHP etc.), the pages are not served and created “on demand” when the user visits the website. With Jekyll it’s more simple, they are only web pages stored on the server disk as if you have created them “by hand”. The magic lies in the fact that you do not have to duplicate all the html everywhere. Jekyll is a “generator” which means by using its basic features, includes, layouts etc. you will not have to repeat yourself so your site will be easily maintainable. What does “blog aware” mean? Jekyll can create pages but it has also been created for blogging on the first place. On its core you will find many things related to blog matters such as pagination, ordering, tagging etc. To conclude the presentation of Jekyll let us mention the fact that it is supported natively by github-pages.

The multi language organization described in this post will illustrate some of the features of Jekyll. If you create a website with Jekyll, you must have a clean website structure such as the following one. You will notice the usual directories _layout and _site.

├── _config.yml
├── _layouts
|    ├── default.html
|    └── post.html
├── _site
|    └── ...
└── index.html

_layout is extremely powerful, it is a form of inheritance. When you declare a page such as index.html and if you reference in the YAML (a kind of file header recognized by Jekyll) the default layout then your page will use all the html defined in the _layout default. We will use extensively the layout pattern for our localized website structure. The main idea is simple: the content of the pages are stored in a layout file located under the _layout directory, the rest of the site will only “call” layouts with the proper language to use.

Let us take a simple example to illustrate this. Suppose that your have a website which default language is english and another one: french. Naturally, the default language is located at the root of the website while other languages are located on a subfolders (e.g. www.myexample.com/fr). Suppose now that you have another subdirectory “about” (“à propos” in french) then your hosted website will have the following structure:

├── fr
|    ├── à propos
|    |    └── apropos.html
|    └── bonjour.html
├── about
|    └──about.html
└── hello.html

The question now is: how to achieve this easily with Jekyll such that the translation of the sentences are kept side by side on the same file? This latter requirement is important to work with your translators. The trick is to replicate the website structure in _layouts. We use the YAML formatter to define a key/value variable that will hold the translation. The “true” pages will only call the layout with the right language to use.

Then, for the example mentioned above, the Jekyll sources structure looks like:

├── _site
|    └── ...
├── _layouts
|    ├── about
|    |    └──about_lyt.html
|    └── hello_lyt.html
├── fr
|    ├── à propos
|    |    └── apropos.html
|    └── bonjour.html
├── about
|    └──about.html
└── hello.html

The about_lyt.html contains the html content of the page and the translation such as this one. This new layout uses the default layout containing the common content of all website pages.

layout: default
en: "This is my first sentence"
fr: "C'est ma première phrase"
en: "My second sentence"
fr: "Ma deuxième phrase"
en: "Last sentence"
fr: "Dernière phrase"

Then the two localized files simply contain a very basic YAML header.
Let us have a look at the file about.html

layout: about/about_lyt
title: "about"
lang: en

And now let us examine its french alter ego apropos.html

layout: about/about_lyt
title: "A propos"
lang: fr

This, organization is very simple and maintainable, this is the one that I have chosen for my own company’s website www.keluro.com. It is also very easy to send the YAML to the translators and put them back in your files to update your website. If you are interested in a script to extract YAML you may use this one written in powershell.