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:
The picture above belongs to a Firefox window, but the same happens with Chrome, Edge or Opera, for instance.
It’s very probably no. 2. Maybe it would be solved by overriding @font-family-serif in your colortheme I’d advise you to at least try it out so that we can be sure the path to resolution is 2.
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
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!
Yup 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
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 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
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).
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
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:
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:
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.
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.
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!
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)?
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).
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?
/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.
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.
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?
I’d advise you to at least try it out so that we can be sure the path to resolution is 2. 
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 
