… and since this family lacks the OpenType feature to turn the sequences ⟨l·l⟩ and ⟨L·L⟩ into something nicer (this exists in e.g. Fira Sans), Catalan typography looks quite bad by default.

It should be noted that Rubik does contain the characters “Ŀ” and “ŀ”, but these are deprecated and discouraged for Catalan typing.

Requesting an alternate "J" glyph without the cross bar at the top.
The typeface looks great, but in some contexts I need a simpler J.
Is this possible?

Screenshot captured via Google Fonts:

The lowercase letters of "f" and "i" have no kerning space between them. Makes it look weird with the top of the "f" connecting perfectly with the dot on the "i". The horizontal line in "f" also connects perfectly with the lower vertical portion of the "i". Makes the entire shape look like a different glyph entirely.

Comments by thlinard. A foundry decision.
davelab6#21

Check the text in navigation bar.

Hello,

Rubik font is not support Vietnamese script yet, example: á á â ă ê ư ơ ô ố ồ ớ ờ ợ ộ.
Could you guys help me to add Vietnamese script to this font, or tell me how to do it.

Thank you so much.

please could you add ľ in italic rubic fonts?

First of all, thank you very much for designing and maintaining this font. I've looked up at least hundreds of different fonts for displaying numbers, and Rubik is at the top of my list that I can't wait to use in my next project.

Back to the issue, I checked the .glyphs file and the fixed-width digits are already there with .otlf suffix, but there isn't any feature definition. This is probably broken when migrating sources from version-1. I am not very familiar with font editing so can't help with an PR.

Hope you can read this and have time to fix it.
Have a good day.

Hey, the italic ľ character is not correctly represented. It has a tick under the letter and not in the upper right corner. Is there a way to repair it? Thanks.

Hey folks.

@alexeiva @meirsadan I'm a little puzzled over why we have double sources, .glyphs and .ufo?

@meirsadan are you using Robofont?

Ideally, we should have just .glyphs.

It's a shame the font doesn't include this character, it's so useful when displaying identifiers 😟.

I have noticed that the inverted question mark (¿, U+00BF) is not spaced properly on italics. Could you fix it?

It would be so great to have an alternate for l to make it more distinguishable from I.

I has a quick look a the source file. The hinting settings (stems) are the same in both masters. That can’t be right.

• the font files lack a nbsp glyph, which should be added with the same advanceWidth as space

Hello!

This is an automatically-generated report about possible interpolation problems in Rubik-Italic[wght].ttf, as found in the Google Fonts catalog.

The particular version of the font that was tested was archive:.

To download a PDF version of this report with helpful visuals of the problems, click here; Or to view it on the GitHub website, click here.

The report follows:

Glyph peh_alefMaksuraar was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3] in '', [0, 3, 1, 2] in 'wght=900.0'
Glyph peh_noonar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5, 6] in '', [0, 2, 1, 3, 4, 5, 6] in 'wght=900.0'
Glyph peh_rehar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [1, 0, 2, 3, 4, 5] in 'wght=900.0'
Glyph peh_yehHamzaabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [0, 1, 4, 2, 3] in 'wght=900.0'
Glyph peh_yehar was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [0, 1, 2, 5, 3, 4] in 'wght=900.0'
Glyph peh_zainar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5, 6] in '', [1, 0, 2, 3, 4, 5, 6] in 'wght=900.0'
Glyph theh_yehHamzaabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [0, 1, 4, 2, 3] in 'wght=900.0'
Glyph threedotsdownabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2] in '', [1, 2, 0] in 'wght=900.0'
    Contour 1 start point differs: 0 in '', 10 in 'wght=900.0'; reversed: False
Glyph twodotsverticalabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1] in '', [1, 0] in 'wght=900.0'
Glyph uniFC13 was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3] in '', [0, 3, 1, 2] in 'wght=900.0'
Glyph uniFC14 was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [0, 1, 2, 5, 3, 4] in 'wght=900.0'
Glyph uniFC6D was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [1, 0, 2, 3, 4] in 'wght=900.0'
Glyph uniFD1E was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [2, 0, 1, 3, 4, 5] in 'wght=900.0'

This report was generated using the fonttools varLib.interpolatable tool. We understand that sometimes the tool generates false-positives. Particularly for more complicated font designs. If you did not find this report useful, please apologize and ignore & close it.

