-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PPEM axis: programmatic interaction & UI #18
Comments
@PeterCon |
Changes of the Suggested programmatic interactions and UI recommendations section: Suggested programmatic interactions: A proper rasterizer should pass zero, representing “Ignore pixel alignment”, or a positive integer, strictly equal to the current PPEM value when rasterizing the glyphs in the font. When a positive The logic of rasterizers could be described as the code below:
UI recommendations: This axis should be hidden from direct user-selection in UI, and the In some special cases, like a user interface designing software, applications could provide some control to let user to select the PPEM value, but the value should be restricted to integers, and the application must properly interpret the TrueType or CFF hints when the value user selected being non-zero. The PPEM used in interpreting hints should be equal to the value the user selected. |
For suggested PI, do you want to expand a bit to add the following (without the added emphasis)? "It is recommended that this value be set by the rasterizer to the current PPEM value, and that text selection and layout processes leave this set to zero." Also, a minor point on wording: I find the wording "pass a value to the axis" a bit confusing: it makes it sound like the axis is an active agent that will take some action on the value passed to it. But in this case, it's the rasterizer that will be taking action. So, I'd be inclined to use wording like "set the axis value". |
@PeterCon UPDATED VERSION: Suggested programmatic interactions: A proper rasterizer should set When a positive The logic of rasterizers could be described as the code below:
UI recommendations: This axis should be hidden from direct user-selection in UI, and the In some special cases, like a user interface designing software, applications could provide some control to let user to select the PPEM value, but the value should be restricted to integers, and the application must properly interpret the TrueType or CFF hints when the value user selected being non-zero. The PPEM used in interpreting hints should be equal to the value the user selected. |
I think the PPEM axis may be of limited interest for people who develop otherwise "static" fonts, as they may be interested in employing traditional hinting techniques for reasons of backwards compatibility. But I think the PPEM axis can be very interesting for various fonts that also have other axes — hinting variable fonts is not yet a "solved" problem, and it's somewhat unclear how one would hint in complex situations. But with the PPEM axis, a designer could easily intervene on a per-glyph basis when some important adjustments are needed in a particular region of the design space. |
@twardoch |
In the proposal summary for the PPEM axis, the fields in the Proposed Axis Details section for programmatic interaction and UI seem to suggest that in some situations the value for this axis might be selected directly by a user, or indirectly by some UI that doesn't obviously directly affect ppem used in text display.
For programmatic interactions, wouldn't it be appropriate to say this should always be set at a point in layout or rendering when PPEM is known, possibly in the rasterizer itself?
"This axis should be hidden from direct user-selection in UI if it is used for implementation of other user-selectable settings such as tracking. If the axis becomes adopted for use in implementation of tracking features in applications, then use of the HIDDEN_AXIS flag in the 'fvar' table should be considered for this axis."
It's not clear how this is related to tracking. If that is what is intended, then that needs some clarification (perhaps in the add'l info field).
Wouldn't it make sense for the HIDDEN_AXIS flag to always be set?
If it's suggested that some software implementations would set a value for this axis in the rasterizer, or some point after layout, shouldn't there be a strong recommendation that this never affect glyph metrics? (That could be added to the add'l info field.)
The text was updated successfully, but these errors were encountered: