Skip to content
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

[feature-request]: fancy, instrumented SVGs #28

Closed
n8willis opened this issue Nov 20, 2022 · 1 comment
Closed

[feature-request]: fancy, instrumented SVGs #28

n8willis opened this issue Nov 20, 2022 · 1 comment

Comments

@n8willis
Copy link

Distinct from #27, there are some additional features that I believe it would be useful to embed into the SVG elements produced by view.

Currently, it looks like each glyph gets an id corresponding to its PostScript glyphName from the font.

It could be useful to also embed some other select information as well, so that the resulting SVG could be styled with CSS (or in Inkscape, possibly elsewhere). The basic use case would be to highlight glyphs by changing their fill-color, visibility, or other such attributes based on some factor you are trying to debug or investigate.

For example, highlighting whether a glyph in the final output was original or was the result of a substitution.

The blanket approach could be to embed that info as tokens with a class for the glyph. Looking at the output of the shape tool, for example, that level of info would be fairly straightforward with fields that are unambiguous, such as the glyph_origin, glyph_index, and the booleans.

E.g., you could add an is_mark to the "class= ..." list when it's True and omit it when it's False without much chance of confusion.

Slightly more complex would be something like glyph_origin_Direct where the "Direct" value gets appended. I'm not sure how complex those values could become; presumably they're all strings so concatenating them after an underscore would be predictable.

Still more complex than that would be numeric values, like liga_component_pos. There is, supposedly, a data: namespace in SVG attributes that could store whatever gets thrown at it (looking at kerning, for instance), but concatenating the value as with the strings might be all that it takes in practice.

Adding a few bits of info to a class element shouldn't impact the size of the output SVG in a significant way, and would be ignored by renderers that are not trying to distinguish things with CSS or other style-rule tooling.

@n8willis
Copy link
Author

Following on, to better explain the use case... in the example above, you could have a CSS rule in your specimen page/app that changes the fill color of the .is_mark class, behind a UI toggle, and use it to highlight mark glyphs.

@wezm wezm mentioned this issue Dec 20, 2022
@wezm wezm closed this as completed Dec 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants