Using brand font: only one box is behaving differently

Hi! Trying to close pending issues here, there is one that is making me nuts!

I’m using a number of different browsers, running on different operating systems, to access our XWiki instance. I’ve set up Roobert as our brand font.

All but one box are showing the font correctly. I’m not able to find the reason. While Roobert is set up, this box, a laptop running Windows 11 Pro, keeps showing Times New Roman:

f67051e18b2896abdf4dc92ad6847ed149cac07c

The picture above belongs to a Firefox window, but the same happens with Chrome, Edge or Opera, for instance.

The settings:

image

And other boxes show:

Could you help me to find why? Thanks!

Good afternoon!
I’m not very knowledgeable about the implementation of fonts in XWiki yet.
From what I can see, this would either be:

  1. The standard font from the OS that takes over the XWiki style (doubt that’s it though)
  2. Somehow your box uses the @font-family-serif variable instead of @font-family-base (not sure why this happens). This variable is set at xwiki-platform/xwiki-platform-core/xwiki-platform-bootstrap/src/main/less/variables.less at de55262bf6fcdd1ab49cae3e0c6e791d01f0412b · xwiki/xwiki-platform · GitHub .

It’s very probably no. 2. Maybe it would be solved by overriding @font-family-serif in your colortheme :thinking: I’d advise you to at least try it out so that we can be sure the path to resolution is 2. :slight_smile:

If you can confirm that it’s no 2., could you check out where this font CSS rule is set? With the name of the file and the whole ruleset, it would be easier to progress towards a solution.

I highlighted in orange below the kind of element you should be looking for and sharing :slight_smile:

Thanks for bringing this up!
Lucas C.

Thanks, @CharpentierLucas! Sorry for the delay with the feedback.

Does the set-up below override @font-family-serif?

Below what I get in several computers I’m using to access the site. They are honouring the font branding:

And now, what I’m getting in, now, two computers, both updated to the last-minute releases. One running Windows 11 PRO:

The other one on Ubuntu 24.04.1 LTS:

A last funny thing I don’t understand. See below:

I created that Engulfing skin a time ago, but it is not currently set for any page. Do you understand why it appears on the URL?

The whole thing is very confusing to me. I will keep trying to find an explanation and solution, focusing on point 1 of your previous reply. Let me know if I can be of any further help!

Thanks!

Yup :+1: Note that this kinda works, but this could also create some weird behaviors for features supposed to use this serif font (none in XWiki Standard AFAIK). As I’ll detail later, trying out this change is also a great step towards finding where your oddity comes from :smiley:

I didn’t check your result well enough at first. I assumed the font-family property was in line with the Fonts Used . I’m leaving a paragraph for the sake of keeping traces of my search, it could still end up useful at some point :slight_smile: See the actual answer after this paragraph.

Good thanks!
Seems like the problem got solved by the small change, so it’s definitely a place in the code that uses this @font-family-serif variable. From your screenshot, we can be sure that it comes from a CSS ruleset on the whole body.

When I check the CSS source, I can see that this is close to a -webkit-tap-highlight-color property. This is quite specific, so I can search in the codebase: Code search results · GitHub

There’s only one result, and I can be sure that this CSS comes from this code:
xwiki-platform/xwiki-platform-core/xwiki-platform-bootstrap/src/main/less/scaffolding.less at 36aa8062822b50c8e488eb65a492ef1c0a48a114 · xwiki/xwiki-platform · GitHub

Soooo. It seems that our issue is that with Windows 11 PRO, @font-family-base takes the value of @font-family-serif instead of the default @font-family-sans-serif. To see where that comes from, I look for all the assignations of this LESS variable in our codebase. This is most likely with @font-family-base:<somethingafter>: Code search results · GitHub .
On this, I can see that the only assignations do not seem to care about the context, the only ones to a serif font are in the Bootswatch Colorthemes Journal and Readable.

After this research, it doesn’t seem like it’s an issue with XWiki Standard. I didn’t test any further so I cannot be 100% certain.

Soo, the Fonts Used is not the same as the font-family. This is weird. This looks like it might be the OS messing with our browser here. I tested with BrowserStack - Windows110 + Firefox 133:

We can see that, similarly, the default font is not the same as the one we have in style. Time to learn more about how this property works:

Values are separated by commas to indicate that they are alternatives. The browser will select the first font in the list that is installed or that can be downloaded using a @font-face at-rule.

You should always include at least one generic family name in a font-family list, since there’s no guarantee that any given font is available. This lets the browser select an acceptable fallback font when necessary.

