Add a webfont version of Source Sans Pro font

Thanks, adding tags.

I also want to add that this font is an integral part of our proposed new styling. Although not including it, is the easy road - we would like to press for this to be included given that it will modernize and elevate our styling

Updated issue summary.

From the preamble of the OFL web version:

The fonts and derivatives, however, cannot be released under any other type of license.

This is our roadblock, the Drupal.org policy requires that anything checked into git is licensed as GPL. Unless we make an exception for font files, we can't include them.

The license goes on to say that embedding the font into documents does not require the document to be licensed under OFL. This does mean we could download the font from an external server. I won't go into the details of that implementation until we are agreed on the above.

Yes, those are the options as far as I understand them: get an exception, or figure out a separate loading strategy.

Added clarification

Used Google Webfonts to get Source Sans Pro, so the font files will not be added to Drupal.

I created an additional file with the CSS file that is created by Google, so the file can be aggregated.

I applied this patch and it worked well. My only possible issue is that the admin website font will have a dependency on being connected to the internet and to google services. If you are all good with that, it will work out, if not, then someone needs to make the ultimate decision regarding this.

Actually I rerolled the patch because the original one was uploaded via Windows and had some issues being applied.

ug ignore that, that is 0kb.. one sec

Actually the original file and my new one are the same.. but I'm going to upload my rerolled one just in case it removed any windows'ness.

@mcpuddin Just explaining some general community guidelines here, we mark this RTBC when a number of contributors agree that this is a good direction and have looked at the code. Its common not to mark your own patches RTBC.

@Bojhan, this was not my patch but rather someone at the code sprint. I simply re-rolled his patch that seemed to work well except there was a windows newline error. Correct me if I'm wrong, but I was under the impression that someone marks RTBC once someone reviews it and validates it. Or do I just need more clout or to work on issues that seem to be a little more decision-worthy?

@mcpuddin True, however this is a big change it could benefit from more discussion.

The bigger issue here is whether committers are OK with relying on a third-party service for the typeface used in the default admin UI. I’m the one who proposed the typeface and I am not sure I’m comfortable with it. We simply need an answer from committers if they are willing to include the font files in the source (preferable, but unlikely) or if they are OK with relying on a service.

In the patches, I notice a couple of things:
- The fonts are being pulled from 'themes.googleusercontent.com'. What is this? There is no site there; is it the font store for Google Web Fonts? Is the URL reliable?
- The patch only pulls woff versions. Now that we’ve dropped IE8 support, that covers everything but Android. We should decide if we want to serve webfonts to mobile browsers. Maybe we don’t (for speed). If we do, we should include a TTF version for Android.

At this point I’m going to come out and say that I think we should either bundle the font files with core or stick with Lucida. I don’t like facing that, but at this point we need a decision, and I just don’t want to even go down the road of relying on third parties for a core aspect of Drupal’s appearance.

This would be a good point to defer to the DA legal counsel or ask the author for a new license. Crell used to be the legal liaison for the DA, and I know he's knowledgeable about licensing issues, however, I imagine he's pretty busy at the moment preparing for July 1. Is there a process for submitting issues like this to the DA legal counsel?

If we can bundle Source Sans Pro with core, that'd be ideal. If not, I would not be comfortable with using the Google Fonts API by default. Relying on third party services for core seems like a bad path to go down.

If Source Sans Pro isn't an option, are there any other free fonts that we could consider? Is Lucida Sans available on all platforms?

@cweagans I second that. Unfortunately I don’t know what processes exist around legal counsel.

If we can’t use Source Sans, we can stick with Lucida. Windows has Lucida Sans, Macs often have Sans but if not, Lucida Grande. We can do our best picking a fallback on Linux if system fonts have changed since D7.

We could relicense to GPL3 and use Open Sans or Droid Sans, though I suspect that'd be much more work than designing our own font =P

IANAL, but couldn't we just not relicense the font files as GPL2? That seems to sidestep the problem entirely, especially since SIL's FAQ says that it's okay. That is, the problem is that we take the stance that everything that goes into Git is going to be relicensed as GPL2. If we make an exception for the font files, then I *think* we'd be okay. Like I said, though, IANAL.

