Open davelab6 opened 3 months ago
I have been able to produce the ttf.ttc and ttf.ttc.woff2 files and have put them in a shared Drive. I can't produce OTFs because:
I think we will need to get the different designspace ranges OTFs generated for us by Adobe.
Is the main purpose for systems that only load the default? I did a quick test on Source Han Sans that isn't 100% correct yet, but just to see the OTF goes from 30.8MB to about 39MB. If you really want I can do a correct one for Noto Sans CJK.
Yes, exactly - unity and unreal engine don't support VF and so get the zero origin default, which is 100. The 8mb increase is worth paying to bridge the gap from here to them shipping VF support :)
If you really want I can do a correct one for Noto Sans CJK.
It looks like we would appreciate versions of Noto Sans and Noto Serif CJK with 400-900 range.
I hope this is just a temporary change, as it causes 100-300 font weights to not display properly in other apps.
This is just for internal testing. You shouldn't be installing them anywhere.
@simoncozens as a priority today please could you make the following font files for evaluation in systems like games made with game engines that don't support VF yet, and therefore load the 100 weight only, because that's the zero origin with a single interpolation to the 900:
NotoSansCJK with 100-900 weight range with 100 as zero origin weight (current build default, but made fresh so it's an exact comparison)
NotoSansCJK with 100-900 weight range with 400 as zero origin weight, by adding an instance and inserting it back into the design space I guess. Not sure if the fonttools.instancer can do that in a straightforward way, I think so.
NotoSansCJK with 400-900 weight range with 400 as zero origin weight, by subspacing in a typical way.
For each of those, having otf.ttc, ttf.ttc, and ttf.ttc.woff2 files for the comparison would be ideal.