As far as I understand, your two machines do not have it downloaded, and cannot access it because you didn’t add a specific @fontface. Not sure if we have doc for this, if there is, we should fix it to avoid people doing the same mistake. I think you could solve your issue cleanly by adding a @fontface for Roobert into your colorTheme’s @lessCode property (or in any SkinExtensionSheet).

You might find some helping info at https://www.xwiki.org/xwiki/bin/view/FAQ/How%20to%20use%20a%20custom%20font%20in%20XWiki

Sorry for all the flailing around, I wasn’t very knowledgeable about fonts in CSS. It was a good opportunity to learn a bit more, thanks :slight_smile:

Not sure why, this URL’s job is to retrieve the CSS for your page. In the request to get this CSS to your server, it provides some context elements so that it can be served a cached value if there’s one already on your server. For each CSS, your server caches it for each Skin and ColorTheme (and updates the cache as soon as the skin or colortheme is updated). It’s especially useful for LESS files where the compilation to CSS can take a very noticeable time.

It seems like your active skin is Engulfing. My guess is that it’s an extension of the DefaultSkin and it’s still somehow active even if you don’t have any customization. Here is what the URL on a standard instance I run locally looks like:

If you’re sure you use the Default Skin and not your custom one, this could be a small bug with the URL constructor. :thinking:


Have a good day!
Lucas C.

1 Like

That’s it! Big thanks! I will elaborate later, but I don’t want to wait to communicate that it works as the FAQ entry reads. From one of the “in troubles” machines now:

As usually, I’m learning a lot. Thank you very much!

Hi! Back on track! I’m failing at adding @font-face, but it is probably due to my lack of knowledge about CSS syntax. I will investigate further.

But, before, identify my faults and try to understand why I was completely lost for months.

  1. The first error was to test only with boxes around me and never check the results in person in remote desktops. All the people around me have Roobert font installed in their computers, as it is our new corporative image font.
  2. The second error was relying on the idea I got from release 1.1 of the FAQ entry How to use a custom font in XWiki?. The current 2.2 version has much more information.

Once at this point, I’m completely confused by the box under Upload locally custom FFT file. It currenlty reads:

I will think for a while and open a new thread about it. I’m confused about the meaning of “your machine”, “locally”, and why to upload fonts to /webapps/xwiki/WEB-INF/fonts. Thanks for your time!

@nikpetrenko
Just pinging you so you know that your improvement of this doc is appreciated! :wink:

1 Like

Great guys, this is cool! :+1:

@CharpentierLucas / @nikpetrenko Small note: Could you please update the page to follow our image best practices (using the image macro), see https://dev.xwiki.org/xwiki/bin/view/Community/DocGuide#HScreenshots2FImages ? Thx again

Done what I could to improve it :+1:

  1. I just checked again the image best practices, You should save your images only as PNG. Here we use a GIF. GIF is an image format but animated GIFs provide something other images do not, it’s probably not possible to replace with one or two PNGs. I’ll open a proposal to discuss allowing the use of GIFs in our doc (or explicitely ban it if that’s what the consensus ends up on)?
  2. Changing the width of the image breaks the animated aspect of the GIF, so I left it as it is for now (images in doc are supposed to have one of four standard widths).
1 Like

thx for the feedback @Ricardo_Rodriguez. I’ve recently updated the FAQ to make it more clear.

Yes, I haven’t mentioned this information because I have only found about in Developer Mozilla section.

I thought to add this information, but from my view it will overload FAQ entry - a bit hard to follow-up.

thanks for link, When I initially created that FAQ I checked the guides and I found only what’s mentioned by @CharpentierLucas

If it’s a case, I can replace GIF with valid PNG.

Hi! Cool to see more people involved! @CharpentierLucas, @nikpetrenko, what is not clear to me yet is what I must expect from the option Upload locally custom FFT file. What is the point of copying the branded font files to the directory /webapps/xwiki/WEB-INF/fonts? What machine is your machine? Is it the box running the XWiki instance?

I’m a bit lost. Thanks for your help!

/webapps/xwiki/WEB-INF/fonts it’s XWiki folder. And you can store a new font there, and it will require the restart of XWiki instance. Only XWiki will know how to use this new font.

Whereas the machine it’s your OS, and by storing a font there, every program will recognise a new font. But in order to let XWiki know about the new system font, restarting or logging out will be mandatory. There can be situations in which you won’t have proper rights to paste or unzip a new font into your OS’s system folder.

Got it. Let me summarize the situation here.

We are running a XWiki Debian 16.10.0 instance on Ubuntu 22.04.5 LTS. It is publicly reachable here. We have a Nginx server working as reverse proxy in front of that box.