@cweagans Oh man, if we can simply relicense then we’re fine. I remember reading the SIL FAQ and I did not think it was possible. Sounds like we /really/ just need someone with legal expertise to take a look.

So, I wrote the original patch and I have a few comments (mainly replying to @ry5n, comment #13).

1. I'd actually agree that bundling Source Sans in core would be preferable to using a font provider. But since I can't do anything about licensing I provided a patch for an alternative approach if people decide that's an acceptable solution.

2. The fonts.css file is the CSS generated by using Google Webfonts URL (http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,600,700,400it...). I copied the code to a new file rather than linking to Google's external stylesheet so that the code could be compressed and aggregated with the other CSS files, avoiding an extra HTTP request.

We can not release the fonts under any other license, the SIL OFL explicitly forbids it:

5) The Font Software, modified or unmodified, in part or in whole,
must be distributed entirely under this license, and must not be
distributed under any other license. The requirement for fonts to
remain under this license does not apply to any document created
using the Font Software.

GPL3 may be compatible, but OFL is not.

I understand. The other fonts that I mentioned are released under the Apache 2 license, and are therefore compatible with GPL3.

For Source Sans Pro, we'd either have to get a special license just for use in Drupal, or bundle the font and NOT include it in our blanket GPL2 license that we apply to all files in Git.

If Open Sans has a more compatible license, I think it's a good choice. It's also more complete than Source Sans (more Unicode characters) and also has a 'Condensed' family, making for a really nice combination when using that for headers.

I’ve asked a couple of times in IRC #drupal-contribute who I should talk to to reaolve these licensing issues (whether Source Sans or another font), with no response. Can someone point me to an authority that can help resolve this? We need a clear-cut answer now or this should be postponed to D9.

I talked to Crell about this:

[09:29:43] I was wondering if you could point me toward whoever is the POC for legal questions. They're blocked on https://drupal.org/node/1986082#comment-7492484 solely on licensing issues, and I'd love to get them in touch with the right people.
[09:32:16] Ugh.
[09:32:23] I don't think there is an official point person at the moment.
[09:33:53] Would it be worthwhile to just send an email to the contact address for the DA and see where it gets routed? Or would Holly know?
[09:37:20] hm.
[09:38:41] Well... At the moment the DA isn't Final Word(tm) in this case. Webmasters would be.
[09:38:51] Because it's non-GPL, we can't put it in the repo without an exception.
[09:39:10] Since it's not GPL-compatible (the way Symfony or jQuery are), an exception is extremely unlikely.
[09:39:28] Everything coming out of or repos is GPL or GPL-compatible.
[09:39:39] Right. Most of our legal issues right now are around that blanket relicensing policy.
[09:39:51] In fact, I think all of them are (all three)
[09:40:53] Okay. I'll update that issue and see what we can do.
[09:40:55] Thanks :)
[09:41:23] So, yeah, I don't think we can use that font, for Drupal reasons not lawyer reasons.

So it sounds like we should:

1) Open an issue with webmasters ASAP (done: #2010902: Asking for exception so that Source Sans Pro font can be added to core)
2) Open an issue with webmasters to establish official POC/process for these legal questions (done: #2010906: Establish official process and/or POC for legal questions)
3) Probably come up with a plan B for this issue, since it's unlikely that #2010902: Asking for exception so that Source Sans Pro font can be added to core is going to pan out in our favor

I've sent an email to Paul Hunt (the creator of the font) to see if we can talk to him about how best to bundle his font with Drupal. Hopefully, he will talk to us here, or if I get an email back from him, I'll keep you guys posted.

Awesome. We did the same with Lato for Ember but unfortunately the designer was unwilling. There's nothing legally wrong with maintaining two versions of the (visually) same font under two different licences (in this case OFL and GPLV2).

meta issue added

#8: 1986082-source-sans-font-8.patch queued for re-testing.

@Gaelan What does this patch do?

It gets the font from Google Web Fonts. It is not my patch.

I am thinking that a licensing exception is not going to happen in time for feature freeze. In the interest of time, I think we should do one of these two things:

1) Use the web font - I've been thinking about this, and this could possibly be okay if it's either off by default or easily disableable. We could also download the font once from Google and cache it in the files directory at install time.
2) Pick a different font that doesn't conflict with our licensing policy

