Open anthonymoretti opened 1 year ago
HylkeReinders
commented
1 year ago Hi Anthony,
Just checked your screenshot and i didn't see a difference when checking the widths in Figma.
For the black:
For the White:
What I do see is that with the black text we have a dark border and that is the same for the white text color. That could be lighter? So it looks like the same width?
anthonymoretti
commented
1 year ago Hi Hylke
Thanks for looking into it. Yeah the border color in both light and dark modes needs to be darker, otherwise it looks like the weights are off. The change is especially noticeable when switching from light mode to dark mode and vice versa.
The border color of the letter "h" is a good example. If you compare the border color of each "h" to the one below it you can see how the border color of the bottom one is too light in both cases. If it could be changed to match the border color of the "h" above it that would fix it I think.
huycozy
commented
1 year ago Hi @anthonymoretti Can you please provide screenshots for the comparison between Flutter and iOS native? Honestly, I've tried to look closely but haven't noticed the difference yet. Should I pay attention to the border of the letters?
anthonymoretti
commented
1 year ago Hi @huycozy Yes, it's the border of the letters, which is too light in both light and dark modes. It creates the effect that text is too thin in light mode and too bold in dark mode.
Here are the screenshots:
| iOS Mail - light mode | iOS Mail - dark mode | Flutter |
|---|---|---|
 |
 |
 |
delfme
commented
1 year ago @huycozy please focus on the leg of "i" or on "k". First row (the thicker one) is native.
I couldn't test and it is not clear if the issue affects only skia, impeller or both engines. However, I remembered this fix landed lately and it would be worth double-checking things work properly on Impeller https://github.com/flutter/flutter/issues/118613
anthonymoretti
commented
1 year ago Hi @delfme. This is with Impeller enabled, but I think it existed before too.
anthonymoretti
commented
1 year ago I realize it might be hard to see, so thought I'd try to make it easier. This is with Impeller, but I think it might have existed before too.
huycozy
commented
1 year ago Thank you guys for more information. I double-check this and see that it's easier to see this issue in dark mode especially.
| 
| 
But as @delfme mentioned above, this seems to be fixed with Impeller:
| Flutter Skia | Flutter Impeller |
|---|---|
 |
 |
