Open davelab6 opened 1 month ago
behdad
commented
1 month ago Baseline variation should in theory be possible with BASE table, though we have not updated the spec for it.
Changing UPM was decided as not supported, as it introduces so many issues (for starters, it's assumed currently in APIs that a face has an integer UPM that doesn't change).
dberlow
commented
1 month ago If supporting the base table allows the base table data to be defined for a design space, i.e. to be stored for each style according to the user axes at least, then that’s fine.There is a simpler possible definition of a “resolution axis” where the upm does not vary, but the styles along the axis represent contours located to render/animate at a particular ppm. On Jul 23, 2024, at 12:31 PM, Behdad Esfahbod @.***> wrote: Baseline variation should in theory be possible with BASE table, though we have not updated the spec for it. Changing UPM was decided as not supported, as it introduces so many issues (for starters, it's assumed currently in APIs that a face has an integer UPM that doesn't change).
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
dberlow
commented
1 month ago Have also shared a doc w/DC about future enhancement ideas.On Jul 23, 2024, at 12:31 PM, Behdad Esfahbod @.***> wrote: Baseline variation should in theory be possible with BASE table, though we have not updated the spec for it. Changing UPM was decided as not supported, as it introduces so many issues (for starters, it's assumed currently in APIs that a face has an integer UPM that doesn't change).
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
@dberlow reminded me today that he recalls back in 2016, in the first call with MS Google and Font Bureau, he had suggested needing to vary the baseline and UPM, which he wants to vary in non latin scripts. Is this possible?
The use case for the baseline is: varying a glyph from its center (such as in hanzi, where the center of glyphs is the center of a square glyph) and adjusting the baseline to stick to the bottom of the glyph. Eg, matching Chinese to Arabic.
The use case for the UPM is: When you have varc, the range of the components changes over the resolution spectrum, so say you have a 64 axes atomic component for hanzi, and you target a res below 40 px per em square, there is a limited space for all the strokes, so you may want to cut down on the strokes. With a UPM axis, you can adjust the compositing over the range along with opsz: opsz is going down and the resolution is going down too. The UPM axis would allow for hinting-like design, ranging from say 7 (for sans, 8 for serif) "pixels per em square" up to 128. And allowing different masters to have different UPMs, to match this, the file size can be compacted because the point coordinates don't require unnecessary precision.
There are 'bad nodes' where rounding doesn't work out well, so 12-18 there are say 2 bad nodes in a glyph, and so the outline can be scaled to a pixel grid that works.