@MattLongCT: As you prioritized this task, do you plan to work on it? If so, please set yourself as assignee - thanks!

In T166138#5091156, @Aklapper wrote:

@MattLongCT: As you prioritized this task, do you plan to work on it? If so, please set yourself as assignee - thanks!

I probably shouldn't have prioritized the task. My apologies :X

Let me add to the chorus here: the default on many systems is Comic Sans which is far from ideal. Is this more difficult than simply editing the local MediaWiki.css?

See https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector#Adding_fonts for general information.

Is this more difficult than simply editing the local MediaWiki.css?

@Koavf: You could do that on your self-hosted wiki if all users' personally identifiable information should be passed to some third-party company. :)

What third-party website? Can MediaWiki servers not locally host fonts?

My comment refered to loading data via MediaWiki.css from https://fonts.google.com/specimen/Petit+Formal+Script?selection.family=Petit+Formal+Script (fonts.google.com is a third-party company), as that link is in the task description.
Debian font packages if available could be installed on Wikimedia servers if this is a request about Wikimedia servers (as Wikisource is mentioned).

Change 652684 had a related patch set uploaded (by Inductiveload; owner: Inductiveload):
[mediawiki/extensions/UniversalLanguageSelector@master] Add Petit Formal Script

https://gerrit.wikimedia.org/r/652684

Is it possible to merge this patch?

In T166138#7153134, @Languageseeker wrote:

Is it possible to merge this patch?

Pinging Language-Team per https://www.mediawiki.org/wiki/Wikimedia_Language_engineering/Code_review_statement_of_intent

This seems out of scope for ULS. How does this improve language support? The intention is that ULS does not become generic web fonts provider in MediaWiki.

In T166138#7220936, @Nikerabbit wrote:

The intention is that ULS does not become generic web fonts provider in MediaWiki.

What then would be the component for web fonts in MW?

I don't think such thing exists currently. The issue is that someone has to maintain it and the Language team already has many things to maintain and we have to prioritize carefully to even take care of the existing ones. Hence I was asking whether this falls within our scope of language support.

It does not fall strictly within "language support" in terms of i18n/i10n.

However, the Wikisourcen, by virtue of needing to reproduce formatting used in the books we transcribe, has a need for certain specialty fonts. Most of the time the typeface is a mere stylistic preference or house style of the printer, in which case we don't do any special formatting, but in some cases the typefaces represent either deliberate authorial choice or is otherwise important for accurately conveying the work and needs to be preserved. Formal script and Blackletter being the two most commonly encountered classes, and for Blackletter @santhosh added this for us in T38666 (that's why we have UnifrakturMaguntia in ULS).

If there is no other existing defined component for generic web font support I have trouble envisioning the circumstances under which it would be possible to create one given the existence and function of ULS. Especially since ULS replaced… Extension:WebFonts (which, in fact, was deprecated specifically in favour of ULS).

All such things obviously add to the maintenance burden, and I know the Language Team has more than its share of tasks on its plate (especially lately); but at the end of the day it is the addition of one font, from a stable source that is unlikely to need frequent updates, and there is a patch available in this task that mainly just needs review.

We can and do manage without it, but the… unfortunate… defaults for formal scripts in web browsers has actually led to edit wars onwiki. From our perspective the cost—benefit makes it a nobrainer.

...unfortunate… defaults

For those who do not know the real joke here: it's Comic Sans (yes, really)

Could we add it to the Wikisource extension? If it's definitely of no use to any other project.

We had scaled down the usage of webfonts due to performance issues are outlined in https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts.
We currently use it only for language support and not for typographic styles as this ticket talks about. This is unfortunate, but we had removed several fonts from our repository to help page performance. Webfonts is critical in page rendering and any delay causes page flashes.

For your usecase, I am wondering if the following solution works:

There is https://fontcdn.toolforge.org/ that mirrors Google fonts to solve anonymity issues with Google fonts. Find Petit Formal Script in it, click to get @font-face css. It looks like:

