DEV Community: Anthony Fung

Absolute vs. Relative Co-ordinates for Defining an SVG Path

Anthony Fung — Wed, 27 Mar 2024 13:00:00 +0000

We previously looked at taking an icon drawn on paper and converting it to SVG code. The process first involves identifying co-ordinates for key points within a design. We use these alongside a set of commands to form the data for a path element to render our icon.

The icon we transcribed used three commands: M, L, and Z. These respectively represent Moving to a location, drawing a straight Line to a point, and closing an open path. Like much in programming, casing is important. Many path commands also have a lower-case counterpart.

In this article, we’ll look at how they differ.

Moving To or Passing By?

An Example

The following SVG renders to look like the square shown in Image 1. As we’re focussing on the d attribute of the path element, I’ve left out both styling attributes, and the html for a Web page to host the SVG.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 7 7">
    <path d="m1,1 l5,0 l0,5 l-5,0 z"></path>
</svg>

Image 1: An SVG containing a Path element defined with relative commands

Now, let’s use the same markup but with one modification. Instead of lower-case commands in the value of the d attribute, we’ll use their upper-case equivalents. The result is shown in Image 2.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 7 7">
    <path d="M1,1 L5,0 L0,5 L-5,0 Z"></path>
</svg>

Image 2: The results of rendering the SVG in Image 1 using upper case commands in the path element

What’s Going On?

In general, lower-case commands work with relative co-ordinates. In contrast, upper-case versions interpret them to be absolute. Z (and z) is an exception; these behave in the same way as they don’t rely on co-ordinates.

In the markup for Image 1, we declared instructions to:

m1,1: move across and down by 1 unit from the origin without drawing.
l5,0: draw a line for 5 units rightwards.
l0,5: draw a line for 5 units downwards.
l-5,0: draw a line for 5 units leftwards.
z: close the loop, resulting in drawing a line upwards.

As we can see in Image 1, this forms a square.

In the markup for Image 2, we:

M1,1: moved directly to point (1,1).
L5,0: draw a line rightwards and upwards to point (5,0).
L0,5: draw a line downwards and leftwards to point (0,5).
L-5,0: draw a line leftwards and upwards to point (-5,0).
Z: close the loop, resulting in a line being drawn rightwards and downwards back towards point (1,1).

In Image 2, we only see part of the shape we’ve drawn. The image’s viewBox attribute has a top-left co-ordinate of (0,0); parts of the image with negative co-ordinates are outside of our specified viewport.

Absolute vs Relative Co-ordinates

Ultimately, it’s possible to achieve the same results whether we use absolute, relative, or mixed co-ordinates. The important thing is to be mindful of which is being used when plotting the next point in an image.

When thinking about an object’s outline, it may be easier to use relative co-ordinates. That way, we only need concern ourselves with how far we move in each direction. As we don’t need to specify exact co-ordinates, we’re left to focus only on the shape being drawn.

But when transferring diagrams from graph (or dotted) paper, it may be preferable to use absolute co-ordinates. The positions of key points will be marked on the page, removing the need to mentally track their whereabouts. And by specifying exactly where each data point is, any ambiguity about their locations – which might be important when using the viewBox attribute – is eliminated.

Summary

The syntax for declaring an SVG path is case sensitive. In general, upper-case commands treat co-ordinates as being absolute and lower-case versions relative.

When mentally following an object’s outline, you may find it easier to think in terms of relative co-ordinates when moving from point to point. But when transferring an image from a design on paper, there’s less ambiguity with absolute co-ordinates.

You can use relative or absolute co-ordinates when defining data for a path; it’s even possible to use a mix of the two. The important thing is to use the system that’s most convenient for you.

Thanks for reading!

This article is from my newsletter. If you found it useful, please consider subscribing. You’ll get more articles like this delivered straight to your inbox (once per week), plus bonus developer tips too!

Change Colours in a Bitmap Image using Browser CSS Filters

Anthony Fung — Wed, 20 Mar 2024 13:00:00 +0000

Last week we looked at how we can create greyscale versions of images in real time. Maybe we want to give our images a different flavour. Or maybe we might want to create engaging mouseover effects. In either case, we can use CSS to achieve our goal instead of having to potentially create and manage multiple versions of images.

Theming is another area we’ve looked at recently where we might need different versions of the same image – we might have multiple themes and want our icons to be a different colour in each. Well, it turns out we can use CSS to achieve this too. There are some caveats however, but to avoid this week’s newsletter from becoming too long, we’ll save those for another.

A (Very) High Level Exploration of Colour Theory

We can express colour in many ways. One common format in CSS is a hexadecimal code, e.g. #6495ed. Here, we use the first two characters (64) to specify the amount of red in the colour, the next two (95) for green, and the final two (ed) blue. In other words, we describe a colour by its intensities of pure red, green, and blue.

But we can model colour in other ways too. In some models, we reference the hue (base colour tone, e.g. orange, blue, etc.) directly. Image 1 shows the colour wheel from GIMP and gives us an idea of how this works. Looking at the outer ring, we can see we can specify any colour we need by referencing its degree of rotation; red is at 0, green at 120, and blue at 240. (Black, white, and the greys between are a special case and can be achieved via other parameters).

Image 1: The wheel from the colour picker in GIMP

Hue Shifting

If we want an image in our app to have a different colour, one option is to use the CSS hue-rotate filter. By specifying a degree of rotation, we can work with these colour models, offsetting every colour in the image by the indicated amount.

