Comments (2)
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:
- 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.
- 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?
- 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:
- Swap the order of 3 and 4.
- 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.
- If you think it would be helpful I could add some additional text following 1-4 that explains how 3 and 4 interact.
- Swap "high quality" for something stronger in the encoding considerations.
from ift.
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.
from ift.
Related Issues (20)
- Add QUERY as a HTTP method type used for patch subset. HOT 1
- IFT and offline reading HOT 3
- Privacy Considerations says checksum is for error correction
- Condisderation HOT 1
- Can't generate html HOT 5
- Compremised
- Rewrite explainer HOT 6
- Different URL ID encoding HOT 13
- Partial invalidation brotli patches? HOT 1
- Mixing patch types and GID "management" HOT 2
- Aspects of streamed decoding on the client side
- Possible "all other codepoints" semantic? HOT 4
- Wide Review of 9 July WD of IFT HOT 8
- Security self-review answers for 9 July 2024 WD of IFT
- I18n checklist answers for 9 July WD of IFT
- Document serializing/caching of patched font HOT 3
- Should we require Erroring on Validation Requirements for Format 1 Patch Map? HOT 6
- Consistently use `code point` instead of sometimes saying `codepoint` HOT 2
- Considerations for "desiccated" initial font files HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ift.