We might consider doing both of these things, and using the font chosen in #2 as a fallback in the event that the site admin turns off the web font option.

Also, if we're going to use the web font, we need approval from Dries, I think. That sounds like a product decision.

@cweagans

1) Use the web font - I've been thinking about this, and this could possibly be okay if it's either off by default or easily disableable. We could also download the font once from Google and cache it in the files directory at install time.
2) Pick a different font that doesn't conflict with our licensing policy

The only problem with 1 is that if Google changes anything about the font (file names etc.) the @font-face CSS that references it could become out of sync. Apart from that it sounds like a good idea.

On 2, we did an extensive search for GPL fonts and there is nothing of sufficient quality available. GPL is just not the standard for font licensing. The standard for open fonts is OFL and unless Drupal accepts the font exception fonts that ship with core will continue to be anemic (which is why I really like the approach in 1)

Also, if we're going to use the web font, we need approval from Dries, I think. That sounds like a product decision.

Dries has reviewed the seven style guide and AFAIK voiced no objection to the font.

The only problem with 1 is that if Google changes anything about the font (file names etc.) the @font-face CSS that references it could become out of sync. Apart from that it sounds like a good idea.

Yeah. But the only thing that would affect is the typeface. I realize that's kind of a big deal from a design standpoint, but it wouldn't disable anyones site as long as there was a web-safe fallback. Also, if we download and cache the font files locally in the site's files directory, this becomes not as big of an issue.

On 2, we did an extensive search for GPL fonts and there is nothing of sufficient quality available. GPL is just not the standard for font licensing. The standard for open fonts is OFL and unless Drupal accepts the font exception fonts that ship with core will continue to be anemic (which is why I really like the approach in 1)

I think an exception for including the license directly is not going to happen with the current licensing policy. OFL is not GPL compatible in any sense. In order to do this, we'd need some clear process for adjusting the licensing policy, as well as a review by the DAs legal counsel, and there's simply not enough time to do all of that.

Dries has reviewed the seven style guide and AFAIK voiced no objection to the font.

I'm not talking about the choice of font. I think pretty much everyone can agree it's a good font. I'm talking about pulling the font in from the Google Fonts API. That's kind of a big deal.

Yeah. But the only thing that would affect is the typeface. I realize that's kind of a big deal from a design standpoint, but it wouldn't disable anyones site as long as there was a web-safe fallback. Also, if we download and cache the font files locally in the site's files directory, this becomes not as big of an issue.

Agreed, if the font fails to load it should not be noticeable to the user. If Google does change their API, we can always update our implementation in a minor version.

Can somebody please assign this to Dries for feedback? Specifically looking for advisory on whether or not we can pull the font in through Google Web Fonts.

Dries, I believe your options are:

1) "It's OK to have a font in the core repo that is not GPL-compatible."

2) "It's OK to have a default font that gets pulled from a 3rd party server (Google)".

3) "Neither of those are OK, let's try something else."

I'm going to rule out option (2).

At first glance, I'm not all that thrilled about shipping a font with Drupal; it seems like it may have both performance and licensing issues. I think we can overcome the licensing issue by talking to a lawyer about this. However, I'd love for us to discuss the performance implications of this (on mobile browsers). It looks like we may have to download 4 additional files to get a custom font.

I'd also love to see a better 'before and after' of an admin page with and without the font. This will help us better understand the implication of option (3). The image in https://groups.drupal.org/node/283223#Typography looks nice but blurry and doesn't really help us understand the 'before and after'. Would it be much work to create this?

Thanks! :)

@Dries

There's a new js library by google and typekit that comprehensively handles many @font-face issues across different services as well as local fonts and offers asynchronous loading and character subsetting to improve performance.

https://github.com/typekit/webfontloader

Following up on #38, can someone expand the issue summary to provide more reasoning on how Source Sans Pro would improve UX or whatever other benefit it will bring? The only thing it currently says (unless I missed something) is:

Source Sans is arguably even better in this respect, with glyphs such as lowercase L and upper/lower I all easily distinguishable from one another, even at small sizes.

We'll need to weight whatever benefits are claimed against the performance cost (#39 might help lower that cost, but not to 0) and the effort involved in clearing #37.1 with legal. Per #38, before and after screenshots that demonstrate the claimed benefits would be helpful.

