UI for lineMetricsVerticalLayout

[ollimeier]

          > Note: We will add UI for `lineMetricsVerticalLayout` to this PR as we noticed that there is an overlap with `openTypeVheaVertTypoLineGap`.

@justvanrossum I think this requires more and thorough consideration of how we really want to deal with it. There are too many open questions: How would a UI look like? Does it look like "Line metrics" or like "Custom Data". Is it always there, like "Guidelines", even though we don't really need it always? In general I would think it should look like "Line metrics", but we don't set these values always (which differs from "Line Metrics"), and we don't have an add or remove concept for that UI, yet.

Originally posted by @ollimeier in #2039 (comment)

[ollimeier]

Do we need to add top and bottom side bearings for proper compatibility as well?

[ollimeier]

vertTypoAscender: default -> (head.unitsPerEm)/2
It is the distance in font design units from the vertical center baseline to the right edge of the design space for CJK / ideographic glyphs (or “ideographic em box”).

vertTypoDescender: default -> -(head.unitsPerEm)/2
It is the distance in font design units from the vertical center baseline to the left edge of the design space for CJK / ideographic glyphs.

But what is vertical center baseline? And where is it? Is it always the center of a glyph, or at a specific position? How do we display this vertical center baseline?

[ollimeier]

If we add UI for lineMetricsVerticalLayout, do we need vertical type-setting as well? And how would it look like?

[ollimeier]

Do we need a glyph 'hight' similar to 'width' for CJK characters?

[ollimeier]

Would it make sense to use the lineMetricsVerticalLayout values for the CJK Design Frame?

[ollimeier]

Do we need 'Zones' for lineMetricsVerticalLayout ?

[ollimeier]

This whole topic requires a lot more thinking then originally expected. As this is not part of Version 1.0 and the time till Version 1.0 is very limited, the best solution for now, might be to add openTypeVheaVertTypoAscender and openTypeVheaVertTypoDescender to ufoInfoAttributesToRoundTrip, so that people can add and edit these values via the font source customData.

[ollimeier]

In a call today, together with @justvanrossum, we agreed on it, that all the questions above are too much to handle now. BUT one possible next step would be to convert the font source 'Line Metrics' section into a ui-list with add and remove buttons (in a separate branch and PR). The add-button opens a dialog where we can select possible options like openTypeVheaVertTypoAscender.

A question, we have not talked about: What happens if we delete one of the default line metrics like 'Baseline' or 'Ascender'?