As an example, Image 2 shows a blue arrow. Let’s say we wanted a red version of it. Looking at Image 1, we can see blue is at around the 7 o’clock position on the outer ring. We want it to be red, which is at the 3 o’clock position – one third of the way (120 degrees) anticlockwise around the ring. Based on this, we can apply a 120 degree hue rotation to it:

filter: hue-rotate(120deg)

The result of this is shown in Image 3.

Image 2: An image of a blue arrow

Image 3: The blue arrow shown in Image 1 with a hue rotation of 120 degrees applied

Bear in mind the degree of rotation offset refers to anticlockwise movements within the circle of hues in Image 1. Let’s say we wanted our original blue arrow to be green. Green is an additional one third of the way around the circle from red; a further 120 degrees makes the total offset 240 degrees. The following CSS would produce the results shown in Image 4.

filter: hue-rotate(240deg)

Image 4: The blue arrow shown in Image 1 with a hue rotation of 240 degrees applied

Summary

You can use CSS to change colours within images in real time. This means you can have many versions of icon bitmaps without needing to manage multiple files.

Some colour models distribute the base colour tones across a circle spanning 360 degrees. With the hue-rotate CSS filter, you can work with these models to offset colours in an image by the amount specified. With careful usage, you can leverage this for areas such as theming – you’ll have different-coloured versions of icons, but without the hassle of maintaining separate files.

Thanks for reading!

Using Browser Filters for Mouseover Effects in Web apps

Anthony Fung — Wed, 13 Mar 2024 13:00:00 +0000

Last week, we looked at how we can use different images to change the appearances of icons in our Web apps. This approach gives us more flexibility. It also allows us to be very specific about in how various states look. However, it introduces a downside. By having more images, we increase the overall workload in creating and maintaining them in our projects.

Changing colours within an SVG is relatively simple. As we can reference elements in an image (both individually and collectively), we can specify and modify their colours using CSS – something we can’t do with bitmap images. However, we can leverage powerful CSS filters to do something similar.

In this article, we’ll look how we can create a button with an icon showing a grey arrow; this arrow will turn blue when the mouse cursor moves over it.

Adding Colour

Let’s take our previous use case as an example: we have a button in our app that shows an arrow pointing leftwards. Ordinarily, we want it to be grey. But when the mouse moves over it, we want it to become blue.

When solving this problem with multiple images, we used two images – one grey, one blue. With CSS filters, we can cut this down to just one. By taking advantage of the grayscale filter, we can desaturate (i.e. remove colour intensity from) any image. This means we can convert our blue arrow (Image 1) into a grey one (Image 2) dynamically at run time with the following CSS:

filter: grayscale(100%);

Image 1: A blue arrow without a grayscale filter applied

Image 2: The blue arrow shown in Image 1 with a 100% grayscale filter applied

We’ve passed in a value of 100%. If we wanted to make the effect more subtle, we can tweak this value accordingly. In any case, we can achieve the hover effect with the following code:

<!doctype html>
<html lang="en-US">

<head>
  <title>Image Demo</title>
  <link rel="stylesheet" href="styles.css">
</head>

<body>
  <button>
    <img>
  </button>
</body>

</html>

button {
  filter: grayscale(100%);

  img {
    content:url(../Images/arrow-dark.png);
  }

  &:hover {
    filter: grayscale(0%);
  }
}

In the preceding code, we’re always using a dark blue image of an arrow. In the normal state, we apply a grayscale filter to remove its colour. But in the hover state, we effectively disable it by applying a value of 0%.

Summary

When creating hover effects, an alternative to using multiple images is to leverage the browser's CSS filters. These let you manipulate images in real time, allowing you to keep the number of files required to a minimum.

The grayscale filter lets you desaturate (or remove colour intensity from) an image. When you use this, you can have a greyscale icon or image burst into full colour when certain events happen; an example might be when the mouse pointer moves over it. Its simple syntax lets you specify how strongly to apply it, leaving you in full control of how your images look.

Thanks for reading!

Dynamically Change PNG Icon Colours for Mouseover Effects

Anthony Fung — Wed, 06 Mar 2024 13:00:00 +0000

We previously looked at how we can dynamically change the colours within an SVG image in a Web app. This can be useful for several reasons, ranging from app theming to special effects to improving overall usability.

But what if you’re not using SVGs? If you’re using bitmap graphics – whether JPG, PNG, or something else – it’s not possible to update the colours of image elements in the same way. However, there are a few things we can do. In this week’s article, we’ll look at one possible option.

Using One Image per State

Hover States

Let’s say we have an app, and we want one of its buttons to have an icon of an arrow pointing leftwards. We want it to be grey, until the mouse pointer moves over it. When that happens, we want it to be blue – to show the button is clickable.

We can achieve this by creating two versions of the arrow and saving them as separate images – one where the arrow is grey (Image 1), and one where it’s blue (Image 2).

Image 1: A grey arrow pointing left

Image 2: A blue version of the arrow shown in Image 1

In our app, we can use CSS to show a different image depending on whether the mouse pointer is over the button or not. The following example creates a simple Web page with a single button. The button shows the grey arrow unless the mouse is hovered over it, at which point it shows the blue arrow.



 html

<!doctype html>

<html lang="en-US">

<head>

  <title>Image Demo</title>

  <link rel="stylesheet" href="styles.css">

</head>

<body>

  <button>

    <img>

  </button>

