Tweaking the CSS stylesheet

I’m trying to do some tweaks on the darktable.css stylesheet but I’m struggeling. I’m on Ubuntu 18.04, Roboto fonts not installed. The default font family of GTK3 is Ubuntu 9 as found in ~/.config/gtk3.0/settings.ini. In darktable.css one can find (around line 160)

/* Reset GTK defaults - Otherwise dt inherits Adwaita default theme dark */
background-color: @bg_color;
background-image: none;
font-family: sans-serif;
font-size: 1em;

My understanding is that the generic font-family sans-serif of Ubuntu 9 is used, the font-size inherited from the “natural” font-size of the font used by GTK3. If one reduces the font-size to 0.9em, one should expect to downscale the font to 90% of its inherited value. But this is not the case. The resulting downscaling is far stronger, most parts of the GUI are nearly unreadable, the resulting font-size is extremely tiny. If I set

font-size= 9pt;

the behaviour is as expected. Allmost all labels of the GUI keep the same size. And reducing the value to

font-size= 8pt;

scales down the size of the labels by a moderate value.
In a next step I tried to replace the generic font by font “Liberation” also installed in my system. But replacing all occurences of

font-family: sans-serif; by > font-family: “Liberation Sans”; and
font-family: monospace; by > font-family: “Liberation Mono”;

changes nothing. The default font (Ubuntu) is still used, the font-family settings seem to be ignored completely. I tried with other installed fonts (Ubuntu Mono for example) finding the same behaviour. Can anyone shet some light on what’s going on? Is this a buggy behaviour or am I completely missing something?

Which theme do you have selected in the preferences? Are you opening and closing darktable to view the change?

Independent of theme, and yes, closing and opening after changing stylesheet. But on linux closing and opening is not nessesary, changing the style in preferences forces reading the changes and setting them.

Please answer this too.

Yes, which theme, which desktop (Kde, Gnome, Xfce…) and which desktop default font size ? You also say Ubuntu 9 (what’s that ? The 9 ? Font size ?). And, which Ubuntu font (Regular, thin, etc…) ?

Also, do you use some font scale factor on desktop ? That could be also a reason to your issue.

I recently see that some users have, for example, some anti-aliasing issues on darktable text just because they use KDE and default anti-aliasing options on KDE don’t work correctly with Gtk library.

So your issue could have many reasons, but not the CSS. I work on it and tested it on Gnome and Kde, and font size is related as it should. What could be difficult is to find which setting on your system is the reason of your issue.

Oh, and last thing : Gtk+3 version installed by default on Ubuntu 18.04 (Gtk+ 3.22) also have some known issues related to font applied by CSS. Like the order font not applied correctly. Something, as I remember, solved on 3.24 release (not sure which one exactly after 3.22).

As said, independent of theme selected in darktable. Xfce-desktop, GTK3 default font is Ubuntu regular 9 pt as taken from .config/gtk3.0/settings.ini. No scaling factor for desktop, standard full-hd monitor, no 4k screen. GTK3 version cannot be checked, I’m not at the computer a this moment. I will check this tomorrow. Thank you for the hints, Nilvus.

darktable.CSS is one theme, and other themes import and over ride this theme, so if you’re changing darktable.CSS but have another theme selected that is over riding it, you won’t see your changes.

Of course, you are right. But in my understandig darktable.css is the central one where all the settings for the fonts are defined. I’m not on my computer at the moment, and I don’t remember the exact names of the themes I tried. I tried several different themes.
And this does not explain the strange behavior when font-size is modified from 1em to 0.9em. The font is downscaled, so I’m shure the modification has been detected by darktable, independent of the theme I actually selected. But the scaling is not to 90% as expected, but perhaps to 10%. And setting the font-size to the absolute value of 8pt (which also is approximately 90% of the default size of the GTK3 font) shows a competely different behavior. In this case the scaling appears as expected. Actually I use this absolute value of 8pt as a workaround. But setting absolute lenghts in a central stylesheet is not a good style… Nilvus mentioned that there are known issues of GTK+3 on Ubuntu 18.04. I will have a look on this tomorrow.

It is difficult to help without knowing the specifics. Yes darktable.css is the central one, but other themes modify and over ride the styles, especially the fonts.

