googlefonts / roboto-classic

Development of a Roboto Variable font
SIL Open Font License 1.1
150 stars 15 forks source link

Mathematical signs are misaligned #80

Open thlinard opened 3 years ago

thlinard commented 3 years ago

The horizontal bar of + − ÷ should be the same, and aligned vertically (in the middle) with × =.

Particularly visible for the Thin weight:

Roboto Thin

Additionally, the × has display issues at certain sizes or zoom in InDesign 2020. Example with the Regular:

Roboto Regular
davelab6 commented 3 years ago

@thlinard thanks for reporting this; which exact font files are you looking at to see this?

@dberlow points out < and > are different widths... And he and his team will fix all such issues. Please do report :)

Unlike what I said in https://github.com/TypeNetwork/Roboto-Flex/issues/116#issuecomment-679117657 though, we will need to take care that these glyphs retain the same advance widths, but adjusting the glyph's vertical position within that space (or forms) is fine.

davelab6 commented 3 years ago

(I just spoke on the phone to @dberlow about this and he is also very grateful for your report, and will fix anything you can point at :)

mikedug commented 3 years ago

just to add, I have not seen, nor can I repro the broken multiply sign in the Variable Roboto.

Thomas, can I ask, which font is showing this problem? Is the illustration you show, the Roboto Regular font rendering in InDesign?

m4rc1e commented 3 years ago

I think it's a rasteriser issue in Indesign, nothing to do with the font per se.

I was able to replicate it in Indesign but not in a browser.

pichotta commented 3 years ago

The /multiply might have an issue with the start point in the wdth axis. I can re-create it in typetools.typenetwork.com using a combination of wdth and opsz.

RobotoFlex multiply
thlinard commented 3 years ago

My version is Roboto VF 3.002: https://github.com/google/fonts/tree/master/apache/roboto

I'm not very concerned with the display bug in InDesign: some fonts manage to work around it, if you can do that too, fine, otherwise too bad.

On the other hand the bad alignment (/multiply, /minus) worries me more.

m4rc1e commented 3 years ago

I'm not too concerned about this issue atm. The current v2.138 static fonts also have the same issue:

Screenshot 2020-08-24 at 15 58 49

https://fonts.google.com/specimen/Roboto?preview.text=%C3%97%C3%B7%E2%88%92&preview.text_type=custom

Not saying this issue shouldn't be fixed but it can happen once we've successfully pushed the v3.002 update.

thlinard commented 3 years ago

It's up to you to decide which priority to give to the problem, but here is a more complete exposition, with ×<>+÷−¬=≠±≤≥.

Roboto Thin:

Roboto Thin

Roboto Black:

Roboto Black

The vertical alignment needs to be corrected, and the thickness (and somewhat the length) of the horizontal bar of +÷−¬=≠±≤≥ should be the same.

thlinard commented 3 years ago

The same example in Encode Sans VF 3.002 (default or lnum feature) https://github.com/google/fonts/tree/master/ofl/encodesans

Encode Sans
dberlow commented 3 years ago

That’s In flex Jill, thanks, I’m on it.

On Aug 24, 2020, at 10:40 AM, pichotta notifications@github.com wrote:

 The /multiply might have an issue with the start point in the wdth axis. I can re-create it in typetools.typenetwork.com using a combination of wdth and opsz.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.