Edit font infos metadata

[ollimeier]

Fixes #2023, fixes #2088

This is an early draft for feedback.

My main question: Is it the right direction to add and use a Fontra to UFO mapping for customData parameters (it's similar to lineMetricsVerMapping)?

I am also wondering if fontInfoNameMapping should be a dict instead of a list? But this is not related to this issue. I am just noticing it and wondering if we should make it consistent?

[ollimeier]

Here a short demo:

Fontra-CustomData.mp4

[ollimeier]

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

[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.

[ollimeier]

Some keys (for example openTypeOS2SubscriptYOffset) do not allow floating points (writing to UFO will complain). We should probably use an IntegerFormatter for these. We may also need a UnsignedIntegerFormatter and/or UnsignedNumberFormatter, if there are float values that must be non-negative (not sure that situation exists, off the top of my head).

Thanks for the great feedback. Very good point. I added several new formatters + unittests. Please see the latest commit: googlefonts/fontra@e7c1909

[ollimeier]

When adding a key, the list isn't reordered, but the key is added at the end. When reloading, the order differs. I think the order should be maintained at all times.

I left a couple more comments.

I fixed the reordering with the last commit: googlefonts/fontra@9482f2c

[ollimeier]

The text input for the key should have focus when the dialog opens. Unfortunately this requires a bit of a hack. See for example this:

https://github.com/googlefonts/fontra/blob/12fe8ab08f53d397f1b9ceef6dd70fa046ba932d/src-js/views-editor/src/panel-designspace-navigation.js#L1532-L1535

I missed that. Thanks for the hint.