</body>

</html>



 css

button {

  img {

    content:url(../Images/arrow-grey.png);

&amp;:hover {
  content:url(../Images/arrow-blue.png);
}



}

}

Theming

In addition to hover states, we can also use this technique (of having an image per state) for theming. Let’s say we have a light theme and a dark theme. The icons need to be visible when using either, so we want the light theme to use a set of dark-coloured icons against light backgrounds. Similarly, the dark theme should use a set of light icons against dark backgrounds.

If we have a separate stylesheet – or simply use different sections within the same one – for each theme, we can modify the paths to our icon files accordingly.



 css

.dark {

  button {

    img {

      background-color: #222;

      content:url(../Images/arrow-light.png);

    }

  }

}

.light {

  button {

    img {

      background-color: #eee;

      content:url(../Images/arrow-dark.png);

    }

  }

}

Pros and Cons

Having a different image for each icon variation comes with its disadvantages. Because each version needs its own image, it means our projects end up with more files. This can complicate both management and deployment:

The app’s download size potentially increases. The change may be small, but the difference could be noticeable.
A change in colour scheme means recreating and replacing an entire set of icons.
The project becomes more difficult to navigate in source form.
There are more files to keep track of.

However, capturing exactly how each icon should appear in each state means we have a bit more flexibility:

We can then tweak their appearance until pixel perfect.
We can apply advanced image-editing techniques and special effects.
Effects are applied directly to and captured within the image: they’ll look the same in any browser.

Summary

When building an app, you can’t selectively change colours in a bitmap in real time like you can with an SVG. One workaround is using different images.

With this approach, you can still use CSS to define themes and mouse-over states. But the downside is that you end up with more files to manage. This can make a project more difficult to navigate and create more work if you ever need to update any of its colours.

However, you gain some flexibility by doing so. You can edit and tweak each image until you’re happy with it, and you can be sure it’ll look the same in any browser.

Thanks for reading!

Convert Simple Icon Designs from Paper Sketches to SVG Code

Anthony Fung — Wed, 28 Feb 2024 13:00:00 +0000

When building an app, we sometimes find ourselves needing an icon but don’t have one at hand. Perhaps it’s for a ‘back’ or ‘home’ button. Or maybe we need a star for a ‘favourite’ button. One option is to find one we need in any of the numerous available online resources, e.g. Font Awesome or Noun Project. Another is to handcraft your own.

In this article, we’ll look at how you can impart your design skills not only in crafting your code, but also in your app’s icons too. Taking the example of a simple icon, we’ll go from sketching it on paper, all the way to creating an SVG of it.

Sketching the Icon

First off, we need some grid-lined or dotted paper to work on. If you don’t have any, there are many websites you can download graph paper from to print.

In this example, we’ll create an arrow pointing leftwards. You can see our design in Image 1. The gridlines are faint but note that all corners of the arrow occur at where they cross. This is important because it will make the translation to SVG much easier.

Image 1: The initial icon design

Transferring to SVG

Adding Boilerplate Code

Now we have our design, we can transcribe it as an SVG. The first step is to find the co-ordinates of each corner of the shape in our image. The origin point, i.e. (0,0) in an SVG is at its top-left corner. In image 2, we’ve added some numbers along the axes of our icon design to help.

Image 2: Our icon design with co-ordinates marked

The following code is for a simple Web page; the part we’ll focus on is the svg tag and its contents.

<!doctype html>
<html lang="en-US">

<head>
  <title>SVG Demo</title>
</head>

<body>
  <svg width="100" height="100" xmlns="http://www.w3.org/2000/svg">
    <path d="" stroke="#000"></path>
  </svg>
</body>

</html>

Breaking it down, our SVG:

Has a width of 100.
Has a height of 100.
Declares itself and its contents to be in the SVG namespace http://www.w3.org/2000/svg.

It contains a path tag, which has two attributes:

stroke defines the outline colour; this is currently #000 (black).
d defines the outline to be drawn. We’ll add data for our arrow icon here.

Transcribing the icon

Let’s think about how we drew the icon on paper. The process will be difficult to follow when described with words, but the steps are also visualised in Image 3.

We first moved our hand (with the pen off the page) to a point on the page.
We then put the pen tip to the page and drew a diagonal line, moving upwards and rightwards.
Without lifting the pen, we then drew a vertical line downwards.
Then a horizontal line rightwards.
Then a vertical line downwards.
Then a horizontal line leftwards.
Then a vertical line downwards.
And finally, we finished the shape by closing our outline.

Image 3: The stages involved in drawing the icon

We can transcribe these steps using SVG path syntax and our grid co-ordinates.

Move without drawing to (0,5).
From there, draw a Line to (7,0).
Draw a Line to (7,3).
Draw a Line to (15,3).
Draw a Line to (15,7).
Draw a Line to (7,7).
Draw a Line to (7,10).
The command for closing an open shape in SVG is Z. To help with remembering this, think of the last command in drawing our shape corresponding with the last letter of the alphabet.

Putting this together, we have:

M0,5 L7,0 L7,3 L15,3 L15,7 L7,7 L7,10 Z

Let’s enter this as our path data:

<path d="M0,5 L7,0 L7,3 L15,3 L15,7 L7,7 L7,10 Z" stroke="#000"></path>

Adjusting the Icon Colour and Scale

When rendered in a browser, two things become apparent:

The arrow’s body is coloured black.
It’s rather small.

