googlefonts / roboto Goto Github PK

James, please review the following commit:
de647e3

Make sure we have ligature carets for all ligatures, such as "fi".

We basically need to make sure all the ligatures in the font (including contour tones in #13) have ligature carets in the GDEF table (LigCaretList table at http://www.microsoft.com/typography/otspec/gdef.htm).

Internal bug b/15653110

Check that the glyphs are proper and that they match what is expected of them.

The features seem to be set correctly, but *.lnum glyphs are misnamed. *.lnum glyphs currently refer to proportional numbers, and should probably be renamed to *.pnum.

Tabular old style numbers are present in the font (named *.tnum) but don't seem to be used anywhere; they could be used in the tnum feature.

These are IPA contour marks (such as ˥˥˦), and their behavior is defined at Unicode 6.2, section 7.8, page 237.

We need to make sure all combinations we care about are supported as ligatures in the fonts.

Currently some of the glyphs in condensed italic fonts are coming out very wrong e.g. "w" in RobotoCondensed-Italic:

All of the non-italic condensed fonts and non-condensed italic fonts seem fine, however.

The fonts have a Navajo form for Ą and Ę with centered ogonek, but miss the small caps variants of the letters.

The values that were already in the font have been changed by ParaType, perhaps unintentionally (see internal issue 31). We need to find the right values and set them.

Assigning to Christian, as this is a design issue.

What steps will reproduce the problem?

1. Install the Roboto fonts family (Windows 7, Windows 8, Windows 8.1)
2. Start using Microsoft Word (2010/2013)
3. Select Roboto Fonts

What is the expected output? What do you see instead?
Word shows only "Roboto" in the Fonts selector and uses only the first installed fonts type. Even so it is possible to select another type in the fonts property menu the chosen type is not shown/used.

https://code.google.com/p/googlefontdirectory/issues/detail?id=233

Building the fonts with the latest open source version of AFDKO (adobe-type-tools/afdko@d6d94c0) fails.

Here's the relevant output:

>> Generating OTF file

makeotf [Note] Converting source font '/font.otf' to temporary Unix Type1 font file '/font.otf.tmp'.
makeotf [Note] setting the USE_TYPO_METRICS OS/2 fsSelection bit 7 from fontinfo keyword.
makeotf [Note] setting the WEIGHT_WIDTH_SLOPE_ONLY OS/2 fsSelection bit 8 from fontinfo keyword.
makeotf [Note] setting the OBLIQUE OS/2 fsSelection bit 9 from fontinfo keyword.
makeotf [Note] Writing options file /current.fpr
makeotf [Note] Running makeotfexe with commands:
   cd ""
   makeotfexe "-f" "font.otf.tmp" "-o" "Roboto-Thin.otf" -ff "features" -gf "glyphOrder" -mf "menuname" -shw
makeotf [Error] Failed to build output font file 'Roboto-Thin.otf'.

makeotfexe [WARNING] The total size of the glyph names is greater than the safe limit for Mac OSX 10.4.x and earlier by 1885 bytes, and will cause crashes. [font.otf.tmp]
makeotfexe [ERROR] <Roboto-Thin> MarkToBase or MarkToMark error 2: A previous statement has already assigned the current mark class to another anchor point on the same glyph 'A'. Skipping rule.  [features 330]
makeotfexe [ERROR] <Roboto-Thin> MarkToBase or MarkToMark error 2: A previous statement has already assigned the current mark class to another anchor point on the same glyph 'B'. Skipping rule.  [features 376]

[...]

makeotfexe [ERROR] <Roboto-Thin> MarkToBase or MarkToMark error 2: A previous statement has already assigned the current mark class to another anchor point on the same glyph 'zrthook'. Skipping rule.  [features 918]
makeotfexe [WARNING] <Roboto-Thin> head FontRevision entry <2.1047> should have 3 fractional decimal places. Stored as <2.105> [features 5432]
makeotfexe [FATAL] <Roboto-Thin> aborting because of errors

make: *** [v2] Error 1

As a Latin and general purpose character, it's considered a math character,
proposed in http://www.unicode.org/L2/L2007/07011-n3198-math.pdf.

It's not supposed to match the asterisk in the font, but should be always
six-pointed.

Internal tracker b/21566652
/cc @xiangyexiao @raphlinus

It should map oldstyle digits to to tabular oldstyle digits. Spec at https://www.microsoft.com/typography/otspec/features_pt.htm#tnum.

(Internal bug https://code.google.com/a/google.com/p/roboto/issues/detail?id=59)

We need to figure out if that is desired for all version of Roboto, or only those shipped with Android or served on the web.

The values are 1900/-500/0.

\cc @roozbeh @raphlinus @jungshik @davelab6

There are various samples from http://www.unicode.org/L2/L2010/10346-n3907-teuthonista.pdf that should be added to samples directory and tested. Note that the documents is based on an older encoding model for the characters, but the samples from the pages are still valid.

The accents on various letter alternatives are not positioned the same way as the main letters. For example, see the following comparison of "ą̈ ę̄ ę̀" with "ä ē è", where the accents of the ogonek forms are to the left of the accents of the basic letters (from internal bug 149):

We need to find a good mechanism to compare, test, and fix this.

/cc @jamesgk

Here's Roboto's rendering of "hy‧phen‧ation"

There are at least three things wrong the current shape:

1. It should be circular.
2. It should be larger.
3. It should have more space around it.

It seems that Segoe UI Symbol has this right:

Internal bug b/21566375
/cc @raphlinus @christianrobertson @xiangyexiao

All letters should have anchors above and below them, all marks should have anchor points for attaching to letters and other marks.

We can probably deduce anchor points for some of the composite glyphs. For example, if C has an anchor point for an umlaut, C-cedilla can keep the same anchor point since a cedilla is on the other side.

cc @roozbehp

It would be really nice if you could see an example of the font (or click through a link to see one) in the README - to get a sense for whether I'd like to use it.

Compare with popular sans fonts, see if they provide anything that we don't.

\cc @roozbehp @davelab6

Due to the glif default file naming scheme in Robofab glyphs like 'LJ' and 'Lj' are overwritten by one another. The UFO, OTF and TTF generated only have one of 'LJ' and 'Lj' or 'NJ' and 'Nj' instead of both in both pairs, or makeotf fails to produce them because of a key error.

We made a pull request to address the issue in robofab: robofab-developers/robofab#35
Another fix would be to use uninames for those glyphs.

I think the macron on ī (i with macron above) may be too wide.

Looking at some of the Windows fonts, it seems that some fonts (Arial, Segoe UI) generally have a relatively short macron which is used for every letter, while some others (Tahoma) use a shorter macron for i and a larger macron for other letters.

Roboto:

Arial:

Segoe UI:

Tahoma:

Christian, what should we do for Roboto?

/cc @sven-oly

When I try to build the fonts using "make v2", and there's no "makeotf" available, the script continues trying to build the TTF anyway, although building the OTF has failed. Here's the error I get:

>> Generating OTF file

/bin/sh: makeotf: command not found

>> Generating TTF file
The requested file, Roboto-Thin.otf, does not exist
Traceback (most recent call last):
  File "/tmp/makefontsB.py", line 84, in <module>
    proj.generateFont(th.font,"%s/Thin/Regular/Th"%FAMILYNAME)
  File "/home/roozbeh/roboto/scripts/lib/fontbuild/Build.py", line 191, in generateFont
    otFont = fontforge.open(otfName)
EnvironmentError: Open failed
make: *** [v2] Error 1

It should just stop after the first failure.

From internal bug 18782818:

@raphlinus:

[...] I researched the shape of "χ" in a number of other contemporary Greek fonts, and see that the
version without descenders is quite common. For example, it appears in the Ubuntu font, which was
developed by a highly respected type foundry. In addition, in the discussion of
http://typophile.com/node/29711 it is stated, "chi's and eta's without descenders are something that
more and more appears in contemporary Greek typefaces (a big percentage of typefaces designed
and used inside Greece)".

It's a bit controversial. In http://blog.gmane.org/gmane.comp.fonts.dejavu/month=20061201 Ben
Laenen states: "That is one of the concerns I'm having, and also that the Greek should be useable for
ancient Greek as well. Therefor I'm still not too keen on the eta and chi without descenders." [...]

@roozbehp:

This appears to be a deliberate change by Christian in Roboto 2 (Roboto 1 has a different chi than x).

I personally don't like it: Roboto is now a default font everywhere, and Greek is not limited to modern
Greek (there are lots of people using chi on the web for basic math, and they are now seeing their x's
and their chis the same way [...]). Basically, I think we want to be more conservative
with a system font.

I also compared with the Windows 10 sans system fonts. Arial, Calibri, Segoe UI, and Tahoma, all
differentiate their chis and their x's, I believe for similar reasons.

[...] I think it needs to be fixed in Roboto 3.

@christianrobertson:

Valid feedback. We should do more research on this question. Generally I
agree with the point that we should choose the more conservative route for
the system font, though in this case the answer isn't 100% clear. The math
point is interesting since there are other characters where the expected
math version of the symbol doesn't work well for running text, or has
diverged from the common usage. In some cases there are multiple code
points, but as far as I know it's not the case for chi.

Feedback from native Greek Googler:

Just wanted to add in this discussion the fact that we (native Greeks) use
'x' as a multiplication symbol, which is another reason that if things stay
as is there will be some major complications. ''x" is never used in Greek
either as the English x character or the multiplication symbol.

In schools, we are taught to write chi as chi and ita as 'η' but without
the longtail. 'η' is actually considered an older form, no one is writing
it like that at the moment (I should perhaps file another bug for this),
but that seems to be more innocent than using a character from another
language (x instead of chi). [...]

According to the Microsoft spec at https://www.microsoft.com/typography/otspec/recom.htm, the TAB (U+0009) character should have an advance width equal to that of space.

This is true in the latest fonts, but we need to have a unit test making sure it doesn't regress.

The glyphs for ᶛƖᵻᶦᵿᶷ are wrong

• ᶛ U+1D9B is not a superscript mirrored Latin alpha but a superscript turned Latin alpha. It should look like ɒ U+0252.
• Ɩ U+0196 must not be the same as I U+0049, some languages use both Ɩ/i and I/i.
• ᵻ U+1D7B is not a small cap i nor dotless i with a bar but ɪ U+026A, a letter small capital i which must have serifs, with a bar. Use the component Ismallcap instead of dotlessi (in Bold) and I.smcp (in Regualr and Thin).
• ᶦ U+1DA6 is not superscript small cap i either, but again a superscript letter small capital i which must have serifs.
• ᵿ U+1D7F is not a Greek upsilon with a bar but a Latin upsilon, ʊ U+028A, with a bar.
• ᶷ U+1DB7 is a superscript ʊ U+028A and thus should be based on it (one has corners for the top serifs, the other is round)

Some lingering differences in mark positioning still exist between the new output and the old. These differences are quite small (<10 units), but there are hundreds of them per font. Even if we don't completely do away with every difference we want to at least understand their cause.

We need to figure out the list of base+combining characters we care about, and make sure they have the right anchors and work properly, and then test them.

Some things to consider: CLDR exemplars, web frequency data, and combinations supported by Windows fonts (to increase compatibility).

It presently has round corners. It should have sharp corners.

Compare with Unicode chart and any font on Windows or OS X that supports the characters.

Internal bug b/21561516
/cc @xiangyexiao

Something along the lines of:

mkdir -p $HOME/src
cd $HOME/src
git clone https://github.com/behdad/fonttools
git clone ....
export PYTHONPATH=....

https://github.com/google/roboto/blob/master/build.bat

According to Roozbeh Pournader: "The batch file is an artifact of the old Windows build environment."
https://plus.google.com/+RoozbehPournader/posts/jbLJZGWFj68

As shown in the image below (Left is Roboto and Right is Noto Sans (CJK) KR), the width of U+20A9 in Roboto is too wide.

Its width should be comparable to other currency signs in Roboto. (it using 'W', it can be slightly wider than $, I guess).

Besides, perhaps, a single horizontal bar is better than two horizontal bars.

Note also that U+20A9 is preferred over U+FFE6 (full-width Korean Won Sign) in the CLDR and other locale data for Korean currency display. So, it's important to get U+20A9 right.

We also need to check the width of Yen sign (U+00A5). While we're at it, we may wanna check the glyphs of other currency signs in Roboto.

I've installed the requirements multiple times but I get the same error below. I'm not sure if this is related to #55 or if this is a different issue altogether.

If #55 is not the cause of this error; where do I need to look at to get this fixed?

PYTHONPATH=:/Users/carlos/code/roboto-src/roboto/scripts/lib python scripts/build-v2.py
BuildNumber: 01290
---------------------
Roboto Thin
----------------------
>> Generating OTF file
Traceback (most recent call last):
  File "scripts/build-v2.py", line 97, in <module>
    proj.generateFont(th.font, "%s/Thin/Regular/Th"%FAMILYNAME)
  File "/Users/carlos/code/roboto-src/roboto/scripts/lib/fontbuild/Build.py", line 181, in generateFont
    builtSuccessfully = saveOTF(newFont, otfName, autohint=self.autohintOTF)
  File "/Users/carlos/code/roboto-src/roboto/scripts/lib/fontbuild/Build.py", line 293, in saveOTF
    reports = compiler.compile(font, destFile, autohint=autohint)
  File "/usr/local/lib/python2.7/site-packages/ufo2fdk/__init__.py", line 88, in compile
    partsCompiler.compile()
  File "/usr/local/lib/python2.7/site-packages/ufo2fdk/makeotfParts.py", line 66, in compile
    self.setupFile_outlineSource(self.paths["outlineSource"])
  File "/usr/local/lib/python2.7/site-packages/ufo2fdk/makeotfParts.py", line 81, in setupFile_outlineSource
    c.compile()
  File "/usr/local/lib/python2.7/site-packages/ufo2fdk/outlineOTF.py", line 77, in compile
    self.setupTable_CFF()
  File "/usr/local/lib/python2.7/site-packages/ufo2fdk/outlineOTF.py", line 654, in setupTable_CFF
    glyph = self.allGlyphs[glyphName]
KeyError: 'Lj'
make: *** [v2] Error 1

The acute accent in the sequence Į́ (<012E, 0301>) is not properly positioned in any size in small-caps.

The combination is used in the Navajo language and potentially other languages.

See the attached screeshots:

The combination is working for the other capital letters in the normal form, but broken in the Navajo form which has a centered ogonek.

See the attached screenshots. The text is "Ą́ Ę́ Į́ Ǫ́ Ų́":

Iit would be nice to have a list off all needed programs like eog, vfb2ufo.exe, etc.

https://www.google.com/fonts/specimen/Roboto+Mono
I have no pressing need right now. I or someone will try to get someone to add PowerLine glyphs someday....

vfb2ufo, which we use to convert FontLab source files to UFO toolchain input, seems to have a few open bugs:

1. Anchors are dropped from glyphs with components but no contours.
2. Composite glyphs including uni1ABE (i.e. lmidtilde_uni1ABE, dcroat_uni1ABE, eng_uni1ABE, gbar_uni1ABE, bbar_uni1ABE, and rrthook_uni1ABE) are dropped.
3. Some glyphs are decomposed (e.g. Gbar and uni04BA).

We create temporary workarounds in the toolchain for these issues while they remain open.

According to Microsoft's Character design standards, the width of U+2009 THIN SPACE is language-dependent. Here's the actual text:

Thin space U+2009 - Standard setting is 1/5 of the em space. 410 units in a 2048 unit per em font. This should be language dependent. The standard language dependent setting for French is 1/8 of the em space. 256 units in a 2048 unit per em font.

Note : When traditionally typesetting he French language a word space is inserted before or after several punctuation characters. These characters are colon, semi colon, question, exclamation, right guillemets, and left guillemets. Commonly the preferred word space used is a thin space of 1/8 the em. Some French typographers prefer to use a larger space character of 1/4 the em with the colon and some other punctuation characters. OpenType supports character substitution and language dependant variants.

/cc @christianrobertson, @raphlinus

Although the height of the various letters have not changed between Roboto version 1 and version 2, the hinted size of the letters has visibly changed between version 1 and version 2.

This is most visible in 12px, 14px, and 16px sizes, where the 1-pixel height difference between Roboto v1 is most visible.

For example, here is the hinted height of the letter 'x', which is 1082 units in both Roboto v1 and Roboto v2:
12px: v1=7px v2=6px
14px: v1=8px v2=7px
16px: v1=9px v2=8px

Capital letters also change, although not dramatically. In 16px, the height of 'A' changes from 12px to 11px, although it's 1456 units in both Roboto v1 and v2.

Internal bug b/19127020
/cc @roozbehp @christianrobertson @davelab6 @jungshik

nototools is also heavily used by some of the scripts, mostly the post-production ones.

They should be drawn with a thinner pen. Compare Roboto Regular, Noto Sans Symbols, and Segoe UI Symbol:

Roboto Regular:

Noto Sans Symbols:

Segoe UI Symbol:

Internal tracker b/21523111
/cc @xiangyexiao

Christian,

I think the shapes of Insular T are still problematic. What do you think? I'm including sample words from the Unicode proposal at http://www.unicode.org/L2/L2006/06266-n3122-insular.pdf.

Roboto Thin:

Segoe UI:

Roboto Regular:

Roboto Black:

coverage_test.py checks individual characters, but we want to also check that we support character sequences e.g. gbar_uni1ABE.

U+20B4 Hryvnia sign have incorrect shape

https://en.wikipedia.org/wiki/Hryvnia_sign

Noto Sans Symbols

Roboto

@jamesgk knows the exact details (which seems to be a FontLab conversion issue). Using this to track it, so we don't release without a fix.

There's two sets of superscript digits in the fonts. One set is cmap-ped from the Unicode superscript digits "⁰¹²³⁴⁵⁶⁷⁸⁹", while another is triggered by the 'numr' feature.

Investigate if they can be merged into one set.

/cc @christianrobertson

Write tests to make sure hints are stripped from the Android version of the fonts.

Do you have a pod for iOS like the font OpenSans?

Basically provide the command line tool one needs to run to build the UFO from the VFB files, and what one needs to do in FontLab to import the UFOs in FontLab.

Those are the Mac tables, and it's possible that Mac knows how to get them from the Windows tables.

The soft-dotted characters should lose their dots when combined with combining characters above. Here's a list:

0069..006A  LATIN SMALL LETTER I..LATIN SMALL LETTER J
012F        LATIN SMALL LETTER I WITH OGONEK
0249        LATIN SMALL LETTER J WITH STROKE
0268        LATIN SMALL LETTER I WITH STROKE
029D        LATIN SMALL LETTER J WITH CROSSED-TAIL
02B2        MODIFIER LETTER SMALL J
03F3        GREEK LETTER YOT
0456        CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
0458        CYRILLIC SMALL LETTER JE
1D62        LATIN SUBSCRIPT SMALL LETTER I
1D96        LATIN SMALL LETTER I WITH RETROFLEX HOOK
1DA4        MODIFIER LETTER SMALL I WITH STROKE
1DA8        MODIFIER LETTER SMALL J WITH CROSSED-TAIL
1E2D        LATIN SMALL LETTER I WITH TILDE BELOW
1ECB        LATIN SMALL LETTER I WITH DOT BELOW
2071        SUPERSCRIPT LATIN SMALL LETTER I
2C7C        LATIN SUBSCRIPT SMALL LETTER J

"Combining characters above" includes (may not be comprehensive):

0363 COMBINING LATIN SMALL LETTER A
0364 COMBINING LATIN SMALL LETTER E
0365 COMBINING LATIN SMALL LETTER I
0366 COMBINING LATIN SMALL LETTER O
0367 COMBINING LATIN SMALL LETTER U
0368 COMBINING LATIN SMALL LETTER C
0369 COMBINING LATIN SMALL LETTER D
036A COMBINING LATIN SMALL LETTER H
036B COMBINING LATIN SMALL LETTER M
036C COMBINING LATIN SMALL LETTER R
036D COMBINING LATIN SMALL LETTER T
036E COMBINING LATIN SMALL LETTER V
036F COMBINING LATIN SMALL LETTER X
0483 COMBINING CYRILLIC TITLO
0484 COMBINING CYRILLIC PALATALIZATION
0485 COMBINING CYRILLIC DASIA PNEUMATA
0486 COMBINING CYRILLIC PSILI PNEUMATA
0487 COMBINING CYRILLIC POKRYTIE
20F0 COMBINING ASTERISK ABOVE
A66F COMBINING CYRILLIC VZMET
A674 COMBINING CYRILLIC LETTER UKRAINIAN IE
A675 COMBINING CYRILLIC LETTER I
A676 COMBINING CYRILLIC LETTER YI
A677 COMBINING CYRILLIC LETTER U
A678 COMBINING CYRILLIC LETTER HARD SIGN
A679 COMBINING CYRILLIC LETTER YERU
A67A COMBINING CYRILLIC LETTER SOFT SIGN
A67B COMBINING CYRILLIC LETTER OMEGA
A67C COMBINING CYRILLIC KAVYKA
A67D COMBINING CYRILLIC PAYEROK
A69F COMBINING CYRILLIC LETTER IOTIFIED E
2DE0 COMBINING CYRILLIC LETTER BE
2DE1 COMBINING CYRILLIC LETTER VE
2DE2 COMBINING CYRILLIC LETTER GHE
2DE3 COMBINING CYRILLIC LETTER DE
2DE4 COMBINING CYRILLIC LETTER ZHE
2DE5 COMBINING CYRILLIC LETTER ZE
2DE6 COMBINING CYRILLIC LETTER KA
2DE7 COMBINING CYRILLIC LETTER EL
2DE8 COMBINING CYRILLIC LETTER EM
2DE9 COMBINING CYRILLIC LETTER EN
2DEA COMBINING CYRILLIC LETTER O
2DEB COMBINING CYRILLIC LETTER PE
2DEC COMBINING CYRILLIC LETTER ER
2DED COMBINING CYRILLIC LETTER ES
2DEE COMBINING CYRILLIC LETTER TE
2DEF COMBINING CYRILLIC LETTER HA
2DF0 COMBINING CYRILLIC LETTER TSE
2DF1 COMBINING CYRILLIC LETTER CHE
2DF2 COMBINING CYRILLIC LETTER SHA
2DF3 COMBINING CYRILLIC LETTER SHCHA
2DF4 COMBINING CYRILLIC LETTER FITA
2DF5 COMBINING CYRILLIC LETTER ES-TE
2DF6 COMBINING CYRILLIC LETTER A
2DF7 COMBINING CYRILLIC LETTER IE
2DF8 COMBINING CYRILLIC LETTER DJERV
2DF9 COMBINING CYRILLIC LETTER MONOGRAPH UK
2DFA COMBINING CYRILLIC LETTER YAT
2DFB COMBINING CYRILLIC LETTER YU
2DFC COMBINING CYRILLIC LETTER IOTIFIED A
2DFD COMBINING CYRILLIC LETTER LITTLE YUS
2DFE COMBINING CYRILLIC LETTER BIG YUS
2DFF COMBINING CYRILLIC LETTER IOTIFIED BIG YUS
20DB COMBINING THREE DOTS ABOVE
1ABB COMBINING PARENTHESES ABOVE
1ABC COMBINING DOUBLE PARENTHESES ABOVE
20DC COMBINING FOUR DOTS ABOVE
FE20 COMBINING LIGATURE LEFT HALF
FE21 COMBINING LIGATURE RIGHT HALF
FE22 COMBINING DOUBLE TILDE LEFT HALF
FE23 COMBINING DOUBLE TILDE RIGHT HALF
FE24 COMBINING MACRON LEFT HALF
FE25 COMBINING MACRON RIGHT HALF
FE26 COMBINING CONJOINING MACRON

Compare with Unicode chart, and the glyphs in Noto Sans Symbols and Segoe UI Symbols:

Roboto:

Noto Symbols:

Segoe UI Symbols:

Internal tracker b/21500703
/cc @xiangyexiao