@anthonymoretti Can you retry on the latest master channel with Impeller and check if see the same result?
anthonymoretti
commented
1 year ago Thanks for looking. I tried on the latest master with Impeller now but it's identical to stable. A second very minor thing, in Flutter there appears to be an extra pixel between "k" and "b", so the total line length is different by one pixel.
The reason I noticed the problem in the first place is because the text in my app appears thinned out in light mode compared to dark mode, and it seems to be because of a font weight imbalance between the modes.
huycozy
commented
1 year ago Labeling the issue for the team's attention since the issue is also happening on skia (see https://github.com/flutter/flutter/issues/120857#issuecomment-1434118870 or above comments for the demo)
anthonymoretti
commented
1 year ago Can anyone suggest a workaround for this, or is it at all possible to make this P3?
For example, is there a way to access font weights between the existing constants? I could probably work around it if I could access values like FontWeight.w450 in light mode and FontWeight.w350 in dark mode (not necessarily those exact values, it would take experimenting).
The app looks washed out because of thin text in these two scenarios especially:
delfme
commented
1 year ago @anthonymoretti although maybe doable, the font variable trick is not a correct solution.
Idk how this is coded at engine level, but I guess fix should be just increasing/reducing an opacity value such that font border color will look darker in lightmode and lighter in darkmode. If so, it would take a few min.
anthonymoretti
commented
1 year ago @delfme Counterintuitively, the border needs to be darker in both modes 😉
delfme
commented
1 year ago Oh yes my bad. So fix is simpler coz we don’t need to distinguish between cases 👍
andrewescutia
commented
10 months ago Hi, I too am seeing the issue referenced in #127810 and was wanting a bit of clarification on how this will proceed. For the time being we have disabled the Impeller engine within our app as it has reduced the readability on some of our pages. I am uncertain if Impeller will be left as is since it appears it is closer to how native iOS renders text or if it will be adjusted to mirror Skia rendering. If the decision is to leave as is then we will proceed with adjusting font sizes, weights, etc. within our app to accommodate the change.
Thanks.
romanr
commented
8 months ago Isn't this a well-known perceptual issue, and it should be remedied by adjusting font-weight in dark modes?
Therefore it may be a higher-level issue, for Material 3?
Even if border/antialiasing is adjusted, it will still be perceptually different. When looking at a dark background with white text, the eye is more open and receptive to light, making any white text elements appear thicker than they actually are.
anthonymoretti
commented
8 months ago @romanr Yes it is, it's even discussed in the Material Design icons guidance, where they reduce the grade for light icons on a dark background: https://m3.material.io/styles/icons/applying-icons#3ad55207-1cb0-43af-8092-fad2762f69f7
But regardless of perception, if you look at the comparison between native iOS and Flutter in my earlier comment-1433892871 you can see an actual imbalance in Flutter.
delfme
commented
8 months ago Isn't this a well-known perceptual issue, and it should be remedied by adjusting font-weight in dark modes? Therefore it may be a higher-level issue, for Material 3?
Even if border/antialiasing is adjusted, it will still be perceptually different. When looking at a dark background with white text, the eye is more open and receptive to light, making any white text elements appear thicker than they actually are.
It is not eyes trick.
delfme
commented
7 months ago Tested it thoroughly at pixel level and confirm @anthonymoretti discovery. Text is too thin in lightmode and too thick in night mode. In light mode, where there is no impact from a dark background, is evident with bare eye on my iphone pro 13, ios 16.3.1
Cant we just add to border 0.X px in light mode and subtract 0.X px in dark mode? Might this be caused by flutter engine current limits with hairlines?
delfme
commented
7 months ago Fixed this. Just a temporary workaround.
Instead of
Text.rich(
overflow: overflow,
maxLines: maxLines,
style: _textStyle,
CustomTextSpan(
text : $text,
style: _textStyle,
overflow: overflow,
maxLines: maxLines,
),
),Do this: put 2 texts inside a Stack, one will draw outerborder (adding the required extra px to make it thicker), and one will draw the inner color.
Stack(children: [
// Draw the inner color
Text.rich(
overflow: overflow,
maxLines: maxLines,
style: _textStyle,
CustomTextSpan(
text : $text,
style: _textStyle,
overflow: overflow,
maxLines: maxLines,
),
),
// Draw the outline border
Text.rich(
overflow: overflow,
softWrap: true,
maxLines: maxLines,
style: _textStyle.copyWith(
foreground: Paint()
..style = PaintingStyle.stroke
..strokeWidth = 0.1
..color = Colors.black,
),
CustomTextSpan(
text : $text,
style: _textStyle,
overflow: overflow,
maxLines: maxLines,
),
),
],);Final result will be a ticker text.
Here is a result (second pic is thicker text):
To reproduce same fix for dark mode, the outerborder color must be the one assigned to the parent widget's background color. This way the text will look thinner.
ManuelRauber
commented
3 months ago For example, is there a way to access font weights between the existing constants? I could probably work around it if I could access values like
FontWeight.w450in light mode andFontWeight.w350in dark mode (not necessarily those exact values, it would take experimenting).
@anthonymoretti Depending on your font, you actually can. And I suspect, depending on the font, using FontWeight is wrong to change the weight of the font.
In my app, I'm using the "Inter" font, which is a variable font face. I did not read much on the Flutter typography page so I was using FontWeight to change the weight of the font.
However, I noticed, that w400 and w500 renders the exact same text. I used an image diff to check and there where no difference at all. I was going to open an issue for that.
But then I read on the documentation again:
When programming a variable font, use the FontVariation class to modify the font’s design axes. The FontVariation class conforms to the OpenType font variables spec.
Then, when you read for static fonts:
Use the following API to programmatically alter a static font (but remember that this only works if the font was designed to support the feature):
FontFeature to select glyphs FontWeight to modify weight FontStyle to italicize
For the variable font, FontWeight is not mentioned, so I suspect using that is not the right approach.
For testing I switched FontWeight.w500 (again, which did not result in a different rendering) to fontVariantions: [FontVariation('wght', 500)] and... it rendered in 500!
Since the font is variable, you can have any weight, like 450 or even 411 if you prefer that.
While there is possibly still an issue with font rendering overall, using the font variations correctly to bump the font weight a tiny bit seems much better then the double rendering workaround by @delfme
delfme
commented
3 months ago @ManuelRauber is San Francisco font variable? Have you got to use a variable font to workaround this issue? Coz result might not be as expected.
The fact is that text on iOS is broken in several minor aspects that all impact for their part. We created a TextWidget where we heavily manipulate text before rendering, not just the outline border mentioned above, but also letterspacing and height. And things get trickier when emojis are inside the text, coz they must be manipulated too in size, height, offset, letterspacing, and also padding (coz emoji on iOS are off-centered).
Until flutter team gets to fix text as a whole, we think there is no easy solution to that problem. Indeed, on iOS I can tell that an app is built in flutter only by looking at text. Involved issues have been open for 2-4 years, hence the fix is tricky and we cannot expect it anytime soon.
anthonymoretti
commented
3 months ago For example, is there a way to access font weights between the existing constants? I could probably work around it if I could access values like
FontWeight.w450in light mode andFontWeight.w350in dark mode (not necessarily those exact values, it would take experimenting).@anthonymoretti Depending on your font, you actually can. And I suspect, depending on the font, using FontWeight is wrong to change the weight of the font.
In my app, I'm using the "Inter" font, which is a variable font face. I did not read much on the Flutter typography page so I was using
FontWeightto change the weight of the font.However, I noticed, that
w400andw500renders the exact same text. I used an image diff to check and there where no difference at all. I was going to open an issue for that.But then I read on the documentation again:
When programming a variable font, use the FontVariation class to modify the font’s design axes. The FontVariation class conforms to the OpenType font variables spec.
Then, when you read for static fonts:
Use the following API to programmatically alter a static font (but remember that this only works if the font was designed to support the feature):
FontFeature to select glyphs
FontWeight to modify weight
FontStyle to italicize
For the variable font,
FontWeightis not mentioned, so I suspect using that is not the right approach.For testing I switched
FontWeight.w500(again, which did not result in a different rendering) tofontVariantions: [FontVariation('wght', 500)]and... it rendered in 500!Since the font is variable, you can have any weight, like
450or even411if you prefer that.While there is possibly still an issue with font rendering overall, using the font variations correctly to bump the font weight a tiny bit seems much better then the double rendering workaround by @delfme
Thanks @ManuelRauber, unfortunately I'm using San Francisco.
zhangwen0510
commented
1 month ago Any updates?
zhangwen0510
commented
2 weeks ago Any updates, this feature is really important
Steps to Reproduce
flutter runon the code sample.Expected results: The font weights look the same.
Actual results: The font weight in Flutter is too light in light mode and too heavy in dark mode. This makes the app look quite different in one mode compared to the other.
Code sample
```dart import 'package:flutter/material.dart'; void main() { runApp(const MainApp()); } class MainApp extends StatelessWidget { const MainApp({super.key}); @override Widget build(BuildContext context) { return MaterialApp( home: Scaffold( body: Column( mainAxisAlignment: MainAxisAlignment.center, children: [ Container( alignment: Alignment.center, height: 56.0, child: const Text( 'The quick brown fox jumps over the lazy dog', style: TextStyle( color: Colors.black, fontSize: 17.0, letterSpacing: -0.43, ), ), ), Container( alignment: Alignment.center, color: const Color.fromRGBO(28, 28, 30, 1), height: 56.0, child: const Text( 'The quick brown fox jumps over the lazy dog', style: TextStyle( color: Colors.white, fontSize: 17.0, letterSpacing: -0.43, ), ), ), ], ), backgroundColor: Colors.white, ), ); } } ```