[MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements (?) in variable fonts

[Skef Iterum]

I'll update the document to remove the use of "master". I meant 
instance, in this case.

Whether adopting this proposal would require a change in how CFF2 
rasterizers are implemented depends on how they were implemented before. 
I've seen some code that trusts that stems arrive sorted and some code 
that doesn't (the latter either resorting and doing something clever 
with the masks or just going through the list to find the best match 
every time). And if code only looks at "active" stems when matching, 
there should only be one active stem with a given position and width, so 
duplication wouldn't matter.

So it boils down to the particular heuristics of the particular 
implementation.

Skef

On 2/5/24 12:43, Peter Constable wrote:
> Hi, Skef
>
> The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data.
>
> In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.
>
>
> A question about this: I gather that this would require changes in CFF2 rasterizers?
>
>
> Peter
>
> -----Original Message-----
> From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
> Sent: Monday, February 5, 2024 3:23 AM
> To: mpeg-otspec at lists.aau.at
> Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts
>
> A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.
>
> Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.
>
> We can talk about versioning questions as part of the discussion.
>
> Skef