Unassigning from Dries until the summary is updated per #40.

@effulgentsia

There are definitely usability and legibility benefits to using Source Sans but to me the biggest benefit is a polished and professional administrative theme. Typography is the soul of design and generic, broadly available fonts simple do not have the flexibility and elegance of well crafted contemporary web fonts with multiple weights (particularly lighter weights).
If we truly care about Drupal becoming a center of great design as well as usability there is no issue more important than this one.

Here are some screenshots of Drupal using Source Sans Pro font for visual testing purposes. The first two images are current Drupal.

We'll need tools like acquia dev desktop or even drush to install the font on user's systems so that people won't have to dl it all the time.

I think in places like the right column of the node add/edit, it is much much worse.

There is only a negligible improvement in non-bold text.

And at what technical expense? (That's rhetorical.)

The screenshots in #43 are not correct representations of the typographyproposed in the styleguide. There are tweaks to font sizes, line heights, and letter spacing to accommodate the new font. Simply swapping out the two fonts, while keeping the styling optimised for Lucida Grande is going to portray Source Sans in a very unflattering light.

I hope to be able to work on a more complete comparison this week. I don't think simply holding up two screenshots is enough of a demonstration, I don't expect developers to have to same eyes as typographers.

I don't expect developers to have to same eyes as typographers.

GFY, you don't know me.

@andymartha

Lewis is right. Each font has has it's own optimal visual sizing and spacing and to judge them fairly we need to see a true visual comparison using CSS from the styleguide. Also your second screenshot shows Times, not Lucida. Not sure why.

@tim.plunkett

Looks to me like the right column of node edit is taking "Source Sans Pro" and "forcing" it bold (applying an outline) rather than referencing the font: "Source Sans Pro Bold" which would be much more legible and properly hinted.

I would like to second the motion that this is not how the final Drupal would look with new font, it was just an attempt to give mention to effulgentsia's request in #40 with a font-swap.

I would like to second the motion that this is not how the final Drupal would look with new font, it was just an attempt to give mention to effulgentsia's request in #40 with a font-swap.

GFY, you don't know me.

I don't remember mentioning you by name... Maybe I should clarify what I meant anyway: in the same way it is a skill to read and understand code, it is also a skill to read and understand the nuances and subtleties of a typeface. It's a skill that is developed over time. We shouldn't expect everyone who is part of this issue to have that skill.

It remains an incredible pretentious and condescending thing to say.
This is the second time in one of these styleguide issues I've seen self-proclaimed "designers" telling people they assume are "just developers" that they are somehow inadequate. It needs to stop.

Ok, I can see that. I should of phrased it differently. Let's not go on about it here, if you want to talk more about what I should of said I'm on IRC most of the day.

On the issue, I still think it's helpful to point out some of the details just so everyone can form an opinion with all the information and reasoning that went into the original decision, if not more. If some people don't need things pointed out to them then I guess that feels patronising. I'm not trying to be patronising, I'm trying to be helpful.

Once I switched in Source Sans into HEAD I realised there a load of design tweaks that need to be made to get Source Sans comfortable, as the new style guide designs were made with it in mind and the current state of D8 is not.

I quickly spoke to Bojhan and yory on IRC and they agree the best way to show comparisons is to introduce Lucida into the style guide designs instead. I'll be working on a Lucida branch of the Seventy Eight sandbox. #2067057: Create a Lucida Grande variant of the style guide

@tim.plunkett @LewisNyman

Now now. Let's simmer down.

Tim, I don't think Lewis' intent was to suggest that developers are visual morons. In fact, carefully read, you'll see the intent was:

"A few screenshots are an insufficiently detailed and in-depth study in the fine details of typography that we (designers) make the differences between these fonts important enough for this to be committed to core. I don't expect all developers to be aware of those fine details, therefore i will provide a more lengthy and informative comparison."

I don't think there's anything offensive there.

I know Dries asked for a better before/after example, but he also indicated that shipping a non-GPL font is not the best option. Before we spend much more time trying to demonstrate why Source Sans Pro is such a good font, are there really *no* GPL-friendly fonts that look good/professional? We may not have Source Sans available, but I can't believe there's no GPL-friendly fonts out there that wouldn't get approving nods from typography geeks.

@Crell

That would be great, I'd encourage anyone to take a look. Here's a great article on good UI typography. Source Sans was chosen for reasons included in that article and the letter forms represent the Seven visual principles a bit better (I'm working on a more detailed explanation).

Our three troublesome thresholds for quality fonts are:
1. Free
2. Open source
3. GPL compatible

Quality free/open source fonts are available but finding one that is GPL compatible is really hard because SIL OFL is popular.

Mozilla recently announced Fira Sans, a new UI typeface for FireFox OS designed by the awesome Erik Spiekermann. It will come in several weights with matching italics. At-a-glance, it looks excellent (as you would expect). But – as usual – we can’t use it, because it is Apache licensed, which is not GPL v2 compatible.

At this point we should abandon any efforts to use a more readable (and more beautiful) typeface for Drupal 8 and stick with specifying system versions of Lucida (Lucida Sans/Grande). There are very real performance considerations that would need to be throughly explored and shown not to cause regressions, even without the licensing challenges. Add in the licensing issue and the prospect becomes untenable.

@Crell

but I can't believe there's no GPL-friendly fonts out there that wouldn't get approving nods from typography geeks.

Unfortunately that is precisely the case. All of the (very small number of) fonts that are GPL fail to meet my approving nod, or that of any other designer I know.

The licensing issue is what's keeping us from being able to use icon fonts like Font Awesome. The creator of that would be happy to work with us on the icons but not about the licensing, as he feels the SIL is more permissive/less restrictive than GPL.

The advantage in using the web font is that it's the only way to present something uniform across mobile and desktop platforms. iOS may have Lucida but Android does not - so at the very least whatever we decide has to be tested pretty extensively to look at UI control rendering with different typefaces being loaded. Not a deal breaker, but it does hurt the consistency across platforms.

Is it possible to get clarification on why SIL is not acceptable? (from legal) If we could get past that we could include icon fonts and a very good web font and have a well-polished UI to present that could be entirely resolution-independent.

Performance considerations are pretty negligible when fonts are included properly: only the font file that is usable by that browser would be downloaded, not all 4 formats - and font files when served locally like that (from the host site) are cached - so no repeat downloads page-to-page.

I don't think the font has to be GPL-compatible. At the end of the day, this is a trade-off between keeping it simple (limit everything to the GPL or GPL-compatible licenses) and giving the community more creative freedom (allow non-GPL compatible projects to be used where possible). Technically, it is sufficient for the font to be an Open Source / Free font as there is no 'binding' or 'shared memory space' issues, although it may require some changes to drupal.org policies and/or packaging scripts. The packaging scripts are responsible for adding the GPL license to all projects, including core. I think these changes are limited to clarifying that "stand-alone assets" (insert correct legal term) like fonts are not necessarily GPL-compatible and that they are bound by their own license(s). This is probably something for the Technical Working Group to evaluate and discuss.

Given Dries comment above It seems that, pending the Technical Working Group evaluation, fonts under other open-source licenses like SIL will be allowed in core.
And if, as jpamental (and others including Paul Irish) have said, performance is not an issue, then the only remaining question is whether Source Sans is the appropriate font.
The UX group has already approved Source Sans but I think that decision was partially driven by a mistaken belief that Source Sans was GPL. Given that Dries has said that the only restriction is that the font be open source there are several others that might be as good or better (such as Fire sans suggested by ry5n above in #58).
Maybe we can toss this around in UX happy hour on Monday and come up with a recommendation.

Kevin: Don't count your fonts before they're committed. :-) What Dries is suggesting is changing the current "every line of code in a d.o repository is GPL or GPL-inbound-compatible" policy; working out where and when and how it's appropriate to make exceptions to that is likely not a short-and-sweet task, and I'd actually be rather worried if it happens quickly as that means it may not have been fully thought-through.

(FTR, I have no opinion on Source Sans itself vs. any particular other font; I freely admit to having no eye for fonts whatsoever. I'm just cautioning that the policy/legal implications of that change are non-trivial, even if they do end up being an acceptable net-win.)

@Crell

Well, ok. I understand that there are still bureaucratic hurdles, but the fact that Dries supports this in principle is important.

As to legal ramifications, we're actually the last to get on this bandwagon. The "font exception" language for GPL has been in use since 2005: http://en.wikipedia.org/wiki/GPL_font_exception

Updated issue summary.

What are the hurdles we need to jump to get progress on the licensing issues?

I don't know if this is still going to happen but I have one thought on this.

Webfonts are great but they need multilingual support. The chosen font would need to have as wide language specific characters. This of course results quickly in big file size. Maybe it would be possible to include just the needed subset of characters depending on current site language?
For example there is a beta option on Google fonts to include not by subset but by single characters like this:

http://fonts.googleapis.com/css?family=Inconsolata&text=ążćęńłóĄŻĆĘŃŁÓ

We still need an issue summary update if we are going to move forward on this. I'll speak to Bojhan and Roy this week.

FYI: There is already a discussion about revising Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL: #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL.

For an even broader perspective, search for the tag licensingpolicy.

I find it encouraging that Dries (see #38 and #61 above) does not rule out having a font in the core repo that is not GPL-compatible.

The first item in the issue summary says:

1. Figure out if we can, license-wise.

The answer to that is a clear "Yes".

Compare the following language from GPLv2:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. (my emphasis)

with the following from SIL OFL FAQ:

Fonts licensed under the OFL can be freely included alongside other software under FLOSS (Free/Libre and Open Source Software) licenses. Since fonts are typically aggregated with, not merged into, existing software, there is little need to be concerned about incompatibility with existing software licenses. (my emphasis)

Both says the same thing: mere aggregates does not have to be under the scope of GPL. It is OK to have an aggregated asset under a non-GPL compatible permissive license in a repo where all the code is strictly under GPL.

In other words, the only thing that blocks this from moving forward is our own policy, which currently says that everything must be under GPL (and IMNSHO GPL is a horrible license for fonts).

This means we could always grant ourselves an exception from this policy.

However, I personally believe this policy should be changed to also allow contributions hosted on Drupal.org to contains fonts, icons and images as long as these are included as 1) mere aggregates and; 2) an exception is granted.

I have some experience implementing Source Sans Pro on a multi-lingual site. This font is great for western languages and most recently the 2.010 version just got support for Cyrillic and Greek, which makes this font super promising, since it now has support for Central European languages using the "latin-extended" option from Google fonts for languages like Czech, Hungarian, Polish, Slovak, Serbian, and Turkish. Even Vietnamese has a separate option but is also supported. The main issue I encountered was maintaining look and feel across into languages that the font doesn't support -- particularly when the light weight of the font is used (such as in headings).

If the exception were not to be granted for Source Sans Pro, then perhaps a good fallback would be Open Sans which I believe has even wider language support, and a really good looking light weight very similar to Source Sans.

Update: so Open Sans is Apache 2, and not compatible with Drupal's GPL v2 either.

After discussion with Lewis and Bojhan. This is being moved to 8.1, it is an improvement that can still go in without affecting interfaces much if any. However we do not wish to spend our time on it for 8.x development.

Guys can we have an update on this issue?

I have a personal opinion on using third-party services for font deliveries. I do some sites in which most of the admin part is controlled by people in China, so Google Services of course are NOT available in there, so I don't think is a good way to go.

vulcanr wrote

Guys can we have an update on this issue?

OK - here is my version (if any other member of the LWG is monitoring this issue queue feel free correct/supplement):

In December 2014, the Drupal Association set up the Licensing Working Group (LWG) to sort out this and similar licensing issues. I volunteered to join the group and was accepted.

We consulted with several relevant parties, including the FSF, and around May 2015, we concluded that there was nothing in the GPL or in copyright law that prevents us having Open Sans or any other font with a "GPL-friendly license" in our repo.

However, the Drupal Association has a Drupal Git Repository Usage policy. It has this to say about what is allowed in the repo:

All files checked into the repository (code and assets) must be licensed under GNU/GPL version 2 and later.

This policy prevents most fonts from being in our repo, as the GPL is not a suitable license for fonts.

To fix this, the LWG prepared an slightly amended version of the license, which was posted on GitHub nine months ago. The amended version says that all PHP code committed to Drupal.org's git repository is licensed as GPLv2 and later, but allows other assets such as fonts, to make do with "GPL-friendly" licenses.

All that is required for this to moving forward, is that the Drupal Association reviews and (hopefully) adopts the policy changes proposed by the LWG.

I've no idea when this will happen. Maybe the chair of the LWG, who is the person responsible for coordinating this with the Drupal Association, can add information about when the Drupal Association has scheduled to review the proposal?

@gisle

That's great news! I'm looking in to when that will be reviewed.

That's great news! I'm looking in to when that will be reviewed.

Don't hold your breath, tkoleary. It was ready in January, so this clearly is not a top priority for the DA.

@gisle

:) Well let's hope. I've done what I can to escalate.

I am happy to report that the Git Repo policy has changed #2139273: Allow GPL Friendly Font Licenses to allow 3rd party fonts (and other non-code assets), and that an exception regarding this font has been granted #2010902: Asking for exception so that Source Sans Pro font can be added to core.

Wow! Those are "good news" then, we should be expecting an update on this soon :)

