-
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
Proposal for a "PPEM" axis ('ppem') has been submitted. Please use this thread for general discussion. #15
Comments
This:
combined wit this:
seems to be a contradiction, since hinting seems still required even when the adjustments are made by the |
What about ppem-related changes in the sidebearings? ‘The ppem axis is used to encode deltas that shift points to the place closer to the pixel grid’ seems to include the phantom points. But this may lead to significant differences in text length if e.g. the same text is rendered in a preview on screen and then printed with high resolution. It is like the issues around the |
[Taken from the OpenType mailing list] Interesting! I'm not sure how this will behave size-wise, since adjustments to the grid are certainly not linear; this might lead to quite large gvar tables – essentially, there would be one 'master' per a single ppem value. I would like to see a prototype implemention of, say, a single, simple CJK glyph that demonstrates this proposal. Another issue would be the behaviour for different scaling values along the x and y axis – perhaps also registering |
I can imagine how this axis can be used with FeatureVariations to, eg, switch to simpler forms of CJK ideographs at small sizes. But I don't see how it can be used to perform hinting using glyph deltas, since we have to and do support fractional pixel sizes. So, deltas cannot be used to align stems to grid the way hinting does. |
@behdad: are you talking about fractional PPEM (after scaling), or fractional UPM, or something else? |
Fractional PPEM |
*lemzwerg “...this might lead to quite large gvar tables” I think this is minimal, if reduced by interpolation of untouched points, to only a few deltas per glyph. Besides the fact that people do make big fonts anyway, I think that quality, as a choice, is sometimes to be made over the quantity it may cause. In this case, something a standard could not be blamed for allowing. I like Rob’s idea of separate x and y a lot, and it got me thinking about some kind of super-efficient additional way to shift all the grid-fit glyph positions at once, in x and y sub pixel space, to provide a sort of fine-tuning that could be offered at a number of possible levels, keeping in mind that this proposed axis would be operating in variable space potentially with other axes, beside via a variety of devices, sizing, scaling and rendering methods . |
The proposal is for a PPEM axis, to enable adjustment of contour points for grid alignment at particular PPEM sizes (similar to TrueType hinting, but maybe easier to implement for font developers not familiar with TrueType hinting). See the proposal details here:
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/PPEM_Axis
Process clarification: Please use this thread for general discussion, but feel free to create issues for specific details in the proposal that you think require attention.
The text was updated successfully, but these errors were encountered: