A batch of minor SVG improvements/alterations. #375
Conversation
E053, E054 (Chrome/Chromium logos): Rotating a circle about its center has no effect. Pointless transformation removed. 1F962, 1F961: The path for each chopstick ends with a line drawn back to the original point. Line command replaced with equivalent 'z' command. 1F372: The steam lines on the pot of food had a path which doubled back on itself. The duplicate segments of the path were removed. None of these changes should affect how the glyphs are rendered, but each was causing difficulties for me when trying to import the vectors into fontforge.
When importing some of the OpenMoji svg files as outlines into FontForge, I noticed that some characters ended up with odd-looking 'dots' in unusual places. These dots were caused by zero length paths in the SVG source. When rendered properly as part of an SVG, these paths will not be visible; The cursor is moved to the path's starting point, but no drawing actually occurs. As such, the removal of these elements shouldn't meaningfully alter the vectors in any way. However, when the zero-length path had a specified stroke-width attribute, FontForge's svg import function was drawing a stroke-width radius circle around the path's starting point.
Strictly speaking, this isn't a fix to OpenMoji's src files. Rather, this is a workaround. When the OpenMoji-Black font is viewed in Chrome or Safari on MacOS, the height of lines is far too high. This is because several glyphs are rendered with small fragments far away from where they should be. The glyphs broken in this way are: 🔬 🪖 🪄 🪘 🫔 and . The commonality between these glyphs is that their source svg features an element in the *line* or *line-supplement* group with a rotation about a point other than the origin. When the resulting font is viewed, some browsers instead view the font as if that element were rotated about (0,0). In most cases, this results in the element being placed far outside the normal bounding box of the character. The same problem in the same glyphs arose when I tried to build an OpenMoji font myself using FontForge. If OpenMoji's current build process also uses FontForge at some stage, then I suspect the error might ultimately lay somewhere in that software's import function. I'm hesitant to suggest a change to the source files for OpenMoji to deal with bugs in another piece of software. However, the changes I have made are still vanilla SVG, and don't fundamentally alter the content of the files. I identified 8 files with this problem, but this commit only altered 6. This is because for two of these files (the Chrome and Chromium logos), the transformation didn't actually *do* anything, and so removing the attribute entirely was an unambiguous improvement.
|
This pleases me a lot :) If possible it would be great to remove the transforms? I have briefly tried to research into this but I couldn't find anything automatic |
|
As in apply the transformations to the paths. If you're not sure about it don't worry :) |
It's certainly possible. I was able to use this Inkscape extension to convert the files in Commit 3 above. (The elements had to be converted to paths first.) Inkscape seems to have some sort of command line interface, but it isn't clear to me how to use it, nor whether it can interface with Inkscape extensions. |
|
@RobertWinslow Many thanks for this! Great + merged! However this will just fix existing OpenMojis, but not fix it from a pipeline point of view. There is a high chance that newly incoming files will share the same issues. Hence best would be to add the identified issue to the /test e.g. https://github.com/hfg-gmuend/openmoji/blob/master/test/file-format.js and look into our svgo rules https://github.com/hfg-gmuend/openmoji/blob/master/helpers/beautify-svg.yml to have potentially these shortcoming automatically fixed. |
This pull request alters a number of SVG src files.
None of the files have been altered in a way that changes the SVG's appearance.
I have grouped the changes into three commits so that they can be individually evaluated.
Commit 1: Several Very Minor SVG simplications.
This alters 5 files in a way that, I believe, is a direct improvement. Details are in the commit's description.
Commit 2: Removed zero-length paths.
This alters 220 files. It removes SVG elements that, as far as I can tell, are not rendered by a SVG renderer that follows the SVG specifications.
Commit 3: Convert several transform attributes to matrix notation.
This alters 6 files in a way that should have only a negligible effect on how they are rendered. See here for the reason behind these changes.