Symbols path for Inkscape OS X Native

[noorstudies]

Just a note for possible add to the README.md. For Inscape OS X native version, not the XQuartz version. The path is: ~/Library/Application Support/org.inkscape.Inkscape/inkscape/symbols

[su-v]

Experimental unstable "OS X native builds" are not "official" Inkscape packages. The location of the inkscape user profile used with those packages may change any time (since those packages are still work-in-progress, and the changes have not been merged into Inkscape trunk). As packager of osxmenu builds, I would rather not see that path mentioned in README files of other projects at this stage.

[noorstudies]

I find the path strange as well. However it took me a moment to figure out why the symbols were not loading. When following the README.

[su-v]

[off-topic] @noorstudies wrote:

I find the path strange as well. However it took me a moment to figure out why the symbols were not loading. When following the README.

TBH I do not find it that strange (I chose that location myself ;-) ), but since the osxmenu branch is work-in-progress, do not rely on any detail being final. The osxmenu packages include a custom extension BTW which opens a Finder window at the location of the user inkscape profile (to ease testing unstable experimental osxmenu builds). Also, the exact location of the user inkscape profile can be looked up in 'Edit > Preferences > System > User config' (this information is present in experimental osxmenu, stable 0.91 and unstable 0.91+devel builds on all supported platforms).

Besides above details - users who actively chose to install experimental unstable osxmenu builds IMHO are -- to some degree at least -- expected to figure out themselves where certain things are. If that's too much of a burden, I would strongly recommend to stick with stable release builds for now (yes, they are X11/XQuartz-based, we know). [/off-topic]

[noorstudies]

I understand what your saying. I learned about osxmenu from someone less puter savvy then myself. Which isn't saying alot. Since I don't know all/much. This was actually the first time I 'needed' to open up Inkscape's preference panel/window/whatever-doo-hicky. BTW I find r12896 to be very stable. Aside from occasionally refusing to quit right away. Oh and org.inkscape.Inkscape/inkscape threw me a 'wtf?' moment. Thought I was being joshed with. Thinking russian doll scenario.

[Xaviju]

Thanks @su-v for your help! :+1:

[su-v]

@noorstudies

BTW I find r12896 to be very stable.