The content of /usr/lib/xwiki/WEB-INF/fonts is:

rjr@e220i057h096l:/usr/lib/xwiki/WEB-INF/fonts$ ls -l -Rt
.:
total 50780
-rw-r--r-- 1 root root    92332 sep  3 00:38 RoobertRegularItalic.ttf
-rw-r--r-- 1 root root    87140 sep  3 00:38 RoobertRegular.ttf
-rw-r--r-- 1 root root    92116 sep  3 00:38 RoobertSemiBoldItalic.ttf
-rw-r--r-- 1 root root    87100 sep  3 00:38 RoobertSemiBold.ttf
-rw-r--r-- 1 root root    90692 sep  3 00:38 RoobertLightItalic.ttf
-rw-r--r-- 1 root root    85888 sep  3 00:38 RoobertLight.ttf
-rw-r--r-- 1 root root    92408 sep  3 00:38 RoobertMediumItalic.ttf
-rw-r--r-- 1 root root    87040 sep  3 00:38 RoobertMedium.ttf
-rw-r--r-- 1 root root    91980 sep  3 00:38 RoobertBoldItalic.ttf
-rw-r--r-- 1 root root    86804 sep  3 00:38 RoobertBold.ttf
-rw-r--r-- 1 root root    90592 sep  3 00:38 RoobertHeavyItalic.ttf
-rw-r--r-- 1 root root    86120 sep  3 00:38 RoobertHeavy.ttf
-rw-r--r-- 1 root root 21053592 sep 25  2023 uming.ttc
-rw-r--r-- 1 root root 10385096 sep 25  2023 gulim.ttf
-rw-r--r-- 1 root root  8061296 sep 25  2023 ipam.ttf
-rw-r--r-- 1 root root    35147 sep 25  2023 LICENSE-freefont
-rw-r--r-- 1 root root      482 sep 25  2023 LICENSE-gulim
-rw-r--r-- 1 root root     9062 sep 25  2023 LICENSE-ipam
-rw-r--r-- 1 root root     4301 sep 25  2023 LICENSE-noto
-rw-r--r-- 1 root root     6901 sep 25  2023 LICENSE-uming
-rw-r--r-- 1 root root   418804 sep 25  2023 NotoEmoji-Regular.ttf
-rw-r--r-- 1 root root     5115 sep 25  2023 README-freefont
-rw-r--r-- 1 root root      581 sep 25  2023 README-gulim
-rw-r--r-- 1 root root      420 sep 25  2023 README-noto
-rw-r--r-- 1 root root      855 sep 25  2023 README-uming
-rw-r--r-- 1 root root     4581 sep 25  2023 TROUBLESHOOTING-freefont
-rw-r--r-- 1 root root     6060 sep 25  2023 USAGE-freefont
-rw-r--r-- 1 root root     6904 sep 25  2023 AUTHORS-freefont
-rw-r--r-- 1 root root    23240 sep 25  2023 CREDITS-freefont
-rw-r--r-- 1 root root   295360 sep 25  2023 FreeMonoBoldOblique.ttf
-rw-r--r-- 1 root root   296284 sep 25  2023 FreeMonoBold.ttf
-rw-r--r-- 1 root root   390692 sep 25  2023 FreeMonoOblique.ttf
-rw-r--r-- 1 root root   584424 sep 25  2023 FreeMono.ttf
-rw-r--r-- 1 root root   342488 sep 25  2023 FreeSansBoldOblique.ttf
-rw-r--r-- 1 root root   416128 sep 25  2023 FreeSansBold.ttf
-rw-r--r-- 1 root root   763696 sep 25  2023 FreeSansOblique.ttf
-rw-r--r-- 1 root root  1563256 sep 25  2023 FreeSans.ttf
-rw-r--r-- 1 root root   608708 sep 25  2023 FreeSerifBoldItalic.ttf
-rw-r--r-- 1 root root  1310828 sep 25  2023 FreeSerifBold.ttf
-rw-r--r-- 1 root root   922088 sep 25  2023 FreeSerifItalic.ttf
-rw-r--r-- 1 root root  3303588 sep 25  2023 FreeSerif.ttf
rjr@e220i057h096l:/usr/lib/xwiki/WEB-INF/fonts$

My Typography settings are:

I’ve restarted that box several times since I copied the Roobert font’s files to /fonts folder and set Roobert as our brand font. I don’t remember how many, but several XWiki updates were also completed without any issues.

Please, must we expect that, unrespectfully of its brand or operating system, any client, any remote web browser, get our XWiki contents served using Roobert font?

Thanks!