Luckily, these are easy to remedy. To change our arrow’s body colour, we only need specify its fill. We’ll use #ff0 (yellow) in our example:

<path d="M0,5 L7,0 L7,3 L15,3 L15,7 L7,7 L7,10 Z" stroke="#000" fill="#ff0"></path>

To zoom into our icon, we can use the viewBox attribute. This takes four arguments, all based on its content:

The leftmost co-ordinate.
The topmost co-ordinate.
The width of the content.
The height of the content.

These need to be based on the co-ordinates within the image, rather than the actual size it’s displayed at. Looking at our data points, we can see:

The leftmost point in our data is 0. To ensure it is shown, we want the left co-ordinate of the viewBox to be -1.
The topmost point is 0. For it to be seen, we’ll use -1 as the top co-ordinate for our viewBox.
The rightmost point is 15. To include it, we’d want the rightmost co-ordinate to be 16. But because the viewBox starts at -1 and we’re specifying total width, this becomes 17.
Our SVG has both a width and height of 100. To preserve the 1:1 aspect ratio, that of our viewBox should also match: a width of 17 means the height should also be 17.

Adding this to the markup will give us the following, which will produce results as shown in Image 4.

<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg"
     viewBox="-1 -1 17 17">
  <path d="M0,5 L7,0 L7,3 L15,3 L15,7 L7,7 L7,10 Z" stroke="#000" fill="#ff0">
  </path>
</svg>

Image 4: Our SVG icon rendered in a browser

Summary

Raw SVG data can look complex. But the core data format is relatively simple, and transcribing an icon from a paper sketch can be a straightforward task.

By designing an icon on graph paper, you have a way of referencing co-ordinates of key points within it. With those, you can mimic the way it was drawn by using a series of commands in SVG markup. In addition, you can specify colours for the icon’s outline and fill.

Finally, you use the viewBox attribute to adjust both the icon’s position and scale to add the finishing touches.

Thanks for reading!

Dynamically Change SVG Icon Colours for Mouseover Effects

Anthony Fung — Wed, 21 Feb 2024 13:00:00 +0000

When we use images in an app, we sometimes want to be able to change their colour dynamically to react to either some app settings or certain user actions.

For example, let’s imagine we have some toolbar icons. We might have an app with switchable light and dark themes. To maintain good contrast in both modes, we want the icons to be one colour when using the light theme, and another with the dark.

Alternatively, we might want to improve the UX by providing immediate feedback on screen elements that can be clicked on. To do this, we want buttons to change their icon colour when the mouse pointer moves over them.

In this article, we’ll look at ways in which we can accomplish this when using SVG images.

SVG Images

Let’s look at our first use case where we want icons to be coloured differently for light and dark themes. As we’ve previously seen, an SVG image is declared using markup. Like HTML, we can modify its properties using CSS if we can reference it. When rendered in a browser, we should see something like Image 1 with the following code.

<div>
  <svg class="icon" viewBox="0 0 15 25" xmlns="http://www.w3.org/2000/svg">
    <path d="M1,10 L11,10 L11,20 Z"></path>
    <path d="M0,11 L0,21 L10,21 Z"></path>
  </svg>
</div>

.icon {
  width: 100px;
  height: 100px;
  fill: cornflowerblue;
  stroke: darkblue;
}

Image 1: A simple SVG image with styling properties declared for the root element

You’ll notice that the SVG tag that defines the image has an icon class. In the corresponding CSS, we’ve set the fill (i.e. background) to be cornflowerblue; and the stroke (i.e. line colour) to be darkblue. This applies to all child elements of the svg, meaning both triangles are coloured/styled as such.

If we wanted to be more precise, we could style each triangle individually, as we’ve done in Image 2.

Image 2: An SVG image with styling properties declared for each triangle

To do this, we’ve given each triangle a different class (triangle1 and triangle2). In the CSS, we can then be more specific; we’ve coloured the first triangle green, and the second blue.

<div>
  <svg viewBox="0 0 15 25" xmlns="http://www.w3.org/2000/svg">
    <path class="triangle1" d="M1,10 L11,10 L11,20 Z"></path>
    <path class="triangle2" d="M0,11 L0,21 L10,21 Z"></path>
  </svg>
</div>

svg {
  width: 100px;
  height: 100px;
}

.triangle1 {
  fill: lightgreen;
  stroke: darkgreen;
}

.triangle2 {
  fill: cornflowerblue;
  stroke: darkblue;
}

Hover States

For our second use case, we’d like our icons to change colour when the mouse pointer moves over them to indicate that they can be clicked on. Luckily, we can use the CSS :hover pseudo-class to help us – all we need do is declare the styles we want for each state.

In the following code, our icon is blue in its natural state. When the mouse pointer moves over it, its colours change to green. Image 3 shows the result of running this code.

<div>
  <svg class="icon" viewBox="0 0 15 25" xmlns="http://www.w3.org/2000/svg">
    <path d="M1,10 L11,10 L11,20 Z"></path>
    <path d="M0,11 L0,21 L10,21 Z"></path>
  </svg>
</div>

.icon {
  width: 100px;
  height: 100px;
  fill: cornflowerblue;
  stroke: darkblue;

  &:hover {
    fill: lightgreen;
    stroke: darkgreen;
  }
}

Image 3: The icon in its (a) normal state, and (b) when hovered over by the mouse pointer

Summary

When building a Web app, you might want to change the colours of its icons in real time – maybe for theming or UX purposes. This is easy with SVG icons.