Not sure if we want to still proceed this. IMHO this is a low hanging fruit that would make Seven look significantly fresher.

I rolled a patch so that more people can test how this would look like. I made few changes including changing the base font size from 13px to 16px to match the original style guide. There's probably more to do, but this should be enough for getting some initial impressions.

I think it would be a really low load if we use system fonts, but then we will not have a cross-device unified/standard font. I'm not sure, actually, IMHO I don't know if anyone likes Windows/Linux system font (being really honest)

I found that an interesting idea! However, given that we are planning to create refreshed style guide of Seven, I'm not sure how much does it make sense to make changes to the existing style guide. Would it make sense to consider that for the new admin theme?

IMHO I think that 'performance' wise and 'load speed' makes sense, but look&feel wise I'm still not sure.

There's one more problem that I can still think of; currently the webfont is loaded only on Seven theme. Toolbar uses the same font but doesn't depend on a webfont. If we'd commit this, some users would see different font on toolbar depending on the theme that is used on the page.

Proposed solution for this: add a theme setting from toolbar which would allow configuring whether they want the webfont to be loaded on the theme. That would give the flexibility for the users to choose if they want to load the webfont on their theme or not.

Attached license information for the library and made the ResolvedLibraryDefinitionsFilesMatchTest ignore external libraries.

