Encoder requirements questions/issues

[skef]

On 3: This needs more explanation. I get that we're using consistency with the fully expanded font as the measure in order to avoid talking about an "original font" in this requirement, but we need to prep the reader for that a bit better. And given that 3 and 4 mirror each other it would probably be better to put what is 4 now first and then start what is 3 now with "when not starting from an existing font file..." or "In other cases ...".

On 3 and 4 more generally: Reading these again I don't understand why requirement 4 is acceptable "as a requirement" at the same time there is resistance to having the more general same-behavior clause be a requirement. I thought the worry was about more "abstract" uses of the protocol, which might stray from strict duplication of behavior WRT a given font. But here in 4 we're saying that if you start with an existing font the fully expanded version must be behaviorally identical. Why is it OK to require that? And, if it is OK, why is it not OK to have a behavioral requirement on incremental patch levels "when an encoder is used to transform an existing font file"?

[skef]

Some more on this: I think the current draft is still way too vague and mushy about functional equivalence. E.g. the sentence "As discussed in [[#encoding]] a high quality encoder should preserve the functionality of the original font.". This is much too soft. "high quality" makes it sound like this is a nice-to-have virtue rather than something that should be true of virtually every encoder in practice.

[garretrieger]

On 3: This needs more explanation. I get that we're using consistency with the fully expanded font as the measure in order to avoid talking about an "original font" in this requirement, but we need to prep the reader for that a bit better. And given that 3 and 4 mirror each other it would probably be better to put what is 4 now first and then start what is 3 now with "when not starting from an existing font file..." or "In other cases ...".

Agreed that we probably want to switch the order of 3 and 4. However, the current 3) doesn't apply only in the case where there is no original font. 3 and 4 are meant to work together, the intention of them is this:

3. This ensures that a partially patched font will have consistent behaviour with whatever the end state (fully expanded font) is. That is when the font is partially patched (not fully expanded) then for any content that is a subset of the subset definition that partial font should have the same rendering behaviour as the fully expanded font.
4. In the case where there is an original font this adds an additional condition which ensures that the end state is equivalent to the original font.

Putting both together in the case where there is an original font then implies that the IFT font will behave the same as the original font at any level of patching. Where there isn't an original font only 3 applies and ensures that you get consistent behaviour with whatever the fully expanded state is throughout the patching process.

On 3 and 4 more generally: Reading these again I don't understand why requirement 4 is acceptable "as a requirement" at the same time there is resistance to having the more general same-behavior clause be a requirement. I thought the worry was about more "abstract" uses of the protocol, which might stray from strict duplication of behavior WRT a given font. But here in 4 we're saying that if you start with an existing font the fully expanded version must be behaviorally identical. Why is it OK to require that?

3. and 4) are both "should" level requirements and so they are strongly encouraged but not mandatory. This allows the freedom for the more abstract uses.

And, if it is OK, why is it not OK to have a behavioral requirement on incremental patch levels "when an encoder is used to transform an existing font file"?

We do have behavioural requirements on incremental patch levels in a case with an original font via 3). We explicitly link 3 and 4 together in the text following 1-4 which explains that to be a neutral encoding with respect to an original font both 3 and 4 are required together:

"If an encoder produces an encoding from a source font which meets all of the above requirements (1. through 4.), then the encoding will preserve all of the functionality of the original font."

How about the following changes:

1. Swap the order of 3 and 4.
2. Update the current 3. with some additional text at the start to clarify that this is preserving functionality of the fully expanded font throughout the patching process.
3. If you think it would be helpful I could add some additional text following 1-4 that explains how 3 and 4 interact.
4. Swap "high quality" for something stronger in the encoding considerations.