As far as I remember, the stylesheets around darktable.css contain mainly (or only) definitions of different colors. But at the moment I can‘t check this, because I can’t edit the files on the tablet I’m just using. Tomorrow I continue looking for the reason of the issue. And I can tell you the exact name of the styles I used. Thank you for your effort to help.

@Nilvus here is the (comlete I hope) list of information :

  • Linux 4.15.0-76
  • #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020
  • Ubuntu 18.04.3 LTS
  • Lubuntu : Desktop Xfce
  • GTK+3 version : 3.22.30-1ubuntu4
  • Desktop theme : ThinIce (as shown in screenshot below)
  • Font : Ubuntu 9 (which means Ubuntu regular 9 pt to my knowledge)
  • Symbol-theme : GNOME


  • Darktable version 3.1.0+447 (build from source last saturday)

Themes used in darktable for testing the tweaking of the stylsheet darktable.css :

  • darktable-elegant-grey
  • darktable-elegant-dark
  • darktable.css

darktable-elegant-grey.css and darktable-elegant-dark.css both import darktable.css and (re)define a number of colors but do not change any settings relevant to the size of the font to be used.
The only parameter I modified is font-size, line 163 of darktable.css. You can see the result for 6 different values 3 relative sizes (em) and 3 absolute sizes (pt).

The results are as expected for 1em, 8pt, 9pt and 10 pt.
For 0.9em parts are downscaled correctly, others appear extremly tiny.
For 1.1em everything gets huge.
I think this is an undesired behaviour.

The application where you’re selecting your theme looks like a gtk2 theme selector. If it is a gtk2 theme, then those settings will not effect darktable.

Perhaps you want to try rem units and not em units. I didn’t take a ruler to your screenshot, but it looks more or less correct.

The application where you’re selecting your theme looks like a gtk2 theme selector. If it is a gtk2 theme, then those settings will not effect darktable.

No, I don’t think so. The config file of GTK+3 (.config/gtk-3.0/of GTK+3/settings.ini) has the following content :

gtk-font-name=Ubuntu 9

and this is what is shown in die screenshot of the dialog.

I didn’t take a ruler to your screenshot, but it looks more or less correct.

Sorry, but I don’t understand this comment.

  • Compare the size of the labels “Schatten: Lift/Offset” for 1em and 0.9. Without any ruler you see that the downscaling is not 10% as expected, but far more than 50%.
  • Compare the on/of icons for the modules for 1em and 1.1em. They are not upscaled by 10% as expected but by a factor of 3 or 4.

I also followed your proposal to scale relative to the font-size of the root element with “rem”. And this works as expected. So I think the yesterday assumption of @Nilvus was correct that GTK+3 version 3.22 has some issues relating to the font(size). Thank you for the hint.

Until now I edited the darktable.css from /opt/darktable/share/darktable/themes as root. On the FAQ one can find

It is possible to customize the looks of darktable by copying the darktable.css file to ~/.config/darktable/ and editing it.

I tried this today but it does not work. The original file from /opt/darktable/share/darktable/themes is used, the modified personal copy in ~/.config/darktable/ is ignored. I’m starting darktable as normal user from my home directory with help of a .desktop file, so in my understanding the personal copy of the stylesheet should be preferred over the original one. Am I missing something or is there no longer support of the behaviour described in the FAQ ?

