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.

▲

qwerpy a day ago | parent [-]

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.

	▲	Theodores 10 hours ago \| parent [-]
		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.