Added standard_viewbox_width property to config file to support fixed and zero/proportional width

[prasannagunuru]

No description provided.

[prasannagunuru]

@rsheeter Just to get an idea, how much time is expected for the PR review process?

[anthrotype]

I don't understand why we need an additional standard_viewbox_width property, and it's not even clear what it means from reading its name. I think you can achieve what you want by setting the --width=0 (this should really be called the minimum advance width) and thus force all the advances to be proportional. Then it's your responsibility to ensure that your SVG viewboxes are as expected. Remember that the viebox height is scaled to font units such that it fits within the ascender-descender dimension then the width is scaled proportionally to keep the aspect ratio.

[rsheeter]

Just to get an idea, how much time is expected for the PR review process?

Apologies, I was out for approximately July so this one has gone much longer than it should have.

For context, we don't really have an SLO but typically a few days to a week. Please email or IM us if you feel we're ignoring you , it's a bit easy to lose things in the flood of GH emails.

[prasannagunuru]

When we're dealing with input sets that require both fixed advanced width and proportional width, it seems challenging to accomplish this within a single build process. For instance, when setting the width to 0, all inputs appear with proportional width, which doesn't align with the intended outcome. Ideally, we aim for the majority of inputs to maintain a fixed width of 2345, while still allowing proportional or zero width for family combination-related input.

[anthrotype]

we're dealing with input sets that require both fixed advanced width and proportional width

then I think the best way would be to write a tool that modifies the svg viewbox of the fixed-advance glyphs such that it incorporates the desired placement and advance, and then run nanoemoji --width=0 so that it will treat all input svgs as proportional.

[prasannagunuru]

New tool sounds possible, but it will be adding time and an extra step for over 9000 SVGs? With minimal changes, Could we streamline things by integrating this functionality directly into nanoemoji, benefiting all users, including us?