Any word yet on the monowidth version of this font?

You guys teased us almost 2 years ago with:

the x-height measurement does not match the actual height of lower case characters.

Any plans to make Bower (http://bower.io) packages for the Source font families? Would be really useful for including the font across my web projects. Thanks!

There are some differences when I am using the fonts on Windows 7 in Java 7 (Swing):

ttf:

otf:

Seems the lineheight varies btween those 2. Is this issue related to the fonts themself or is it a Swing issue?
@miguelsousa @adobe

https://forums.oracle.com/thread/2573652

In https://github.com/adobe-fonts/source-sans-pro/blob/master/Roman/Black/features#L25 you have

NOTE: For cross-platform consistency, OS/2.TypoAscender and OS/2.TypoDescender must add up to the font's UPM value

Do you know which platforms are inconsistent in their handling of these values?

Please provide a UFO of Multiple Masters as for Source Code Pro.

It would be nice to have U+202F NARROW NO-BREAK SPACE in Source Sans Pro. This is a blank glyph, usually a bit narrower than a normal space.

U+202F is used in French typography (before some punctuation marks), although many people substitute either a normal space or no space. It is also used in Mongolian.

See http://en.wikipedia.org/wiki/Space_(punctuation)#Spaces_in_Unicode for more details on this character.

The regular geometric shapes should have the same visual impact.
Unicode also provides some large square or circles, medium squares, small squares, triangles or circles.
See http://www.unicode.org/reports/tr25/

The geometric shapes ■◆◉ \25A0\25C6\25C9 are way too small for regular size in Source Sans Pro, they should match the sizes of the following regular triangles.
▲△▶▷▼▽◀◁ \25B2\25B3\25B6\25B7\25BC\25BD\25C0\25C1 could be a bit bigger as well.
It’s less clear for ❒ \2752 what size it should have.

The following information was received by me from Pablo García:

The rendering bug happens only for capital letters (caps / upper case). The px sizes affected are 24px, 23px, 22px, 21px, 10px and 9px. The exact problem is that bold face is 1px (or more) shorter than the normal face.

As you can see I have only tested up to size 25px.

The TTF / WOFF formats were forced both with the rendering bug (the screenshot would be exactly the same).

Environment:
Operating system: Ubuntu Lucid Lynx 64bits (x86_64, 2.6.32-46-generic)
Browsers:
Google Chrome Version 26.0.1410.33 beta (GPU disabled),
Chromium Version 27.0.1436.0 (187236) (GPU enabled)
Firefox 20
At Opera 12.14 the rendering issue is similar but happens instead at sizes: 16px, 13px.

We are using this CSS Link:
http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700

CSS obtained as default, WOFF format used:
@font-face {
font-family:
'Source Sans Pro';
font-style:
normal;
font-weight:
400;
src:
local('Source Sans Pro'),
local('SourceSansPro-Regular'),
url(http://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff)
format('woff');
}
@font-face {
font-family:
'Source Sans Pro';
font-style:
normal;
font-weight:
700;
src:
local('Source Sans Pro Bold'),
local('SourceSansPro-Bold'),
url(http://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/toadOcfmlt9b38dHJxOBGFkQc6VGVFSmCnC_l7QZG60.woff)
format('woff');
}

CSS obtained when forcing to TTF:
@font-face {
font-family:
'Source Sans Pro';
font-style:
normal;
font-weight:
400;
src:
local('Source Sans Pro'),
local('SourceSansPro-Regular'),
url(http://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlNzbP97U9sKh0jjxbPbfOKg.ttf)
format('truetype');
}
@font-face {
font-family:
'Source Sans Pro';
font-style:
normal;
font-weight:
700;
src:
local('Source Sans Pro Bold'),
local('SourceSansPro-Bold'),
url(http://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/toadOcfmlt9b38dHJxOBGLsbIrGiHa6JIepkyt5c0A0.ttf)
format('truetype');
}

I just found the fontface kit with older versions of the font.

The ttf files say: Version 1.033 and the fontface kit from google fonts is Version 1.038

But the latest release is 1.050
https://github.com/adobe/source-sans-pro/releases

Also is there somewhere a complete zip file of the fontface kit including svg, eot, ttf and woff?

This issue is a discussion question, I'm not reporting a bug. I'm trying to find a succinct list of languages that Source Pro supports supports. Any chance somebody might be able to relay that here or point me in the right direction?

Double check fitting of small caps, in particular rounds against straights and small A. Use MEDIA as a test word.

Why is it that the A has no white space at the left of the character, but the B has like 3-4 pixels? This is horrible for left-aligning upper case letters neatly. For round characters like the O it's ok, but the L has white space to the left, but none at all to the right.

I am using this font hosted on Google web fonts and at first it was rendering fine but now it looks off. Something about it looks weird. It looks pixelated and it's annoying. I noticed it's looking weird on another site that's using the same font (screenshot below). What's the problem? There's nothing wrong with the CSS on the site I'm working on.

On the first screenshot, I am using the font on the header (with the orange background) and that's at a weight of 400. Something about it looks odd, it looked much better a few days ago.

U+2009, U+200A and U+200B respectively.

It would be nice to have them as part of the font.

I've noticed the '$' behaving strangely on-screen at small sizes. Specifically, the top of the bar seems to be "globbing up" with the top of the "S". Setting 10 pt semibold '$' in InDesign and then viewing at 125% seems to trigger it. Hinting/alignment zone issue?

Is this release just a patch/update or a complete release of the fonts? Because the SVG font is now missing.

The accents (acute, grave, tilde, macron, etc.) on the lowercase letters should be a bit heavier and/or bigger.

In https://github.com/adobe-fonts/source-sans-pro/blob/master/Roman/Regular/font.ufo/fontinfo.plist#L92-L93 the styleMapFamilyName seems odd....

<key>styleMapFamilyName</key>
<string>368 : SourceSansPro_0.ufo / SourceSansPro_1.ufo</string>

This is the same in all UFOs in this repo - https://github.com/adobe-fonts/source-sans-pro/search?utf8=%E2%9C%93&q=styleMapFamilyName

Is this value correct? If not, is it corrected elsewhere?

Are the unicode values assigned by another file or process? Or is this a bug?

When we render code with line breaks, we see strange non-rendered characters.

A screenshot speaks louder than words:

It is present in all weights.

Hello.
I downloaded fonts, SourceSansPro-Reconciliation, and I can not find feature locl for Serbian Glyphs, normal feature in all Adobe Pro fonts.
Serbian glyphs are

I hope You can add glyphs for proper Serbian Cyrillic.
TIA. Best Regards.

All italics of Source Sans Pro seem to have the common problem that the space right of the quotedoublebase (U+201E) is too small. When used in German texts the quote sticks at the following letter, for example in „Ernsthaft?“ – „Leider ja.“

Hi folks, me again...

Ran into this recently:

It only happens on Windows 8/FF 38+. It's fine on Windows 8/Chrome and Mac/Firefox 38+

And again here: https://github.com/gitterHQ/gitter/issues/708

We're basically hosting the release version (https://github.com/adobe-fonts/source-sans-pro/releases/tag/2.010R-ro/1.065R-it) of SSP directly off our own servers. I've been serving up the .otf.woff version ala:

@font-face {
    font-family: "source-sans-pro";
    src: url("/_s/l/fonts/sourcesans/SourceSansPro-Regular.otf.woff") format('woff');
    font-weight: normal;
}

I made a little codepen test and was able to reproduce this until I switched over to the .ttf.woff, which appears to work just fine.

So I had a few questions:

1. Is there any difference between the otf and the ttf .woff? I was under the impression that otf has more features (perhaps they aren't being used).
2. Any idea why this may be happening with the .otf.woff under Win8/FF - have you seen this thing before?
3. Is it safe to switch over to the .ttf.woff version? I won't lose any noticeable features of the font would I?

Sorry for all the questions, never got this deep into the intricacies of webfonts before.

Cheers
Mike

For non-experts, it would be really useful to include woff2 files in the main distributions, and woff2 srcs in the main CSS file.

I don't know the pros and cons of the various converters. I don't really have money to spend on pro font tooling. I want to send the smallest possible files on the wire. I'm sure there are many people just like me. In my very limited understanding, WOFF2 seems to be widely considered best practice on the web.

If I'm missing something obvious please enlighten me, and thanks for a beautiful product.

I downloaded Source Sans Pro - Fonts Only 1.050 from SourceForge. Unfortunately I'm having trouble using it in an OS X app. It appears that the height of the font is specified incorrectly which causes significant space above the characters. You can see the difference between Source Sans Pro and Hypatia Sans Pro in these screenshots:

Superior letters are at the same height as numerator figures. Superior figures are higher.

One would expect superior figures and letters to be on the same line.

Hi - still enjoying this awesome font!

I left a comment on the blog page about the small caps, and it got a reply that they were ready. I was delighted, and ... could not find the small caps in the 1.038 package.

Perhaps it's just me, but would it be worth a line or two in the README spelling out how to access the small caps? I'm used to seeing an "SC" variation, or something. But despite hunting through character maps, etc., I still cannot find the small caps!

Is it worth a moment to add a "numpty's guide"? I live in hope, and thank you!

I see mentioned in #42 that you intend to add African language support to the fonts. Could you also take a look at what other glyphs you need to add to finish IPA support? The IPA is mostly Latin alphabet + African languages glyphs + rotated/flipped versions of those, + a small number of other glyphs.

Looking at the existing glyph complement of the fonts, I don't think it would be too hard to finish IPA support once African languages are added.

There seems to be a Hinting Glitch at the eot WebFont. If the IE8 rendering the Ampersand at 26px it looks like the Glyph wearing a T-Shirt. Could You prove this?

See adobe-fonts/source-serif#3 (comment)

Ƒ/ƒ is a letter in Ewe language, ƒ florin U+0192 should be upright and have the correct ascender and descender height in Roman.

I’m not sure what is the best option you’d want for the current glyph, the Dutch florin symbol, maybe as a stylistic set or Dutch locl glyph.

Please pretty please :3

I'm curious if there is a monospace variant in the works? Currently in iTerm2 it looks like:

I have a few web font hosting related questions regarding Source Sans Pro.

Are web font hosting vendors like TypeKit, Google Fonts, WebInk, etc. are always up to date with each new release? If not, then how long does it take them to get up to date?

Do you have a preferred vendor?

Whenever I look at a sentence sent in SSP, I feel like I need to go in and manually set the word spacing. It's almost as if it's not using a full em space between words. It's very subtle (ha ha), but just that extra 1/3 of a space or so would make a big difference in readability.

There seems to be some issues with the font family encoding. A lot of apps on OSX seem to only show Regular and Bold. If you select Light or Extralight it shows as regular. Example: Messages on OSX and change to Source Sans Pro Light.

PhpStorm was also pretty annoying to get working but that might be a Java issue.

Just feels like this font isn't being distributed/built correctly and it is an awesome font.

Based on adobe/brackets#8985 (comment) it appears that the ttf and otf fonts have drastically different hinting going on, raising the question "which one looks as intended" for the purposes of using the fonts for stable UIs. Is the otf authoritative, and the ttf likely to see improvements/adjustments to its conversion as time goes on?

Italic "double low-9 quotation mark" (U+201E) needs more built-in padding on the right side (or kerning?). Right now it runs into other characters.

Hi there,

At Gitter, we recently switched over to Source Sans Pro, which we really love. One of the issues we've had, however, is there's quite a substantial size difference between Source Sans Pro and other fonts. Our app does some fairly nifty things on load to force the browser to the bottom of the chat and we get some timing race conditions and due to the sizing of Source Sans Pro we often get a reflow of content.

We've tried using events once the font is loaded to then force the chat to the bottom of the page, but this makes for an unpleasant flicker of the user interface.

We were wondering if there were any standard Mac/Windows fonts that have the same sizing?

To Illustrate my point, here's a series of fonts at 14pt...

Would it be possible to add sub- and superscript "+" and "−" characters? I find these particularly useful for writing good-looking chemical formulas in programs that don't support true sub- and superscript (such as LibreOffice Impress)…

There is an issue where certain text containing letters with diaeresis (ä,ö) gets rendered with misplaced diaereses (see attachment) on Firefox. With a not so reduced example, the diaereses are partly over the next character instead of making a empty space underneath them, seen in the attachment.

To my amateur eyes, it seems that there are separate characters for the base letter and the diaeresis. The very characters in my text are causing the problem, because rewriting the text fixes things. But it does not happen with Arial as the font, so maybe there could be room for improvement to handle text more robustly.

Hey Adobe,

I've noticed bower.json is provided with the latest release. Awesome stuff! But I was sad to see that I couldn't just bower install --save source-sans-pro. :(

Am I wrong to assume that you folks might be registering the repo soon? I'm hoping you do, many people use bower, and it would be very helpful to have this typeface readily available for use in projects through the package manager.

I noticed this mentioned in #35, and here's my "pretty please" in response to this.

All it takes is a bower register https://github.com/adobe-fonts/source-sans-pro.git. In fact, anyone can do it, but it would probably be rude for someone to do it if he or she wasn't the actual maintainer of the project.

I work as a consultant for various organizations, including in recent years the Google Fonts team, and I'm pleased to say that Google is offering some limited financial assistance to commission qualified designers to improve popular libre-licensed font projects, especially to increase their language support.

https://github.com/adobe-fonts/source-sans-pro#getting-involved says to email Paul directly to discuss how to get involved, and after a brief discussion with him, I thought I'd file an issue here to ask the wider SSP community about what was important to you all.

What would you like to see added to Source Sans Pro?

Regarding language support, its a big effort, and any single organization's budget is always limited, so I'd love to know if anyone subscribed here knows of any companies or other organizations who would like Source Sans or Serif to be extended to the following scripts, and would be willing to 'co-pay' with Google so that together we can all go further :)

Arabic
Bengali
Gujarati
Gurmuhki
Hebrew
Kannada
Malayalam
Sinhala
Tamil
Telugu
Thai

To recap, from what I can gather, so far the project has been extended from Latin to IPA, Greek and Cyrillic by @pauldhunt for the upright styles, and by Marc Weymann (who I couldn't find on Github just yet) for small caps in the upright styles. It seems to me that a good thing would be to round-out those additions to all styles in the family; certainly the Google Fonts API would benefit from that, to provide consistent web font families.

There are also the sister projects led by @frankrolf , Source Serif Pro, and it has some 'evening out' issues already filed for italics and IPA, Greek and Cyrillic

There's also the Source Han Pro project, which was developed by a cross-industry collaboration to support all of CJK, and has been released as a separate family. That seems typical of Adobe's multi-script families, such as Myriad which has "Myriad Hebrew" and "Myriad Arabic" and those include scaled down Latin glyphs that harmonize and are sort of secondary to the script in the family name.

In that direction, there are some 'cousins' too; new projects not directly affiliated with Adobe, for scripts not directly related to Latin, but designed to be compatible or harmonious with SSP, like @khmertype 's Lao Sans Pro and Myanmar Sans Pro, and @erinmclaughlin's sketch of a Source Sans Pro compatible Devanagari. I wonder if there are there any other projects like these cooking silently behind closed doors? :)

freetype 2.6.2
fonts.conf

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <match target="font">
  <edit mode="assign" name="autohint">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>none</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintmedium</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

when i type in the combo "ft", the 't' seems like it is a little bolder, looks blurry. with normal t' this wont happen. it also wont happen with "fft" . but it happens again with "ffft" so with everything "n*2+1f"t combination.

everything else looks brilliant.

The font looks really bad (when installed from github using AFDKO) on Mountain Lion.

I followed the same steps (essentially running build.sh) on my on other laptop with OSX Lion and the font looks great.

Has anyone had luck with Mountain Lion?

I have a question about the way the various fields in the 'name' table are set up for the Source Sans Pro family of fonts.

For regular, bold, italic, and bold italic weights, Name ID 1 ("Font family name") is set to "Source Sans Pro". For the fonts whose weights do not match the "base four" weights (i.e. Black, Semibold, Light, Extra Light) Name ID 1 ("Font family name") is set to "Source Sans Pro ".

This seems to cause most Windows applications, e.g. WordPad, to show the extra light, light, semibold and black versions of Source Sans Pro as separate fonts, while the "base four" weights can all be obtained by choosing "Source Sans Pro" from the font combo and using the bold and italic buttons.

However, it also means that these fonts are interpreted as being in separate families, e.g. the "Source Sans Pro Light" family, rather than the "Source Sans Pro" family.

I note that Name ID 16 ("Preferred Family") is set to "Source Sans Pro" for all weights.

My question concerns why this particular arrangement of settings was chosen, and how an application that wants to interpret all weights as being part of a single family should interpret the available data.

Thanks!

Just a suggestion that you should include screenshots of the font in the readme so that people can see what the font looks like.