An SVG image is declared as markup. Like HTML, the properties of it (or its elements) can be specified using CSS. If your app uses separate stylesheets for different themes, the colours of icons in each theme can be specified directly in the stylesheet.

Similarly, it’s possible to declare hover states. You can use this technique to change an icon’s colour when the mouse pointer moves over it (or its corresponding button). This can enhance an app’s UX by providing immediate feedback to a user to show the buttons that can be clicked on.

Thanks for reading!

An Overview of Scaling SVG vs. Bitmap (JPG, PNG) Images

Anthony Fung — Wed, 14 Feb 2024 13:00:00 +0000

Having looked at the basics of SVG and bitmap formats (like JPG and PNG), we now have a rough idea of their pros and cons. In this article, we’ll look at another important factor that sets these formats apart: scalability.

Getting Things Pixel Perfect – Scaling Bitmaps

A bitmap format represents an image as a series of pixel colour values. Each pixel is a separate entity, and we have independent control over its value. This works to our advantage in images where colours and textures blend smoothly. But when we want to scale an image (to make it either larger or smaller), the nature of being a grid of colour points has its disadvantages.

To explain why, consider Image 1. When we look at it, we see a diagonal line going through the centre of a rectangle. But as a bitmap image, it’s nothing more than a series of colour values.

Image 1: A diagonal line with rounded line endings inside a rectangle

Let’s say we wanted to double its size. As a grid of colour values, we have no concept of there being a line. Instead, we work at the pixel level and duplicate each one horizontally and vertically. And if we wanted to zoom an image to four times its original size, we’d replicate each pixel four times. And so on: we’re effectively increasing the size of each pixel in the image without adding to or enhancing any of its details.

After a certain point, this affects image quality. Image 2 shows the top right tip of the line at different zoom factors. Everything is smooth and sharp at 1x. The image starts to look blurry at 2x but isn’t too bad. At 4x the diagonal line starts to look like a series of steps, and this pixelation is even more apparent at 8x. (The pixel gridlines in the image are an overlay from Affinity Photo – the image editor I used while zooming into the image.)

Image 2: The top right tip of the line from Image 1 shown at 1x, 2x, 4x, and 8x zoom levels as a bitmap

Pixelation is more noticeable with certain types of image content than others. But in general, it isn’t possible to scale a bitmap up too far without it become apparent.

Plotting a Route – Scaling SVGs

SVG images define their content as shapes on a co-ordinates grid. Instead of a series of unrelated colour values, Image 1 would be represented as a series of lines and curves. Scaling an SVG involves multiplying the co-ordinates of its content by the zoom factor. As shapes are mathematically defined, we’re able to recreate them at any scale without any loss in quality.

Image 3: The top right tip of the line from Image 1 zoomed in as an SVG

Image 3 shows the same tip of the line from Image 1, zoomed in as an SVG. Despite a greater scale factor than the 8x level shown in Image 2, the line ending is still smooth and rounded.

Summary

A bitmap format like JPG or PNG represents an image as separate colour values, whereas SVG defines its content as shapes. This affects how scalable an image is.

When working at the pixel level, scaling an image up effectively means increasing the size of each pixel without being able to add more detail. At smaller zoom increases, this can cause an image to become blurry; at higher levels, pixelation becomes apparent and rounded edges become ‘stepped’.

Scaling an SVG involves applying a zoom factor to its content. As shapes are defined mathematically, this process causes no loss in quality; rounded edges won’t suffer from pixelation, even at high magnification levels.

Thanks for reading!

SVG: An Introduction and Overview vs. Bitmap Formats

Anthony Fung — Wed, 07 Feb 2024 13:00:00 +0000

In last week’s article, we looked at and compared two common bitmap image formats – JPG and PNG. These formats represent an image as a fixed-sized grid.

In this article, we’ll look at an alternative way of representing images where more emphasis is placed on the elements within it. In addition to introducing the data format, we’ll look at what it means in terms of storage requirements.

Making a Calculated Choice

A bitmap describes an image at the pixel level. It specifies both the number of points within an image, and the colour of each one. However, the points aren’t related to one another apart from being in the same image. Image 1 shows a green circle on a blue background. Some pixels are blue, some are green. But there’s nothing to say that the green pixels form a circle.

Image 1: A green circle on a blue background

SVG Image Format

Instead of treating an image as a series of colour values in a grid, the SVG format takes an entirely different approach by describing the shapes within it using a dedicated markup language. This makes it unsuitable for certain purposes (like photos) where elements blend smoothly into each other.

Image 1 was created in Affinity Designer. Once exported as an SVG, it – like any other SVG – can be opened in a text editor. The following is a snippet from the output.

It may look complex, but it’s not too hard to see what’s going on if we take it bit by bit.

First off, we have a rect. This represents the blue square we’re using as a background. Looking at its attributes, we see it has:

X and Y co-ordinates (x and y respectively).
Width and height sizes (width and height respectively).
A colour; more specifically, rgb(38,72,184).

Likewise, the circle also has:

X and Y co-ordinates (cx and cy respectively).
A size (r represents its radius – the length between its midpoint and edge).
A colour: rgb(77,209,94).

Neither co-ordinate of the rect is 0, and we might expect the image to be offset as a result. However, this isn’t the case because the image’s elements are all wrapped in a group (g) with a matrix transform to reposition it.

Storage Requirements

