latin: Add U+2122 (™)

[criana]

I recently discovered the Open Sans library via Google Fonts is missing the trademark symbol. It's currently an issue with a website I'm working on, and was able to verify it with the font preview tool on Google Fonts.

Although Adobe's version of the library has the TM. Any chance of getting the Google hosted library fixed?

[enathu]

I have checked this issue with a CodePen, and the Trademark (™) sign is showing as intended. You can have a look at the CodePen here

However, I can also confirm that that the Google Font preview tool, doesn't show the ™ mark in any font, as I've tried with it. May be it's an issue with preview tool, not with the font. Hope this get fixed.

Cheers.

[criana]

@enathu thanks for sharing, that's very interesting. I wonder why on our site pulling the Open Sans font gives us the TM in a box representation.

[criana]

@enathu I just made a slight edit to the CodePen and was able to reproduce the issue. Remove "sans-serif" from after Open Sans and the TM becomes a [TM] in a box, broken character. I believe the library may still be missing this item and when "sans-serif" is supplied it defaults to the system sans-serif font which does contain that character.

Does that make sense?

[enathu]

@criana Alright, that makes sense, now. So, I think it's an issue with GF API, since it's showing the same cross (missing glyphs) for all other fonts for trademark sign. Even though the trademark sign is inside the font file, as I just checked with the GF hosted Open Sans files.

Pinging @davelab6 for fix. :)

[davelab6]

The directory's preview isn't an accurate reflection of the characters available in the font. The sans-serif thing is interesting, I'm not sure what is happening there... my guess is that when you add sans-serif then the browser uses the ™ that is in the default sans-serif font (likely Arial on windows) but when sans-serif is not there, is uses a default font (not sure what) which for some reason has this character in a box like that.

I'm using a mac right now, and the ™ in the codepen does look slightly different with/without the sans-serif, but there is no box shape.

The unicode U+2122 is not in the latin subsets, though, and thus isn't being served... so it could be a candidate for inclusion in the latin-ext subset.

https://github.com/google/fonts/blob/master/tools/encodings/latin_unique-glyphs.nam

https://github.com/google/fonts/blob/master/tools/encodings/latin-ext_unique-glyphs.nam

[codeman38]

U+2122 is part of the legacy Latin character sets for both Windows and Mac OS, so it feels like it should possibly even be included in latin.

>>> u'\u2122'.encode('cp1252')
'\x99'
>>> u'\u2122'.encode('macroman')
'\xaa'

[criana]

@davelab6,
Thanks for looking into this more. I've attached a screen shot of what I see in CodePen. I'm running Chrome on a Mac with OS 10.10.4. I also do no have any versions of OpenSans running locally on my machine. This is only when sans-serif is removed from the font-declaration.

[davelab6]

Here's what I see in Chrome 46, also 10.10.4, also none installed locally...

[criana]

I was able to verify this too after a thorough cleaning of fonts and caches on my machine. Sorry for the mixup.

[davelab6]

No worries @criana - the suggestion to add ™ is a good one :)

[BenRacicot]

Hey @davelab6 any updates on this? I'm having the exact same issue as @criana perhaps someone has a nicer fix than adding a fallback font?

[qJake]

This is still an issue - Open Sans does not include the ™ character in any subset, and if a fallback font is not specified via CSS, it defaults (on most PCs) to a serif font, which looks ugly:

The ™ character should be included in the latin-ext subset. 😄 👍 ™️

[davelab6]

Re-acknowledging this issue :) I'll see what I can do!

[danimalweb]

Any update on this? Thanks :)

[m4rc1e]

Made up a quick Jsbin:

LGTM http://jsbin.com/perivejuqa/edit?html,output

[qJake]

@m4rc1e In #785 you said:

#78: Works just fine for me, added comment, skipping

It still does not render for a lot of us. Your JSbin renders for me (incorrectly) like this:

Can you try testing on a fresh VM with Windows 10 + Chrome 59? On a VM here with that environment I get this (same behavior):

I'd like to vote to reopen unless there is concrete proof that this isn't an issue, or the decision has been made for the ™ character to not be included in any subsets of Open Sans on Google Fonts.

[m4rc1e]

Thanks @qJake ,

Here's my screenshot on Win 10, Chrome 59. You're correct

However, the glyph exists in the fonts:

It gets served properly on OS X. I will look into this more.

[davelab6]

Thank you @roozbehp :D

[stuartpb]

Shouldn't this issue stay open until the change is integrated?

[davelab6]

Ok, yes, reopening until your is plumbed all the way through to production :)

[davelab6]

Coming soon...

[VeeDoubleYuh]

Curious if there are any updates on this. I see it's been quite a while since there has been a post.

I haven't read every post here, but if anyone needs to pull in a "pretty" TM for their site and they don't mind an extra request, you can do what I'm doing right now. I've placed this line at the end of my HTML's <body>.
<link href="https://fonts.googleapis.com/css?family=Cairo:300,400,600,700&text=™" rel="stylesheet">
The "text=™" will pull only that glyph rather than the whole font according to this.

Then, you just make the above font (Choose whatever font you wish, of course. I just liked the TM in this one.) the second in your font stack in CSS. Not a perfect fix, but it's a decent workaround until there is a native TM in this font.

You can also put it in the <head>, but I felt that it was a small enough enhancement that it wasn't something that should slow everything else down.

[davelab6]

Yes the text API can work like that, although you should url encode the character to make sure it is standards compliant html and works everywhere.

…

On Tue, Jan 15, 2019, 7:19 PM Veronica Watt ***@***.*** wrote: Curious if there are any updates on this. I see it's been quite a while since there has been a post. I haven't read every post here, but if anyone needs to pull in a "pretty" TM for their site and they don't mind an extra request, you can do what I'm doing right now. I've placed this line at the end of my HTML's <body>. <link href=" https://fonts.googleapis.com/css?family=Cairo:300,400,600,700&text=™" rel="stylesheet"> The "text=™" will pull only that glyph rather than the whole font according to this <https://developers.google.com/fonts/docs/getting_started#optimizing_your_font_requests> . Then, you just make the above font (Choose whatever font you wish, of course. I just liked the TM in this one.) the second in your font stack in CSS. Not a perfect fix, but it's a decent workaround until there is a native TM in this font. You can also put it in the <head>, but I felt that it was a small enough enhancement that it wasn't something that should slow everything else down. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#78 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9y0PhQQdAJ1UM0j75KWp8kRTx-74Cks5vDnAogaJpZM4FYhFW> .

[code23-isaac]

Coming soon...

[davelab6]

What I remembered was that Roozbeh left Google in the middle of this effort and no one picked it up since. Let's assign it to me and eventually we will deal with it

[davelab6]

Actually @RosaWagner says she can take the next steps on this so reassigning

[davelab6]

Haha after looking further, this is already fixed

https://fonts.googleapis.com/css?family=Open+Sans has

/* latin */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  font-stretch: 100%;
  src: url(https://fonts.gstatic.com/s/opensans/v27/memSYaGs126MiZpBA-UvWbX2vVnXBbObj2OVZyOOSr4dVJWUgsjZ0B4gaVIUx6EQ.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;
}

So u+2212 there means it will be provided by default when it exists in the font

Thanks @RosaWagner for looking closer at this :)