One thing forgotten to be updated, the FAQ. Since the add of new themes, the correct folder to use is : ~/.config/darktable/themes (last folder needs to be created). And copying the CSS and editing it is just the easiest way but not the better. The better is to import the default CSS (or the one you want to edit by the @import line (just copy it from a default css (grey, dark or darker one for example) and edit the line to point to where the default css is. Then just copy parts you want to change and edit them. That’s easier to maintain after than having lot of lines not changed.

I will try to remember to propose an updated FAQ soon (no time this day and probably no more tomorrow).

1 Like

That is exactly what I want to do. But the first attempt was just to create a copy to test the functionality ( … and it did not work). Thank you for the fast clarification.

OK, all stylesheets in /opt/darktable/share/darktable/themes remain unchanged, tweaks are applied to a copy of darktable-elegant-grey.css in ~/.config/darktable/themes. The import chain is

which imports
which imports

This works as expected, but two questions remain. The first is :

{ font-size: 0.9rem; }

works as expected, the components are scaled down by 10 % relative to the predefinded value of 1em from darktable.css. This is shown on the right side of the screenshot.

But using

{ font-size: 0.9em; }

scales down most components far more than 10%, most components become really tiny as shown on the left side of the screenshot. I’m not the super expert on CSS, but I used it several times, so I know about inheritance of properties and about scaling lengths of components (widths, heights, sizes…), overwriting properties by subsequent definitions. But the behaviour above seems curious to me.

Using 1rem or 1em generates the same result. Sizes of components appear identical. But scaling this size (whatever absolute value it represents) in both cases by a simple linear factor (0.9) behaves completely different. In the first case the result is as expected, in the latter case it is not. This scaling is simplest math. I’m wondering what happens here ?

The second question is related to the size of the label of the dropdown (see second screenshot). Scaling the font-size to 0.9rem as shown above has different impacts on the sizes of header_label, darktable_label, view_label on one side and view_dropdown on the other side.

The code snippet below shows the relevant part taken from darktable.css.

background-color: transparent;
font-size: 1.5em;

I wanted to compensate the different sizes by increasing the font-size of the dropdown. But nothing changes if I set for example

font-size: 2.5em;

in the local darktable-elegant-grey.css, while the same code for the other components works as expected. I looked for further appearances of #view_dropdown in darktable.css, but none of them should have an influence on the font-size. Again I’m wondering what happens ? Bug, or am I missing something fundamental ?

edit : there seems to be an issue uploading the screenshots (png files). Its shown “uploading…” when I drag an drop the images, but they are not shown.

second edit : I just figured out the answer to the first question

  • the unit rem always refers to the root element which in the present case is the size of the font delivered by GTK+3.
  • the unit em always refers to the parent of the actual element. In the present case this means that an element embedded into another element is scaled two times by the factor used (0.9 x 0.9 in the example above). And so on. The deeper an element is embedded into others the smaller it gets when scaling with unit em.

On this point of view in my opinion it would be more comfortable for the user, if darktable.css would always refer to the root element in line 163 by using font-size= 1rem. This would make tweaking the file simpler, because it is more predictable what is happening, when an (child, grandchild…) element is to be scaled later.

In CSS, em units scales the font size of the currently selected element. rem units scale the font size of the current element using the font size of the document’s root element. If the size of the root element and the current element differ, then rem and em will give different results.

In CSS, em units scales the font size of the currently selected element. rem units scale the font size of the current element using the font size of the document’s root element. If the size of the root element and the current element differ, then rem and em will give different results.

Of course, but this is a very general remark. Why should we have two different “units” if they had the same function. So it is obvious that they behave different. But the problem is a bit more complicated and appears if your objects which you want to give a style, have a highly hierarchical structure (which is the case at the dartable GUI). The article exactly decribes what I mean and gives some excellent examples. My conclusion of this article is : It would be a very approriate solution to set

font-size= 1rem

instead of 1em at line 163 of darktable.css. If a user wants to downscale all elements by 10%, he (she) only has to set font-size= 0.9rem and 95% of the work is done. Only some small tweaks ( about 4 or 5) have to be done for some elements to get a good looking and well balanced style.

rem is just rarely used and it’s difficult to think and adapt to all users cases/wanted uses and specific DPI scale factor used on different OS. And good thing about CSS is it’s quite easily tweakable. So feel free to adjust it as you want. That’s the goal of CSS themes.

rem is quite recent (2013) regardless of others CSS units and W3C just say that on their webpage units : “Because they are so new, they don’t work everywhere yet. But, as of early 2015, several browsers support them.” (

Anyway, I will test if it could be better to change that (and verify which Gtk versions correctly renders this quite recent unit. I spent quite a lot of hours tweaking and adjust CSS to finish Aurélien big work on the UI and correct a lot of UI glitches. What I learnt making this work is that changing a parameter could sometimes breaks other parts (sometimes not visible at first). And I have read some different fonts rendering between Gtk+ 3.22 and 3.24… So we have to be careful.