Difference in colour between variable and static builds
simoncozens opened this issue · comments
Prerequisites
- If you are reporting an issue that affects glyphs for characters for a particular region or regions, did you verify that the characters are within the supported scope of the region or regions? This generally means GB 18030 or Tōngyòng Guīfàn Hànzìbiǎo (通用规范汉字表) for China, Big Five or CNS 11643 Planes 1 & 2 for Taiwan, HKSCS-2016 for Hong Kong, the JIS standards for Japan, and KS X 1001 and KS X 1002 for Korea.
- Did you thoroughly search the open and closed issues to avoid reporting a duplicate issue?
- Did you go through the official font readme file to better understand the scope of the project, to include the Known Issues section at the very end?
Description
This is something we noticed when preparing the Noto build of the font for onboarding to Google Fonts. Odd lines are
Serif/OTF/Japanese/NotoSerifCJKjp-Regular.otf, even lines are Serif/Variable/OTF/NotoSerifCJKjp-VF.otf at wght=400:
Note especially the strokes of hiragana た、に、で.
I don't know if it's a hinting issue, but this was rendered with Safari on macOS.
Just so we know what sizes did you use here? At larger sizes I can't see any problem and if you check the actual fonts there's no issue. It seems to only be from rendering at smaller sizes. I removed hinting from the static and compared and it still looks the same so doesn't seem to be hinting, but definitely something odd with the variable fonts. I tried both the CFF2 and TTF VFs and they both look off in some places in the browser.
The image above was created with the following HTML:
<html>
<head>
<style type="text/css">
@font-face {
font-family: "NSC";
font-weight: 400;
src: url(../Serif/Variable/OTF/NotoSerifCJKjp-VF.otf);
}
@font-face {
font-family: "OTF";
src: url(../Serif/OTF/Japanese/NotoSerifCJKjp-Regular.otf);
}
.old { font-family: "OTF"; }
.new { font-family:"NSC"; }
</style>
</head>
<body>
<div class="old" style="font-size:20px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:20px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:25px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:25px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:30px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:30px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:35px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:35px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:40px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:40px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:45px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:45px">ABC かさた かきく たちつ にので</div>
<div class="old" style="font-size:50px">ABC かさた かきく たちつ にので</div>
<div class="new" style="font-size:50px">ABC かさた かきく たちつ にので</div>
</body>
</html>
It seems to be path direction. I checked に and た just to see and they had wrong directions on the contours that appear lighter. I fixed those and rebuilt and then they look fine.
Nice. Please also check the ten-tens on だぢづでど etc.
It seems to be path direction
Are you referring to the old recommendation to set contour direction to counter-clockwise for postscript outlines?
if confirmed, this would be the first time that I actually see path direction having any impact whatsoever, and quite a visible one.
Yep, good ol' counter-clockwise for PS. Here's a quick test I did with just に. Top line is TTF variable and bottom line is OTF static. The left contour is clockwise on the left glyph and counter-clockwise on the right glyph. It only displays differently when it's clockwise.
you said the top is a TTF variable. but doesn't TrueType spec recommend clockwise for top-level contours?
I'm talking about the cubic sources. The TTF should get reversed in the build process.
But it shows up in both CFF2 and TTF variable fonts. I'm surprised it shows up so visibly and also that this hasn't come up in a big way before.
that's quite amazing... The screenshots are from Safari on macOS, right?
Does it behave the same, say, inside Adobe desktop apps?
I see the same in Safari and Chrome on macOS. I don't know if it does it anywhere else, but with the original VF builds I tested in Adobe apps to compare layout between static and VF and never saw anything like this.
I'm totally confused now. It's been a while since I looked at this, but with the "correct" path directions I'm seeing the CFF2 lighter, but the variable TTF and static OTF seem ok. Firefox seems fine for all, but Chrome shows lighter CFF2 no matter the path direction.
Ok, so there are at least two problems here.
Problem 1
The original point of this issue I believe: If the path direction is "wrong" then the text is lighter in spots which just happens to show up really well with some kana. In all browsers? Definitely in Safari, but checking in Chrome runs into the next problem...
Problem 2
Chrome displays the CFF2 lighter no matter what. Here's what I see with the latest on macOS 13.4.1. Safari (16.5.2 (18615.2.9.11.10)) seems pretty consistent in color. Chrome (115.0.5790.114) shows the CFF2 lighter.