SVG markup is semantically rich: each tag describes an element in its entirety. For example, the circle tag defines a circle with its location and size specified by the tag’s attributes. This lets us express a lot of information with a relatively small amount of data, especially when compared to how a bitmap would represent the same image. For reference, Image 1 as an SVG takes 778 bytes.

Summary

The SVG format represents an image differently to how bitmap formats such as JPG and PNG would. An SVG describes its elements using a dedicated markup language, instead of presenting it as a series of colour values in a grid.

This makes the format unsuitable for images where its elements blend seamlessly with one another. However, it means SVGs generally have a much smaller footprint than a bitmap equivalent.

Thanks for reading!

JPG vs PNG: Pros and Cons of Each Format When Building Apps

Anthony Fung — Wed, 31 Jan 2024 13:00:00 +0000

Images can play an important part when building an app. Whether it’s for desktop; mobile; or Web, there’s a chance you’ll need icons or backgrounds at some point.

Three popular formats (in alphabetical order) are JPG, PNG, and SVG. In this article, we’ll look at and compare the pros and cons of the first two. As SVG is conceptually different, we’ll explore it in a later article.

Taking Things Bit by Bit

An image in either JPG or PNG format is a bitmap. The specific process of encoding/decoding each format differs, but they work in the same way once decoded: an image is represented as a fixed-sized grid where each pixel (i.e. grid ‘slot’) is set to a specified colour. Table 1 summarises a few differences between the two formats and may help when deciding which to use.

	JPG	PNG
Compression	Lossy	Lossless
File size	Smaller than PNG	Larger than JPG
Identical to pre-encoded version	No	Yes
Supports transparency	No	Yes

Table 1: Comparison of .JPG and .PNG formats

Storage Requirements

JPG

In general, storage requirements for a JPG file will be less than those for a PNG. However, this might not always be the case: it will depend on an image’s complexity, dimensions, and the specific encoder settings used.

When creating a JPG, the encoder will analyse an image to find parts that can be discarded while having minimal impact on how it’s perceived. This data is then removed to help achieve smaller file sizes. The transformation is lossy: an encoded image won’t be identical to the original version. And depending on the compression level, this process could introduce noticeable artefacts.

It’s also worth noting that repeatedly saving a JPG in a typical image editor will gradually degrade image quality as data is lost each time it’s (re)encoded. For this reason, it’s a good idea to only save an image as a JPG as a final step after any required edits have been made.

While encoded images will contain less data than the original, it might not be noticeable with gentler encoder settings. And if data sizes are important (e.g. to minimise download times) JPG is certainly worth considering.

PNG

While PNG images can also be compressed, the compression is lossless. An analogy would be using 7-Zip to create a compressed archive of a file. We can extract its contents at any time, and the result will be identical to the original. No data is lost in encoding.

This makes PNG a good choice where we want the highest possible image quality, e.g. for charts and diagrams where clarity and/or legibility is important.

The downside is that because all data is kept, a PNG encoded file can be larger than its JPG counterpart. To give an idea of the differences in file size, I took a screen capture of the image shown in Image 1 and saved it (separately) in both formats as a 521x782 image. The resultant file sizes are shown in Table 2.

Image 1: Photo by alex geerts on Unsplash

	JPG	PNG
File size (bytes)	458,643	628,062

Table 2: File sizes of the image shown in Image 1 when saved as a 521x782 image in JPG and PNG format

Image Transparency

Depending on how we plan to use our images, we might need transparency (or alpha channel) support.

This usually isn’t the case for photos; we typically don’t need to see ‘through’ them, though an exception might be if we wanted to lower an image’s opacity to act as a watermark or subtle overlay.

But the argument is more persuasive for icons. Many modern UIs feature buttons and menus that become highlighted when a mouse (or other pointing device) hovers over them. In this context, an icon would stand out for the wrong reasons if the entire rectangular area within its image boundaries stayed the same colour while the rest of the control’s appearance changed to its highlighted state. In this scenario, we’d ideally like an image’s background to be transparent, instead of a solid colour. As we can see in Table 1, this is possible with PNG but not with JPG.

Summary

JPG and PNG are two formats you might use for images when building an app. Depending on intended use, one might be more suitable than the other.

JPG files are typically smaller and so allow for shorter loading times. Depending on the use case, this could make your app feel more responsive. However, this is achieved by removing data from the image. This potentially results in less clarity, or artefacts being added to an image at more extreme settings.

PNG files preserve all image data and are a good choice when you need to prioritise image quality. While they can be larger than their JPG counterparts, the difference in file size may not be significant and will depend on an image’s complexity, its dimensions, and the settings used.

When images are used as photos, you might prefer JPG for a smaller data footprint; this can lead to an app feeling more responsive due to shorter loading times. For charts; diagrams; and icons, PNG gives you the highest possible image quality. Furthermore, it supports transparency; this can give your app a more natural feeling when used on buttons and other UI controls.

Thanks for reading!

Using Virtual Desktops to Stay Organised and Productive

Anthony Fung — Wed, 24 Jan 2024 13:00:00 +0000

It’s usual to have many apps open at once while writing software. As a back-end developer, you might have Visual Studio; Azure Data Studio; and a browser open for documentation. When working front-end, you might have Visual Studio Code, Fiddler, and a browser to see the results of your work. And things can get even more complicated if you’re working both sides.

It’s possible to switch between all open apps using the Taskbar. But leveraging virtual desktops to create a different workspace for each of your workflows could give your productivity a boost.

