As far as I can tell, the internal encoding of a font has no bearing on how Unicode code points are mapped to glyphs, so long as the encoding is properly declared. Back in CJK land we had a "cidmap" for that.

If we're talking about File:SVG_Test_TextAlign.svg: I believe the RTL issue as shown by the KV 15 arabic text is being shown correctly on Commons now. As a result, *if* we get SVG Translate Tool to flip start/end, it will work as expected.

Undone by https://phabricator.wikimedia.org/rOPUP33b0f4f1308bd03d1422f34e23c0ac8794ab86bf because Ubuntu is non-free. Welp, there goes my fancy file (https://commons.wikimedia.org/wiki/File:Avermectins_skeletal.svg). Now to figure out why font fallback to monospace didn't work...

If you propose to change this behavior you can make a proposal and we can change it in the source code unless there are objections from others

New compliant about scientific names getting hidden. Articles on familiar kinds of living things commonly start with something like "Big bush (Bushus biggus) is a big kind of plant"; for Biology reasons people want to keep the parenthetical. Discussion at https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Tree_of_Life#Scientific_name_excised_from_pop-up_preview_-_please%2C_can_it_be_prevented%3F

+1 on this request, mainly because the existing mw-collapsible function is a lot less accessible than this standard thing.

So uh @tstarling, what about the promise of trying to deploy a build script? I've got all the steps laid out...

I didn't say it has to override the existing Media: function. A new pseudo-namespace would work great.

Looks like the "Parser" tag isn't helping, but this really is where the code is located. Pssst... @brion would you please take a look at this? You seem to be familiar with media support.

While most cases of "comma-separator" use are for list of items, the MIME case is unfortunately more like a list of sub-clauses.

Since when do we have MIDI transcode? Well great, that's yet another reason to offer a transcoded link.

Test images with the haphazard build:

A haphazard build of 2.56.0 does not show this issue. See build instructions in https://phabricator.wikimedia.org/T265549#8868748.

Beyond rust version, the dependency issue is mainly pango. Buster has 1.42.3 while librsvg wants 1.46. This bar was raised by two commits upstream:

• https://gitlab.gnome.org/GNOME/librsvg/-/commit/077f21b03b1cc9eebacbbbf6860045f2fcd96768 does 1.38 to 1.44. This is required for the T36947#7062325 bugfix. Okay, it's not that bad. The bug's reappearance was caused by pango's behavior change in 1.44.3, so in 1.42 we will fly fine.
• https://gitlab.gnome.org/GNOME/librsvg/-/commit/19f07cd73556f138d2b53932cb28d0be800626dc does 1.44 to 1.46. This is fine-ish because it's for overline and other fancy SVG2 stuff, which we don't use. Yet.

It's done? Cool. Now to remove these ugly hacks from all the SVGs that have piled up...

In T306246#8008801, @AlexisJazz wrote:

because nobody wants images from the bad image list to show up in search results.

I am… getting impatient enough to ask: how hard is it to, really, just make our own statically-compiled rsvg-convert binary into a deb package and then deploy it? I mean:

The font-family may encode not only the font family, but also the font-style or the font-weight.

For showing the original source on hover, we can maybe instead just display the a trimmed tree down to the base ref (in the beta extends proposal). That is, for:

Bit surprised to see the book-reference / extends system cancelled after all the advertising on Template:rp and such. Ouch. Should’ve went to the vote.

Some scattered suggestions, wishes, and questions.

Subscribing in case someone makes a comment about a bot being made available.

Appreciate the heads-up, but I am pretty sure the very relevant follow-up would be: which version is Debian stale on? The hesitancy of the team to even backport testing/unstable source packages has been a persistent roadblock to us getting good things.

Putting a +1 here because someone on zh.wp telegram group asked for a way to not list navbox-introduced links. I agree that these links don't make sense to be counted and add unnecessary noise to "most wanted" and similar stats.

At least the 2.51.1 result makes more sense and works in non-extreme scales...

Every time I hear a librsvg bug, I can't help but ask: "is it a Debian stable librsvg bug or an actual librsvg bug?" (urgh) And indeed, a quick test using rsvg-convert from libsrvg 2.50 shows the red and black text on the last line overlapping fine.

In T50032#6979865, @Physikerwelt wrote:

Package inputenc Error: Unicode character 甲 (U+7532)(inputenc) not set up for use with LaTeX. $\sin(甲

FWIW, it seems that texvcjs, not MathJax, is the one blocking the characters from mathoid. The problem is in turn thrown from pegjs.

For those curious about KaTeX, you can use it with the JS below, either in common.js or from a brower userscript:

This issue also affects wikis using a black background by default, which is... a lot of video game wikis. Let me describe the T279181 issue in more detail:

I agree that it's a dupe of T111222. I think it's invalid status... right?

Heredoc looks nice for its consistency and general-ness, but I do hope we come up with something for LISTGAP. The definition-list is still a very bad idea, but then we can also just use ** <<< now.

Agree with the Quiddity bold suggestion. The "indent" name is very unfortunate.

Converted the additional observation to notes. Did some reading in the source, and I think it's could be a librsvg bug or a misconfiguration. Either way, this can be worked around in the environment.

1. The rasterize() part of SvgHandler.php seems to set LANG only when there is one. That makes sense.
2. librsvg falls back to LC_MESSAGES then LC_ALL [[https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.40.21/rsvg-cond.c#L145 |when there is no LANG]]. That is not really a bug.
3. librsvg falls back to en when the locale [[https://gitlab.gnome.org/GNOME/librsvg/-/blob/2.40.21/rsvg-cond.c#L148 |is exactly "C"]]. This is very not good. And it's fixed in their Rust version because they used a locale_config crate that doesn't do this.

okay, editing the bug now.

I disagree with the merge. This report is related but not identical, since the SVG Tool is not part of MW proper. Instead there should just be a reference to each other.

Appears to be affecting the example presentation of multilingual images on a Commons template. See https://commons.wikimedia.org/wiki/Template_talk:Translate#New_Template%3A_Multilingual_Gallery.

I would recommend a post-processing for PNG thumbs by way of color reduction to 256. This usually gives a very signification reduction in file size at little cost to quality for drawing and text content. In ImageMagick, this is done by prefixing the output file name with PNG8:. Their handling of transparency is not good, but documents don't have that issue.

Yes, make this task about -sharpen on JPEG then. Editing.

Currently the enabling/disabling of the availability of language converter is made across the entire wiki, however it might not always suit every needs.

The autoprefixer thing using caniuse looks good. -webkit-text-emphasis is especially a pain in the alias for Chinese/Japanese, as 71% of global users only get support via this prefixed version. Chrome, ya know.

I made a quite mention to Ctrl-F'ing the source for $props in https://www.mediawiki.org/wiki/Help:TemplateStyles#What_CSS_rules_are_recognized?, so folks can at least know how to find a list.

By the way, is the IPSet ($proxyListIPSet) always created anew when User::isLocallyBlockedProxy is called? I am not sure what to make of that...