I've been using 4.6 for some one-off game mods/utilities and it has done very well. "I have a very niche keyboard (Moonlander) and I play this very niche space sim, make me a SVG keyboard cheatsheet for it". Told me to grab keymap.c for the keyboard and inputmap.xml for the game's key bindings, churned for a while, then spit out a pretty good first attempt, along with the python script used to generate it. Spent another hour of back and forth to refine the script, and now it generates great diagrams that will adapt as my keyboard firmware and game bindings evolve: <a href="https://files.catbox.moe/x0u76x.svg" rel="nofollow">https://files.catbox.moe/x0u76x.svg
Excited to try 4.7. I hope they fixed the "it's not X, it's Y" that showed up in 4.6.
Impressive! I had to peek at the SVG file and it superficially looks good, however, as is the case with everything AI, the more you look, the more it doesn't make any sense.
By now AI should know of the DRY concept. But no. Hence the keys have a rounded rectangle for the key shape and another rounded rectangle for a clip path, to prevent text overflow. There are 72 * 2 = 144 identical rectangles, when just one would suffice (in the defs), with this being cloned once for the clip path, and 72 times for the keys.
I would not expect SVGO levels of optimisation (rounding numbers, that sort of thing), however, the human, if writing out the same thing for the 72nd time, might think 'is there a better way', to get the manual out. A graphics program such as Illustrator would not do that, but AI 'should' because AI.
The above is not criticism of your work, just an observation regarding AI SVG capabilities.
Nice. Thanks for the feedback. I'm currently having it churn out a refactor so I can use it for other games, but afterwards I will tell it to use base key shapes and clone them for the keys. If I were writing this by hand I may have made the same mistake, not knowing that SVG actually has clone capabilities like that. The script does have the key geometry defined in a single place, and generates the SVG wastefully.
Congratulations on going down the SVG 'rabbit hole'!
There are also interesting inheritance rules with SVG, so you could define the basic shape of a key, well, several shapes, just as rects in the defs, with no stroke or fill specified.
Then, at the group level, you can then specify stroke and fill, so there could be a group of normal keys, another group for modifiers, function keys and so on.
Then there are the keys themselves, how do you clone a shape and put different text inside each clone? There are many ways to do this but I think you are on the right track using the clip path approach, albeit using the rects in the defs.
What is interesting about SVG is that artists don't care for the file format, they just see text as shapes on a page. Then programmers don't care for SVG as that is a graphic designer/artworker thing. So SVG sits in this witch-space, with only a few brave enough to wade in and do cool stuff.
Given your application, and given the fun that could be had with SMIL/JS, you could make your SVG files interactive, so you press a key and a popover tells you more about what that key does. You can even get audio working in SVG, as well as HTML popovers (in foreignobjects, as buttons, but working, nonetheless).
'Views' is another interesting SVG feature. I have a sprite sheet that uses a lot of views, where you are projecting your SVG into some type of virtual canvas, taking a 'picture' of it, and then incorporating that in something else, maybe a CSS variable.
One 'deadly addiction' is animation. Filters are another 'deadly addiction'. Why have a static and actually useful diagram, when you can animate it, move the 'camera' and add the equivalent of 27 Photoshop layers as filters to everything?
For example, supposing you wanted to show what keys to press, with there being modifiers and a sequence, e.g. 'Hello World!'. The animation for one letter could be what triggers the animation for the next 'key press' and so it goes.
My top tip of all: reposition the origin (0,0) to where it makes sense. Many objects have symmetry, so you can define one side, clone it, scale it (-1,1) and do it all around 0,0 to then translate the results to somewhere sensible.
I have found the JetBrains IDEs to be extremely useful for SVG, the preview feature is very helpful, as are the code hints.
AI sort of knows SVG, so I have had some suggestions from Google on how to build filters. These never work, but they do get you thinking. Say you wanted to use filters to add specular highlights and animated shadows to the keys, that would be fair game for AI hints on how to do it.
qwerpy · · focus · HN ↗
Excited to try 4.7. I hope they fixed the "it's not X, it's Y" that showed up in 4.6.
Theodores · · focus · HN ↗
By now AI should know of the DRY concept. But no. Hence the keys have a rounded rectangle for the key shape and another rounded rectangle for a clip path, to prevent text overflow. There are 72 * 2 = 144 identical rectangles, when just one would suffice (in the defs), with this being cloned once for the clip path, and 72 times for the keys.
I would not expect SVGO levels of optimisation (rounding numbers, that sort of thing), however, the human, if writing out the same thing for the 72nd time, might think 'is there a better way', to get the manual out. A graphics program such as Illustrator would not do that, but AI 'should' because AI.
The above is not criticism of your work, just an observation regarding AI SVG capabilities.
qwerpy · · focus · HN ↗
Theodores · · focus · HN ↗
There are also interesting inheritance rules with SVG, so you could define the basic shape of a key, well, several shapes, just as rects in the defs, with no stroke or fill specified.
Then, at the group level, you can then specify stroke and fill, so there could be a group of normal keys, another group for modifiers, function keys and so on.
Then there are the keys themselves, how do you clone a shape and put different text inside each clone? There are many ways to do this but I think you are on the right track using the clip path approach, albeit using the rects in the defs.
What is interesting about SVG is that artists don't care for the file format, they just see text as shapes on a page. Then programmers don't care for SVG as that is a graphic designer/artworker thing. So SVG sits in this witch-space, with only a few brave enough to wade in and do cool stuff.
Given your application, and given the fun that could be had with SMIL/JS, you could make your SVG files interactive, so you press a key and a popover tells you more about what that key does. You can even get audio working in SVG, as well as HTML popovers (in foreignobjects, as buttons, but working, nonetheless).
'Views' is another interesting SVG feature. I have a sprite sheet that uses a lot of views, where you are projecting your SVG into some type of virtual canvas, taking a 'picture' of it, and then incorporating that in something else, maybe a CSS variable.
One 'deadly addiction' is animation. Filters are another 'deadly addiction'. Why have a static and actually useful diagram, when you can animate it, move the 'camera' and add the equivalent of 27 Photoshop layers as filters to everything?
For example, supposing you wanted to show what keys to press, with there being modifiers and a sequence, e.g. 'Hello World!'. The animation for one letter could be what triggers the animation for the next 'key press' and so it goes.
My top tip of all: reposition the origin (0,0) to where it makes sense. Many objects have symmetry, so you can define one side, clone it, scale it (-1,1) and do it all around 0,0 to then translate the results to somewhere sensible.
I have found the JetBrains IDEs to be extremely useful for SVG, the preview feature is very helpful, as are the code hints.
AI sort of knows SVG, so I have had some suggestions from Google on how to build filters. These never work, but they do get you thinking. Say you wanted to use filters to add specular highlights and animated shadows to the keys, that would be fair game for AI hints on how to do it.