You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 theshape
tool, for example, that level of info would be fairly straightforward with fields that are unambiguous, such as theglyph_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, adata:
namespace in SVG attributes that could store whatever gets thrown at it (looking atkerning
, 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.The text was updated successfully, but these errors were encountered: