Skip to content

Commit

Permalink
New Android deliverables
Browse files Browse the repository at this point in the history
  • Loading branch information
@simoncozens
simoncozens committed May 8, 2024
1 parent 5b1d953 commit 07fb9c9
Show file tree
Hide file tree
Showing 6 changed files with 38 additions and 5 deletions.
Binary file added android/NotoSansCJK-wght-400-900.ttf.ttc
View file
Binary file not shown.
Binary file added android/NotoSansCJK-wght-400-900.ttf.woff2
View file
Binary file not shown.
Binary file renamed google-fonts/NotoSansCJK[wght].ttf.ttc → android/NotoSerifCJK-wght-400-900.ttf.ttc
View file
Binary file not shown.
Binary file added android/NotoSerifCJK-wght-400-900.ttf.woff2
View file
Binary file not shown.
43 changes: 38 additions & 5 deletions build-gf.sh
View file
Binary file removed google-fonts/NotoSerifCJK[wght].ttf.ttc
View file
Binary file not shown.

8 comments on commit 07fb9c9

@iKirby
Copy link

@iKirby iKirby commented on 07fb9c9 Jul 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 100-300 are not included in the Android variant? They were available on Android 15 Beta 1 and Beta 2. Starting with Beta 3 100-300 are not displayed correctly.

@cccClyde
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMG_0039

This is how the lockscreen looks like now in Beta 4 so please add 100-300 back. Thanks.

@davelab6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 100-300 are not included in the Android variant?

Because of how Variable Fonts work: They have a 'zero origin master', the typeface design within the glyf table, and then the gvar table provides deltas to vary that design into other designs. Typically there are 2 delta sets for each axis, a min and a max. But to save filesize, it is possible for the zero origin master to be the min, and have an axis with only one set of deltas. Noto Sans CJK has a wght axis set up that way, so that the 'Regular' (400) weight changes from being the one in the the glyf table, to one accessed by processing gvar data to obtain the weight 400 instance.

Apps like games that call the TTF file directly and can not handle Variable Fonts (so they get the glyf table only) therefore get the 100 weight, and this is bad.

It is possible to de-re-compile the TTF to generated the 400 weight and made that the zero origin, then make the wght axis with a min/max, but this increases the file size compared to the original variable font by around 1/3, and 3x the original static font. So in Beta 3, the Variable Font has the 400 as zero origin, and the max added only, no min - so there's no 100..399 axis range, and the filesize is the same as the original variable font, and 2x the static font.

If this lands, then in future it may be possible to either let everyone know a drastic change is coming, with no file size difference, and they better be VF capable to keep showing the 400 weight; or, for the file size to increase again by 1/2 to add the min.

This is how the lockscreen looks like now in Beta 4

It seems to me the clock was always looking like that, then it was looking better with the full range, and then reverted to how it was before. Is that correct?

@cccClyde
Copy link

@cccClyde cccClyde commented on 07fb9c9 Jul 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 100-300 are not included in the Android variant?

Because of how Variable Fonts work: They have a 'zero origin master', the typeface design within the glyf table, and then the gvar table provides deltas to vary that design into other designs. Typically there are 2 delta sets for each axis, a min and a max. But to save filesize, it is possible for the zero origin master to be the min, and have an axis with only one set of deltas. Noto Sans CJK has a wght axis set up that way, so that the 'Regular' (400) weight changes from being the one in the the glyf table, to one accessed by processing gvar data to obtain the weight 400 instance.

Apps like games that call the TTF file directly and can not handle Variable Fonts (so they get the glyf table only) therefore get the 100 weight, and this is bad.

It is possible to de-re-compile the TTF to generated the 400 weight and made that the zero origin, then make the wght axis with a min/max, but this increases the file size compared to the original variable font by around 1/3, and 3x the original static font. So in Beta 3, the Variable Font has the 400 as zero origin, and the max added only, no min - so there's no 100..399 axis range, and the filesize is the same as the original variable font, and 2x the static font.

If this lands, then in future it may be possible to either let everyone know a drastic change is coming, with no file size difference, and they better be VF capable to keep showing the 400 weight; or, for the file size to increase again by 1/2 to add the min.

This is how the lockscreen looks like now in Beta 4

It seems to me the clock was always looking like that, then it was looking better with the full range, and then reverted to how it was before. Is that correct?

No it's not about the clock. Here's the AoD to transition on Beta 2:
b2

And same transition on Beta 3 and 4, but only the numbers have the font weight changing:
codoeutb34te05l6r4hg