Latest is r12911 (based on Inkscape trunk r14020), and a newer upload is planned for this week. Inkscape-osxmenu r12902 and later no longer include custom themes for now (defaults to regular GTK2 Adwaita and Inkscape's default icons).

@Xaviju - on another unrelated topic: I had been working on (manually) converting GNOME symbolic icons (from Adwaita icon theme) to (fully re-colorable) Inkscape symbol sets, but am not fully satisfied yet with the result (it would be great to have more automated steps during that conversion, even if the source isn't sufficiently "clean" to convert "as is"). Any comments on the usability of the current state would be welcome: bzr repo (WIP, for now hosted at launchpad)

[Xaviju]

@su-v great extension! I'll test it as soon as possible. I've also downloaded the icons you created from the bzr repo and test how the generated code looks like. :)

[su-v]

@Xaviju - the current symbols sets of the gnome symbolic icons were created manually (in inkscape, but with heavy usage of the built-in XML editor). The extension I then started working on (not finished) is in most parts based on that experience, trying to minimize a few of the repetitive tasks.

The largest part of the work I spent time with when working on the symbol sets for those icons though is not trivially automated / auto-generated AFAIU (at least not addressed by the work-in-progress extension):

• relocate each icon at the SVG origin and remove preserved transforms (including those on parent layer groups)
• flatten nested groups within the icon
• manually fix rounding errors / floating point issues with integer values
• clean-up of unneeded style and other attributes (inkscape can help with that)
• etc.

[su-v]

Just a quick example of Font-Awesome as (re-colorable) Inkscape symbol set, created (with Inkscape 0.91+devel) based on the SVG sprites file from https://github.com/encharm/Font-Awesome-SVG-PNG (sprites.svg), with help of the utilities provided by the symbol tools extension (WIP):

Result: https://www.dropbox.com/sh/dy5r4ehll0rgyh4/AAB4wMRh8oI7n0CFvN1JxWM9a?lst

[Xaviju]

@su-v as I use the icons mostly for frontend development I use to do some more repetitive tasks than usual but this is more or less the pains that my team found, probably not very different from yours:

• Creating the icons from the UI requires doing it one to one. In any case, if its not done one per one, it's hard for the UI to know what is an icon and what is not when them are composed of more than one path, I guess.
• If the icons have already a color, the color becomes uncolorable. Need to remove fills and strokes manually. (I think you already solved that)
• I have to save the as plain SVG to get rid of all the inkscape/sodipodi code I don't need. Lots of inskcape metada that can be fixed if exported as plain SVG instead of inkscape SVG.
• I have to remove all the groups and forms to create a basic path, I do it from the code editor but it would be more useful with a simple <path> insted of a bunch of <g> and forms when its not needed. I could use this symbol later for my web developement (this is my perdonal case)
• Weird IDs all over the SVG file (is this needed?) <title id="212131">. I use to remove all of them and just keep the item-slug ids.

From the result you share, just watching the code:

• I'll remove the inkscape sodipodi metadata about the inkscape page, zoom...
• I'll remove the <g> wrapper if not needed (if only contains a single <path>)
• I'll remove this inkscape:connector-curvature="0" if not needed.
• The <use> tag from line 3146 to 3664 its not needed in the symbol SVG.
• Same with the <text> from 3665 to 5221 path, could be removed and save space.

Hope my experience creating this icons is useful for you!

Side-note: I am trying to install your extension. I copied the files to the extension directory and made the py files executable. What shoul I do next? Is there any documentation on how it should work?

[su-v]

@Xaviju

I won't comment right now on what are inkscape-specific questions (I am not a core inkscape developer myself, and topics like for example why Inkscape enforces IDs on all elements (IIRC mentioned in the Inkscape FAQ), and what plans might be in this regard for the future (maybe make this optional) is certainly getting really off-topic here).

What shoul I do next? Is there any documentation on how it should work?

There is no documentation available at this stage - the extension is very much work-in-progress (I'm adding new features as soon as I encounter a need for it), and probably much based on my personally preferred work flows (there's not a single button to apply a sort of 'Do all the magic for me, I don't bother with details' function/effect).

A few comments to the remaining items:

I'll remove the <g> wrapper if not needed (if only contains a single <path>)

The inner wrapper in the example case (font-awesome sprites.svg converted to Inkscape symbol set) was added intentionally (as test) to be able to use the original path data (aka as is), while at the same time being able to scale (down) all original items by the same amount - the original paths (from the sprites file) are huge, and likely not useful when inserted as symbols at their original size e.g. in mockups for web sites drawn in Inkscape. Ideally, the extension would apply the scale factor to the path data (coordinates) directly, but that's somewhat out-of-scope for this extension.

I'll remove this inkscape:connector-curvature="0" if not needed.

Inkscape tends to add these attributes back whenever paths are touched/updated (I dislike that fact too) - maybe I'll add an option to the extension to remove them (though they'll likely get added back as soon as the symbol set file is edited again in Inkscape).

The <use> tag from line 3146 to 3664 its not needed in the symbol SVG.

These have been added intentionally - the symbol sets distributed with inkscape have them too. This is intended as kind of a self-documentation of the symbol set when viewed/edited directly (not via Inkscape's custom 'Symbols' dialog). The symbol instances (<use> elements) are not needed for the 'Symbols' dialog itself.

Same with the <text> from 3665 to 5221 path, could be removed and save space.

Optional, see above (I originally worked on converting Inkscape icon sets to symbol sets, and had the need to know the IDs of the original icons (those IDs are used as icon names when loading icons in the interface, and thus important). For this reason it was added as optional feature to the extension to display the <title> content per symbol on-canvas). Originally I implemented the feature as text with a <tref> child element which references the content of the <title>element (so that it auto-updates), but then I discovered that <tref> won't be part of SVG 2.0 (so Inkscape's buggy handling of such <tref> elements is unlikely getting fixed).