/* latin-ext */
@font-face {
  font-family: 'Petit Formal Script';
  font-style: normal;
  font-weight: 400;
  src: url(https://tools-static.wmflabs.org/fontcdn/s/petitformalscript/v8/B50TF6xQr2TXJBnGOFME6u5OR83oRP5qkHDgPrgZ.woff2) format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

/* latin */
@font-face {
  font-family: 'Petit Formal Script';
  font-style: normal;
  font-weight: 400;
  src: url(https://tools-static.wmflabs.org/fontcdn/s/petitformalscript/v8/B50TF6xQr2TXJBnGOFME6u5OR83oRP5qkH7gPg.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Put this in site specific css (example Mediawiki:Common.css ).

Define a template for using this font whereever need. Define TemplateName/styles.css (require templatestyles extension) and add

.petitformalscript {
 font-family: 'Petit Formal Script', cursive;
}

The template will add a wrapper div or span tag with class petitformalscript. That will invoke the @font-face and font will get download.

Arguably TemplateName/styles.css can have the @font-face instead of common.css but the CSS validator for Templatestyles does not like @font-face syntax and won't pass validation

@santhosh \o/ that totally works: https://en.wikisource.org/wiki/Template:Cursive

You are a hero!

In T166138#7223399, @Inductiveload wrote:

@santhosh \o/ that totally works: https://en.wikisource.org/wiki/Template:Cursive

You are a hero!

We should record the detail locally at enWS and multWS, and also share the solution with the broader Wikisource community.

I was not aware of this concern about fontcdn. I was in the impression that it solves the issues with Google fonts. Thanks @Aklapper.
But there is always an option to have the woff2 file uploaded in commons.wikimedia.org and refer it by URL. I remember seeing that in some wikis.

https://en.wikisource.org/w/index.php?title=MediaWiki:Gadget-Site.css&oldid=11519194

AFAIK Woff(2) cannot be uploaded to Commons.

Perhaps the Wikisource extension could serve this file?

Oops. Can that be solved by filing ticket to support WOFF2 in commons? We are talking about free licensed fonts.

ULS can technically have this font and not mapped to any language and then access the font path like w/extensions/UniversalLanguageSelector/data/fontrepo/fonts/Fontname/Font.woff2 but, we do not want wish to maintain a large collection of fonts in the repository. The project is not designed for that, and language team does not have the capacity too.

requested at T286988

In T166138#7223586, @santhosh wrote:

Oops. Can that be solved by filing ticket to support WOFF2 in commons? We are talking about free licensed fonts.

ULS can technically have this font and not mapped to any language and then access the font path like w/extensions/UniversalLanguageSelector/data/fontrepo/fonts/Fontname/Font.woff2 but, we do not want wish to maintain a large collection of fonts in the repository. The project is not designed for that, and language team does not have the capacity too.

In T166138#7223586, @santhosh wrote:

Can that be solved by filing ticket to support WOFF2 in commons?

That would require a community RFC at Commons, and I am uncertain whether the Commons community would be inclined to expand their scope to include free fonts… partially because they would also need to "support" this, through patrolling, policies, tooling, etc. On Commons it would be fairly open-ended (vs. tightly controlled in ULS), so it would take significant community resources to deal with it.

And it would need software changes to deal with previews (what is the the thumbnail for a font file?) and metadata (cf. EXIF), including possibly a custom renderer for Thumbor and explicit code to support it in Swift. Which all would need ongoing support from SRE.

we do not want wish to maintain a large collection of fonts in the repository. The project is not designed for that, and language team does not have the capacity too.

That's certainly an issue, but at the same time this is one font, and the last request was for a Blackletter font in 2012 (that is: one request every nine years). There are a small number of other probable specialized fonts that might come up (an outline font and a dedicated proofreading font, ala. OpenDyslexic spring to mind), but we're not talking a huge number of them. And ULS/WebFonts does explicitly include this use case, and uses it as part of the rationale for why ULS is needed. It's not something completely novel or exploding the scope of ULS we're requesting.

In T166138#7223493, @santhosh wrote:

I was not aware of this concern about fontcdn. I was in the impression that it solves the issues with Google fonts. Thanks @Aklapper.

The issue there, AIUI, is that Toolforge (and WMCS) is by definition "third-party" (because anyone can set up a tool there), so the privacy policy disallows gadgets or styling talking to anything there the same way it prohibits such talking to google.com or evilhaxors.net.

The same does not apply for services provided in production because those components are under direct control of the WMF, including access controls, security and privacy policies, etc. Which means, one way to solve the issue is to move fontcdn away from Toolforge and into production. Which would solve this and a whole bunch of related problems once and for all.

@zhuyifei1999 @Legoktm Any thoughts?

In T166138#7223790, @Xover wrote:

In T166138#7223586, @santhosh wrote:

Can that be solved by filing ticket to support WOFF2 in commons?

That would require a community RFC at Commons, and I am uncertain whether the Commons community would be inclined to expand their scope to include free fonts… partially because they would also need to "support" this, through patrolling, policies, tooling, etc. On Commons it would be fairly open-ended (vs. tightly controlled in ULS), so it would take significant community resources to deal with it.

I am not certain that this would require a community consensus of Commons. As I remember it, these restrictions have pretty much come from staff over the days. If push comes to shove. let us have the capacity to upload it to English Wikisource and everyone else can go and work out their own requirements, and when they do, then we can migrate it to Commons.

There is precedent for that as donatewiki has font upload enabled in the CommonSettings.php.

In T166138#7223878, @Xover wrote:

In T166138#7223493, @santhosh wrote:

I was not aware of this concern about fontcdn. I was in the impression that it solves the issues with Google fonts. Thanks @Aklapper.

The issue there, AIUI, is that Toolforge (and WMCS) is by definition "third-party" (because anyone can set up a tool there), so the privacy policy disallows gadgets or styling talking to anything there the same way it prohibits such talking to google.com or evilhaxors.net.

The specific issue here is around user-agents. The Wikimedia privacy policy considers UAs to be private information, but 1) your UA is available to the Toolforge maintainer and 2) fontcdn proxies your UA over to Google Fonts. It would be reasonable to make an exception for 1 given that the maintainer in question has signed an NDA, but I don't see how to work around 2, given that Google Fonts varies its response based on your UA.

The same does not apply for services provided in production because those components are under direct control of the WMF, including access controls, security and privacy policies, etc. Which means, one way to solve the issue is to move fontcdn away from Toolforge and into production. Which would solve this and a whole bunch of related problems once and for all.

Moving the fontcdn proxy into production doesn't solve privacy issue #2. Also not a huge fan of being dependent on a third-party service.

It seems to me that we mostly need a place to put web fonts that are not language support related and can't go in ULS. In the past we tried having a dedicated extension per font, (https://www.mediawiki.org/wiki/Extension:MontserratFont) which works but is a lot of overhead if people want other fonts too. Maybe a generic "CoolFonts" extension, that lets us enable specific fonts per wiki.

`wgEnabledCoolFonts' => [
    'default' => [],
    'enwikisource' => [ 'petit-formal-script' => true ],
],

I think such a plan would need buy in from the Performance-Team because of past issues we've had with web fonts and some guidelines on what uses of web fonts we're willing to entertain. E.g. if a web font enabled {{cursive}} made it to the enwp main page, would that be OK?

In T166138#7228181, @Legoktm wrote:

The specific issue here is around user-agents. The Wikimedia privacy policy considers UAs to be private information, but 1) your UA is available to the Toolforge maintainer and 2) fontcdn proxies your UA over to Google Fonts. It would be reasonable to make an exception for 1 given that the maintainer in question has signed an NDA, but I don't see how to work around 2, given that Google Fonts varies its response based on your UA.

Slight correction here: tools-static.wmflabs.org/fontcdn/ and tools-static.wmflabs.org/cdnjs/ are special cased in the toolforge static web server code and are directly proxied to the respective web services (afaik) without leaving any logs to the tool maintainer, so the only people who can see the logs on Toolforge side are roots, who all have signed NDAs by policy. However Google Fonts varies the returned font formats to only contain formats that they deem best for that user-agent, so unfortunately toolforge needs to proxy the UAs to Google.

Maybe a generic "CoolFonts" extension

Also just chucking it into the Wikisource extension and accessing via /w/extensions/Wikisource/data/font/Name.woff2 if making a fully generic extension isn't felt to be a good idea.