To give feedback about this report, please file an issue or open a discussion at fonttools.

Micah reported:

Problem Description
The same font when rendered at 12px, in browsers (in this particular example Firefox 102.0.1), the font renders with a wrong height in Linux, as opposed to windows.

demonstration
screenshots from Google Fonts website, Rubik font, size 12px:

It is clear that in Linux the height of the letters are lower than rendered in Windows 10.

The same rendering issue also happens with Chrome (and IE11 too).

NOTE: Other sizes (apart from 12px) seems to render at the same size/height.

Also, if the size of font is set at 12**.1**px (0.1px more), the height in Linux renders correctly.

I have a website using Rubik. Some users report that the letter "c" is rendered as an "o" in Chrome. And it becomes a "c" when the page is zoomed in.

Here is a screenshot (enlarged):

Does this have something to do with ClearType?

And any advice on how to avoid it?

Thank you very much!

@alexeiva
Hi Alexie,

A note to let you know that we have made the outlines compatible for Rubik and have generated a beta variable font in the "fea-ufo-conv" branch of the repo fork.

https://github.com/TypeNetwork/rubik/tree/fea-ufo-conv

We have used the Glyphs source data on this repo as the original masters.

Best,

Jill

: : :

Hello Phillip, Sebastia, Meir and Alexei,

The Google fonts team would love to see a variable fonts version of ‘Rubik'. They have commissioned us @TypeNetwork to work on upgrading a number of font projects to be variable fonts with a single weight axis.

In order to achieve the highest quality and most efficient long term results we will be converting the source data from Glyphs to UFO. The new source data will be generated in the RoboFont environment using fontmake and ttfautohint. There has been progress on tools to make an easy path to move between the Glyphs and Robofont environment.

During the process we will be looking to improve any errors while preserving how the font appears and renders on different platforms.

We have started by making a fork off of this git repository. The upgrade will be completed for you in the near future. When the proposed final font is approved by Google they will accept a pull request.

We hope this answers some of your questions about the process. Please let us know if you have any additional comments.

Best Regards,

Jill Pichotta
Vice President
Type Network
[email protected]

Comb accents have anchors but a lot of letters are missing some (mostly lowercases)

A nice set of devanagari typesets can be included in this font?
Considering user base and other criteria of eligibility!

The spacing between "i" and "n", and "i" and "s" in bolder fonts doesn't look too good:

Seems they're not visually consistent with everything else

Here's how it could look, which I think is improved:

I'm also not a fan of the ligature between f-i, also reported in #42 - but I guess that's subjective.

For example,

Rubik

SF Arabic

As you can see, the dots of the Arabic letter "Ya" are so close to the letter "Raa" in Rubik vs SF Arabic. This is also more noticeable "an issue" at smaller font sizes.

I have noticed that the inverted exclamation mark (¡, U+00A1) is not spaced properly on italics. Could you fix it?

See the screenshot below:

Also, a U+FDF2 ligature is needed here.

Rubik is missing the INR symbol. Can you add ₹ to this font family?

Even since the June 2023 updates, line-height:normal is far too big on some devices. line-height:normal seems closer to 2.2 than 1.2.

More specifically,
https://fonts.gstatic.com/s/rubik/v28/iJWKBXyIfDnIV7nBrXw.woff2 is broken (v28)
but
https://fonts.gstatic.com/s/rubik/v26/iJWKBXyIfDnIV7nBrXw.woff2 works correctly. (v26)

Link: https://fonts.google.com/specimen/Rubik
See screenshot:

Left side: (Normal)
Normal 1080p Desktop PC
Chrome
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

