Hi @Verdy_p, please read https://www.mediawiki.org/wiki/How_to_report_a_bug and include a full link to a web address where the issue can be seen.

See https://upload.wikimedia.org/wikipedia/commons/archive/2/23/20201226141533%21Wikifunctions_wordmark.svg

This is a VERY basic SVG containing a single text element (there is an additional part commented out showing the bounding rectangle for correctly positioning the text and centering exactly in the defined width and height 160x20px where there should be enough horozontal padding, the text should fit cleanly inside the vertical area, and should be centered exactly even if alternate fonts are used)

(this is rendered by the browser, but the thumbnail is visible in the history for that same date)

https://commons.wikimedia.org/wiki/File:Wikifunctions_wordmark.svg (the version on 26 December 2020, 15:15)

I had to fix it using only capitals instead.

Note that this also causes incorrect centering (because of incorrect metrics computed, based on metrics of smallcaps, even if the smallcaps glyphs are NOT selected and properly positioned in the string, but this may also be caused buy the fact this was initially designed an a "Montserrat" font not supported for now, and the renderer uses a fallback font, which may not have the smallcaps glyphs, but which should still be used with the correct metrics for lowercase, if the renderer cannot synthetize smallcaps by reducing capitals vertically from M-height to x-height and uses only the lowercase letters mapped in the fallback font).

I don't know if smallcaps are really working if the specified font is available. But definitely it does not work with the default fallback font.

@Verdy_p: Are you willing to follow https://www.mediawiki.org/wiki/How_to_report_a_bug and structure your bug reports?

Steps to reproduce:

1. Look at the SVG file https://upload.wikimedia.org/wikipedia/commons/archive/2/23/20201226141533%21Wikifunctions_wordmark.svg (that's "14:09, 26 December 2020" under "File history" on https://commons.wikimedia.org/wiki/File:Wikifunctions_wordmark.svg )
2. Look at the corresponding PNG thumbnail for that SVG file.

Expected outcome:
The PNG thumbnail looks like SVG; All letters are upper case; all letters except for first letter have less height than the first letter
Actual outcome:
In the PNG thumbnail, all letters except for first letter are lower case

I can confirm this with the latest stable librsvg2-2.50.2 with the SVG file itself (no PNG thumbnail involved), so this looks like an librsvg2 Upstream issue:

Upstreamed as https://gitlab.gnome.org/GNOME/librsvg/-/issues/668

Dans T270836#6715613, @Aklapper a écrit :

Steps to reproduce:

1. Look at the SVG file https://upload.wikimedia.org/wikipedia/commons/archive/2/23/20201226141533%21Wikifunctions_wordmark.svg (that's "14:09, 26 December 2020" under "File history" on https://commons.wikimedia.org/wiki/File:Wikifunctions_wordmark.svg )
2. Look at the corresponding PNG thumbnail for that SVG file.

Expected outcome:
The PNG thumbnail looks like SVG; All letters are upper case; all letters except for first letter have less height than the first letter

Actually, "smallcaps" are *not just* "reduced capitals", but capitals whose metrics are adjusted vertically only so their height matches the lowercase letters, i.e. x-height instead of M-height. Reducing the font-size does not work well, as it also reduces too much the width and advance gaps; stretching the glyph vertically also does not work well as it also reduces the weight of horizontal strokes. Smallcaps are distinct glyphs with their own metrics.

Actual outcome:
In the PNG thumbnail, all letters except for first letter are lower case

I can confirm this with the latest stable librsvg2-2.50.2 with the SVG file itself (no PNG thumbnail involved), so this looks like an librsvg2

Upstreamed as https://gitlab.gnome.org/GNOME/librsvg/-/issues/668

Dans T270836#6715595, @Aklapper a écrit :

@Verdy_p: Are you willing to follow https://www.mediawiki.org/wiki/How_to_report_a_bug and structure your bug reports?

Yes but my initial comment was enough. You asked for more precision, and I gave them. It was structured as needed, and my reply gave a very basic example limited to jsut a single text using smallcaps (note that there's already been several attempts to make it work, until the wordwark was finally all capitalized).

According to the Gnome project, this has to go fgurther upstream into a bug of Pango.
See also https://github.com/Automattic/node-canvas/issues/894 (submitted in 2017)
Apparently, Pango does not use these styles, you need to enable the "smcp" OpenType feature (which is disabled by default of course but should be enabled with these CSS styles). Enabling an individual Opentype feature is possible with some SVG rendererers using a "labs" CSS property (still not part of the SVG or HTML5 standard, so with custom prefixes for CSS properties)

In T270836#6726228, @Verdy_p wrote:

According to the Gnome project, this has to go fgurther upstream into a bug of Pango.

Where does "the GNOME project" say so?

In T270836#6727649, @Aklapper wrote:

In T270836#6726228, @Verdy_p wrote:

According to the Gnome project, this has to go fgurther upstream into a bug of Pango.

Where does "the GNOME project" say so?

At https://gitlab.gnome.org/GNOME/librsvg/-/issues/668 :

"We pass PangoVariant::SmallCaps to pango... I fear small caps is not implemented in pango itself"

the "Unicode small caps block" is clearly not a solution. Small capitals are a generic styles that must cover complete scripts, and not the reduced subset encoded in Unicode only for compatibility, or because there are a few languages/orthographies that use them as ifd they were *different* base letters of the alphabet, or for specific notations.
For example there's not enough latin letters to cover French in that block. And your proposal based on "Wɪᴋɪғᴜɴᴄᴛɪᴏɴs" is not correct (this is not even encoding an "F" letter).

So we still need support for small capitals (which are a standard style feature in both CSS and in OpenType). This style works in SVG renderers implemetned in web browsers, or in most common SVG editors, but still not only in the SVG renderer used by Wikimedia wikis and does not require using the encoded compatiblity block or changing the encoding (and breaking the orthographies like you did).

So for now the only correct workaround is to replace small letters by capitals (but then reduce their font-height, and possibly increase their font-weight), or to use other SVG editors and replace the smallcaps text by their generated glyph paths

But then we loose the possibility of internationalizing the text easily by just adding another text string, and using language selectors inside the SVG for locale-sensitive rendering in a unified multilingual SVG. Small caps are needed in common situations, notably for titling, or for rendering maps (where we need visual distinction of labels, e.g. between country names and city names).

This should be fixed in librsvg >=2.57.1 and harfbuzz >=8.3.0, per https://gitlab.gnome.org/GNOME/librsvg/-/issues/1019 (and previous https://gitlab.gnome.org/GNOME/librsvg/-/commit/e9db53c710d22ccce8d03808e9ca3897205cb6a5)