A Workspace for Each of Your Workflows

You’ll likely have encountered virtual desktops before if you’ve used Linux or macOS. However, it’s only been a native feature in Windows since Windows 10.

Each virtual desktop gives you a separate workspace in which you can arrange your apps in any way you want – if you’re working full stack, you could dedicate one virtual desktop exclusively for back-end tools; and another for building a front-end Web client.

While there’s nothing to stop you from having all your apps open on a single desktop, the ability to group related tools together gives you options to help stay focussed and organised.

Managing your Workspaces

Creating and Navigating Virtual Desktops

In Windows 11, you can create a new virtual desktop in one of two ways:

Using the keyboard shortcut Ctrl+Win+D.
Via the Task View: press Win+Tab and select New desktop – this option is highlighted in Image 1.

Image 1: The Task View in Windows 11 with ‘New desktop’ highlighted

When using option (1), you’ll automatically switch to using a newly created virtual desktop. With option (2), the new desktop will appear in the list at the bottom of the screen where and can select it.

Regardless of how they’re created, you can move between your virtual desktops in one of two ways:

The keyboard shortcuts Ctrl+Win+Left Arrow and Ctrl+Win+Right Arrow. These move to the previous and next desktop respectively.
Clicking on the desktop you’d like to use in the Task View.

Moving Apps Between Virtual Desktops

When working with multiple virtual desktops, opening an app launches an instance of it on the desktop that’s currently active. If you later decide it would be better suited on another, it’s easy to move. The Task View shows the apps open on the current desktop, and all available desktops along the bottom of the screen. From here, it’s possible to drag the app you want moved and drop it on the desktop you’d like it to go to. To illustrate this, image 2 shows moving the Calculator app from Desktop 1 to Desktop 2.

Image 2: Moving Calculator onto Desktop 2

Things get a bit more complicated with apps that are set up to be a single instance. For example, let’s say we have an instance of Microsoft Excel open on Desktop 1. If we move to Desktop 2 and try to launch Excel again, we’ll find we jump straight back to Desktop 1. This is because Excel is already open there; when not opening a different workbook, Excel’s behaviour is to maintain a single instance. In this case, we can work around it by opening another workbook. This will launch a new Excel instance, which we can then move to Desktop 2.

Closing Virtual Desktops

If you no longer need a virtual desktop, you can easily close it by either:

Pressing the keyboard shortcut Ctrl+Win+F4. This will close the active desktop.
Clicking on the close button located in the top right corner on the respective desktop in the Task View (Image 3).

Image 3: The Task View with the button to close Desktop 2 highlighted

Closing a desktop doesn’t close the apps on it. Any that are open will be moved (and will appear) on the desktop to the left of it; for example, apps on Desktop 2 will be moved to Desktop 1 when Desktop 2 is closed. You’ll need to manually close any apps you no longer need.

Summary

It’s easy to lose track of things when working with many apps. Virtual desktops is a powerful feature in Windows 11 that can help group related tools together.

Each virtual desktop acts as a separate workspace where you can arrange your apps as required. The Task View allows you to manage your currently open apps and desktops. Here, you can create new virtual desktops, move apps around, and close any that are no longer needed. If you prefer, there are keyboard shortcuts for navigation too.

With this, you can create themed workspaces where you only have the tools you need open. And if you need to temporarily change focus, you’ll be able to quickly switch to another toolset with minimal disruption to your workflow.

Thanks for reading!

Static Helper Class vs. Injected Service: Pros and Cons

Anthony Fung — Wed, 17 Jan 2024 13:00:00 +0000

We’ve all worked on apps and services that weren’t as clearly written as they could have been. While we try our best, the combination of complexity and time constraints can result in code that needs a bit of time to get into before making modifications.

One way of reducing complexity – even if only to save ourselves a bit of head scratching when returning to our own work a few days later – is to follow the Single Responsibility Principle. If we find we later need to redefine the meaning of 'single', or if code was written without the SRP in mind, it’s still possible to apply it; we identify multiple responsibilities within an entity (this could be a module, class, or method), and refactor them into their own units. When doing this, we have two choices:

Move logic into a new class we can instantiate (and inject as a service).
Extract it into a static 'helper' class.

While these approaches may appear similar, there are differences that may make one choice a better (or worse) fit.

Going Head-to-Head

Before diving in, let’s first refresh our memories on the concept of a pure function. This style of method doesn’t use or modify state variables. Its outputs are entirely dependent on its inputs, and providing the same set of arguments will always lead to the same result.

Another way of looking at it is that we should be able to replace a pure function with a value-lookup table and have everything continue to work.

Testability of Extracted Functions

In terms of testing the extracted logic in isolation, there typically isn’t much difference between static and instantiable classes. In both cases, we’d need to setup our tests in similar ways. With pure functions, the main difference would be how we invoke the methods to be tested, i.e. whether we need a class instance.

The exception to this would be where state is involved. In this case, we’d need to remember to reset our classes between tests, and also be mindful about running them in parallel. This is easier with instantiable classes because we can create a new instance per test – something that isn’t possible with a static class.

Coupling and Testability of Calling Classes

The main advantage of a static class lies in its simplicity. Once created, its (public) methods immediately become available for use anywhere within a codebase. There’s no need to consider creating additional interfaces, no need to tweak IoC framework modules, and no need to modify the constructor parameters of any classes. For this reason, a static class can be a good choice for self-contained helper methods that form part of an importable class library, possibly via NuGet.