Increase font size in the Views UI.

This issue is also working with fonts #2943657: Embedding only needed weights for Open Sans and Scope One.

In there we're specifying weights because to this comment. Maybe it'd make sense to load them here too to not force italic and bold.

So maybe instead of:
https://fonts.googleapis.com/css?family=Source+Sans+Pro': { type: external, minified: true }

We could use something like:
https://fonts.googleapis.com/css?family=Source+Sans+Pro:400,400i,700,700i': { type: external, minified: true }

Here is the updated patch with interdiff as per the comment mentioned in #95

I did a quick search for the font-weights used in Seven and it seems like we have few instances of 600 and a single instance of 900.

As per #38 we should be downloading a local copy of the font instead of using Google Cloud. This is possible given that the Drupal.org licensing policy has been changed: #2010902: Asking for exception so that Source Sans Pro font can be added to core.

Also, we should research how are we going to support other languages.

@lauriii I agree about using a local copy of the fonts. For example, installations made in China are not going to be able to load fonts.

Here's patch with local font files. In this patch there's only .woff fonts which are supported by most browsers. Maybe in future we want to provide .woff2 files for browsers that support them.

Even though the character support on Source Sans Pro is quite impressive, it isn't perfect. What should we do when Drupal is enabled on languages that the font doesn't support? Should we still load the webfont even though it could be unnecessary? Should we make it configurable for the user?

Removing the .DS_Store file that somehow got into the patch.

This should fix the test failure.

Unrelated test failure, setting back to needs review.

The Seven theme has been removed from Drupal 10 core. I confirmed that this issue only affects Seven and no other themes included with Drupal core, so I am moving this to the contributed Seven project.

Now Drupal Git Contributor Agreement & Repository Usage Policy says:

All code submitted to the repository that is a derivative work of Drupal must be and it will automatically be redistributed as GPL-2.0-or-later.

A font is not code that is a derivative work of Drupal.