Combining what you expained above, it seems that Android is using 'Regular' (100) for English charactors and numbers, but 'Regular' (400) for CJK now. Thus it will look weird when put together from a UI/design perspective.

@cccClyde
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW honestly I don't care about the file size shrinking as a user as long as it fits (like in Beta2). I care about consistency, where iOS just introduced VF font for CJK to make all fonts in system maintaining a closer look and feel, but we still have to see bolder English and numbers along with slim CJK charactors.

@iKirby
Copy link

@iKirby iKirby commented on 07fb9c9 Jul 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your detailed explaination. Now I understand that it is for compatibility.

Apps like games that call the TTF file directly and can not handle Variable Fonts (so they get the glyf table only) therefore get the 100 weight, and this is bad.

But showing text in different weights when they should be the same is also bad.

If this lands, then in future it may be possible to either let everyone know a drastic change is coming, with no file size difference, and they better be VF capable to keep showing the 400 weight; or, for the file size to increase again by 1/2 to add the min.

If there is enough space, why not just increase the size for better user experience and compatibilty?

In my opinion, if there isn't enough space for a compatible solution, system UI font rendering should be prioritized as users are seeing basic UI things much more than playing games. It could also possibly force those game engines to add support for variable fonts, and even if they don't add the support, developers can still just pack a font file in the game.

@tamcy
Copy link

@tamcy tamcy commented on 07fb9c9 Jul 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Dave for the explanation.

I understand the need for BC, and I do appreciate that the team is taking care of it. That said, I hope the team can reconsider this decision, with the following concerns taken into account. Noto Sans CJK was introduced in 2014, and we CJK users have been waiting for ten years (since the release of Noto Sans CJK) to have the ‘faux bold CJK characters’ issue fixed in Android, and I believe most won't want to wait for another ten years for the introduction of ‘Thin to Light’ weights into the system.

What makes it even more painful is that there is comparison. Apple introduced PingFang into its iOS and Mac platform in 2015, with weights of Ultralight (50?) to Semibold (600). In the next release coming this year the family will support Ultralight to Heavy weights (as I saw in https://www.threads.net/@maylogger.vtuber/post/C8GzYcJS1FJ). On the other hand Android users, having bore with this faux bold texts for ten years since its launch, are still struggling to wait for having the full Noto Sans CJK family in an Android phone.

It looks like the current 3 options have its own pros and cons:

Option 1. Offers VF with weight 100-900, with weight=100 as the default

Pro: Least effort. Immediate facelift of CJK character rendering to users.
Con: Font rendering issue for gamers when playing games that reads from the TTF with engine doesn't support VF.

Option 2. Offers VF with weight 400-900, with weight=400 as the default

Pro: Best of both worlds. Immediate facelift of CJK character rendering of all users, without affecting existing code that rely on reading TTF without supporting VF.
Con: Increased file size and maybe memory footprint. 3x the original static font.

Option 3. Offers VF with weight 100-900, make weight=400 as the default.

Pro: Facelift of CJK character rendering with weight > 400 (no more faux bold). Won't break existing native code that reads TTF but not VF support.
Con: Sacrifices overall UX of all CJK Android users, including non gamers.

I can understand why option 1 isn't viable, but I don't understand why option 2 outweighs option 3, that the benefit of UX improvement doesn't worth the increase in file size (and it's just 1/3 larger).

But if file size is the concern, what about handling Sans and Serif differently?

Given (i) Sans is the most accessed typeface in the system and have biggest impact to primary user experience, (ii) Serif is larger in size but is introduced in later version and should be less used by game engines, how about supplying the Sans font in weight 100-900 with 400 as the zero origin, while the Serif version is deployed in its original format? Or, if BC has to be ensured, deploy only the Serif version with 400-900 (or even 300-900 - the difference isn't that much really)? This should reduce the impact of file size increase. You can still announce the change of default zero origin, and bring back the original full weight Sans and Serif with 100 as the origin later.

@WordlessEcho
Copy link

@WordlessEcho WordlessEcho commented on 07fb9c9 Jul 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in future it may be possible to either let everyone know a drastic change is coming

I know that from Android 12, Roboto changed to a variable font but kept a static version for the 400 weight. From Android 14, all weights changed to a variable font. This change wasn't posted on the Android developer site. So, is it temporary for Noto Sans CJK like it was for Roboto?

Additionally, adjusting the ital and wght axes in the font feature settings doesn't work for the system font. Is this intended? (fixed on beta 4)

Please sign in to comment.