However, this simplicity is also a double-edged sword. A static class will help separate code in source form, and it’ll help in following the DRY principle. But it doesn’t reduce coupling between responsibilities.

Whether this is a problem depends on the context. A good example of where using a static class makes sense is System.Math. The functions it contains return values that are widely accepted to be correct. There’s no need to set them up with input/output value pairs and returning anything other than what they do typically isn’t useful, not even for testing purposes.

Another example where this might not be a problem is a library that converts between different colour formats/models. After all, mocking a service to transform red rgb(255, 0, 0) into the hex code for blue #00f probably isn’t useful.

Let’s contrast this with logic for calculating a password hash for example. While this too should produce consistent results, there is value in mocking its outputs in tests. Imagine writing a test that verifies a method:

Takes a password string.
Hashes the password into a long hash value.
Compares it against a known value in the test assertion.

If a real hashing algorithm is used in step (2), it could unnecessarily increase the time it takes for the test to run. More importantly, it reduces its focus. Instead of only checking that the process is followed, we’d also be incorporating knowledge about the output hash. (While testing the password transformation is important, it can – and should – be done in a separate test.) Lastly, if we ever changed the hashing algorithm, we’d need to update this test.

Summary

When refactoring code into separate classes, you can often choose between creating new static or instantiable classes. The best choice often depends on context.

When you create a static class, you’ll build a solution that’s easy to use and requires minimal changes (if any) to integrate. These are often a good choice for standalone logic where functions have widely accepted expectations or conversion results.

By creating an instantiable class, you’ll allow for more flexibility by decoupling separate concepts. While needing a bit more effort to incorporate, you’ll find it can be easier to write tests for and run in parallel. As a bonus, you might be able to avoid modifying your tests if you ever need to change your implementations.

Thanks for reading!

How Programming to an Interface Affects Testability

Anthony Fung — Wed, 20 Dec 2023 16:46:36 +0000

We’ve previously explored how a slight change in mindset can make our code more flexible. Thinking in terms of what we’re doing rather than how can help us to architect our software to be more modular. We benefit from this by producing code that’s potentially less brittle in the face of requirements changes; reusable; and adaptable for various environments. This week, we’ll look at the implications of programming to an interface when it comes to testing.

The Problem with Holding All Responsibilities

It’s worth noting that not all forms of testing are affected. The main advantage of having a modular design lies in the ability to swap a component’s dependencies freely and easily for others. However, some tests focus on the bigger picture. End-to-end and manual tests typically verify the workflows of a finished product. And as such, the way that it’s put together is irrelevant for these types of tests; they are only concerned with how the product behaves as a whole.

However, writing unit and small integration tests becomes much easier. When attempting this for code that wasn’t written with testing in mind, we sometimes encounter two characteristics:

Dependencies are presented as concrete class types.
A class contains multiple tightly coupled responsibilities.

This in turn presents three challenges:

Tests become more complex to set up: we need to create and configure real instances of objects that are merely dependencies of the actual test subject.
We need to design our tests more carefully: we must factor in the additional processing these dependencies will perform, which may not be directly related to (but also cannot be isolated from) the code we want to test.
The code can become impractical to test.

To further explain point (3), let’s consider an example. Imagine we have a method that:

Accepts data via a parameter.
Converts it from one type to another.
Writes it to a database.

We’d like to test the conversion logic, and we could theoretically provide a database to write to. But we’d prefer not to have to persist the results of a unit test, especially as doing so is outside the scope of what we’re testing. And it’d slow down something we’d run both repeatedly and regularly.

Alternatively, consider a method for logging errors, which:

Takes a message as a parameter.
Adds a timestamp.
Writes it to storage.

While the code itself is relatively straightforward, it becomes difficult to test if the timestamp is obtained by calling DateTime.UtcNow directly. By doing this, we’d need to know the exact time every time the test was run to determine whether the logged message is correct.

Modularity to the Rescue

Both examples of how code can become impractical to test suffer from the same problem: it’s trying to do too many things.

In the first example, logic for writing to a database is coupled with that for mapping data types. It’s important that we have both for the system to work correctly, but we can separate the two concerns. By introducing an interface for a data repository, we can say we want to store data. But we don’t say how, nor do we need to at this level. It also means we can bypass writing to a database in our unit tests. Instead, we can provide an implementation that stores data passed to it in a variable, which can be used later if necessary.

Again, we can break apart the two distinct responsibilities in our second example. By introducing an interface representing a timing service, we can say we want the current time and date without specifying how we obtain it. In unit tests, we can use an implementation (whether in the form of a mock, stub, or fake) that returns a constant time value. This gives us the power to manipulate time – at least as far as the logging service is concerned.

Summary

Writing tests is difficult when multiple responsibilities are tightly coupled within the same body of code. Programming to an interface can help separate them.

Without doing so, tests could be unnecessarily cumbersome to set up due to their subjects needing concrete implementations of their dependencies. Furthermore, they may need more careful design to cater for the additional moving parts. This can lead to code that’s impractical to test.

However, you can prevent this from happening by identifying boundaries between conceptually separate systems within your code. By introducing interfaces at these points, you loosen the coupling between them. In doing so, your code becomes cleaner and more modular. Its subsystems can be swapped for simpler and more predictable substitutes while testing. Ultimately, you’ll produce code that’s easier to both test and maintain.

Thanks for reading!