Closed skef closed 3 months ago
skef
commented
3 months ago 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
commented
3 months ago 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:
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:
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"?