Right side: (Too large. Line-height is closer to 2.2 than 1.2)
AWS Workspace (Resizable screen) (I'm pretty sure this is a Virtual Machine)
Chrome
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

I'm... having a hard time narrowing down the possible causes, or creating a reproducible test-case, but this seems to be a regression of the font itself:

1. It doesn't occur the older version of the font.
2. It doesn't occur with other fonts.
3. It doesn't occur in Firefox, only in Chrome.
4. It occurs on the official font website: https://fonts.google.com/specimen/Rubik

I'm... not sure how to provide enough information to create a reproducible test-case, but if I can provide any more information, I'll be more than happy to. (I... don't THINK it's a problem with Windows 10's font scaling, but I can't figure out what else might be different.)

Rubik from google fonts does not support extended cyrillic glyphs

Rubik doesn't show up in the typeface list in either PowerPoint or Keynote on Mac. I tried with both the font files from Github and Google Fonts, both variable and static versions. It works in other applications, such as Adobe CC.

MacOS 14.2.1
Microsoft PowerPoint 16.81
Apple Keynote 13.0

The font looks awesome and the question in the Subject-line arises quite naturally.

If funding is required let's start the campaign.

hatafsegol-hb, U+05B1 should look something like this:

But in the file Rubik.glyphs the dots are overlapping creating a blob that displays an incorrect shape on the Google Fonts site:

The same problem exists for all Hataf Hebrew diacritics, hatafsegol-hb hatafpatah-hb hatafqamats-hb in both the regular and italic styles.

This issue was first reported in the Google Fonts Project Template repo: googlefonts/googlefonts-project-template#85

All Latin Extended glyphs should be kerned. For example, if T has no accent and o has a double acute, the small o can keep the same positioning since the small o and their Latin-1 accented letters are already kerned.

Hi guys,
Some currency icons are not supported in the font family. Some of them are as follows; Turkish lira( ₺), United Arab Emirates ( د.إ ) etc.

Can you update your font family on this issue?

Thank you very much!

Hey @m4rc1e, I'm trying to figure out where things went awry and I noticed that the build script produces a broken glyf table: it won't complile in VTT and that's the complaint. On the other hand, it passes MS fontval. I'm going to dig into this and this issue is essentially my notes.

Probably not Chrome problem, as the problem is on several websites and two computers each one with different Chrome version. Other fonts also work OK.

Hello!

This is an automatically-generated report about possible interpolation problems in Rubik[wght].ttf, as found in the Google Fonts catalog.

The particular version of the font that was tested was archive:.

To download a PDF version of this report with helpful visuals of the problems, click here; Or to view it on the GitHub website, click here.

The report follows:

Glyph peh_alefMaksuraar was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3] in '', [0, 3, 1, 2] in 'wght=900.0'
Glyph peh_noonar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5, 6] in '', [0, 2, 1, 3, 4, 5, 6] in 'wght=900.0'
Glyph peh_rehar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [1, 0, 2, 3, 4, 5] in 'wght=900.0'
Glyph peh_yehHamzaabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [0, 1, 4, 2, 3] in 'wght=900.0'
Glyph peh_yehar was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [0, 1, 2, 5, 3, 4] in 'wght=900.0'
Glyph peh_zainar.fina was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5, 6] in '', [1, 0, 2, 3, 4, 5, 6] in 'wght=900.0'
Glyph theh_yehHamzaabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [0, 1, 4, 2, 3] in 'wght=900.0'
Glyph threedotsdownabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2] in '', [1, 2, 0] in 'wght=900.0'
    Contour 1 start point differs: 0 in '', 10 in 'wght=900.0'; reversed: False
Glyph twodotsverticalabovear was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1] in '', [1, 0] in 'wght=900.0'
Glyph uniFC13 was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3] in '', [0, 3, 1, 2] in 'wght=900.0'
Glyph uniFC14 was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [0, 1, 2, 5, 3, 4] in 'wght=900.0'
Glyph uniFC6D was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4] in '', [1, 0, 2, 3, 4] in 'wght=900.0'
Glyph uniFD1E was not compatible:
  Masters: '', 'wght=900.0':
    Contour order differs: [0, 1, 2, 3, 4, 5] in '', [2, 0, 1, 3, 4, 5] in 'wght=900.0'

This report was generated using the fonttools varLib.interpolatable tool. We understand that sometimes the tool generates false-positives. Particularly for more complicated font designs. If you did not find this report useful, please apologize and ignore & close it.

To give feedback about this report, please file an issue or open a discussion at fonttools.

when settings: text-align: justify in the CSS, it seems that extra spaces are added within some words of the text.

They look very odd to myself (Danish is my native language) and also asked a bunch of other designers that agreed. We never do an ø or Ø like that other than maybe some display/logo fonts 🙃

It's the equivalent of having e.g. a slanted crossbar on a t or something.

It would look much more in place if the slash goes from bottom left to top right corner. Also would still kinda fit the typeface I'd think.

Let me know if you accept a PR and I'll fix it.

Cheers