fix: stroke omitted for hi_outline_icons.rs

[goosethedev]

Solves #62

Omits the stroke attribute on codegen. I only tested it for the Heroicons files (the Material repo was too big for me to clone), but I assume it is also beneficial to avoid hardcoding the attribute in other files. Let me know if I should test it for the other files as well.

Also, I think it would be better to set stroke: "currentColor" to explicitely allow stroke overwriting by the parent, but it seems it isn't totally necessary.

[Copilot]

Pull Request Overview

This PR addresses issue #62 by omitting the stroke attribute from the generated icon files to allow for parent-based stroke overwriting.

• Excludes the "stroke" attribute in the generated code for SVG child elements.
• Aligns attribute filtering for icon file generation with the desired behavior for Heroicons.

[nissy-dev]

Sorry for the delayed response.

It seems that in Heroicons, not only the stroke attribute, but also stroke-linecap, stroke-linejoin, and stroke-width are included in the returned HTML from child_elements.

dioxus-free-icons/packages/lib/src/icons/hi_outline_icons.rs

Lines 32 to 35 in 5a42938

	stroke: "#374151",
	stroke_linecap: "round",
	stroke_linejoin: "round",
	stroke_width: "2",

In this case, we need to omit those attributes and adjust the settings for extract_svg_colors, extract_stroke_linecap, and extract_stroke_linejoin accordingly.

dioxus-free-icons/packages/codegen/src/create_icon_file.rs

Lines 153 to 176 in 5a42938

	fn extract_svg_colors(icon_prefix: &str) -> (&str, &str, &str) {
	match icon_prefix {
	"Fi" => ("\"none\"", "user_color", "\"2\""),
	"Ld" => ("\"none\"", "user_color", "\"2\""),
	"Io" => ("user_color", "user_color", "\"0\""),
	_ => ("user_color", "\"none\"", "\"0\""),
	}
	}
	fn extract_stroke_linecap(icon_prefix: &str) -> &str {
	match icon_prefix {
	"Ld" => "round",
	"Fi" => "round",
	_ => "butt",
	}
	}
	fn extract_stroke_linejoin(icon_prefix: &str) -> &str {
	match icon_prefix {
	"Ld" => "round",
	"Fi" => "round",
	_ => "miter",
	}
	}

[goosethedev]

I'll work on this in the upcoming days and check if other icon packs have similar problems.

[goosethedev]

@nissy-dev while taking a closer look at this, I noticed some other aspects of the Heroicons:

• The pinned submodule revision is 3 years old, missing several icons.
• The Heroicons repo includes an optimized directory with modified versions of the src icons. Here, attributes follow more sensible values (including the stroke set to currentColor).
• The latest version also includes two additional icon subsets for smaller icons (solid versions only): 16 (mini), 20 (micro).

I was thinking of turning this PR into a draft that solves all of these problems. I would:

• Update the submodule to the latest versions.
• Switch the SVGs path to the optimized directory.
• Add two output Heroicons icon packs, making them four in total: hi_outline_icons.rs, hi_solid_icons.rs, hi_mini_icons.rs and hi_micro_icons.rs, same as shown in the Heroicons page.

Let me know what you think about this :)

[goosethedev]

Also, unrelated to this PR, I was considering other modifications as separate PRs:

• Add command line options (maybe using clap) to the codegen crate to run it only for a selected icon pack (right now it generates all icon packs, and the ones not downloaded in the icon_resources output empty files). e.g. cargo run -- heroicons.
• Separate pipeline transformations for each icon pack for better modularity, so changes in one icon pack don't affect the other ones. Maybe a IconParser trait with a .create_icon_file?

[nissy-dev]

Thank you for doing your work! I think your suggestions look good overall.

Update the submodule to the latest versions.
Switch the SVGs path to the optimized directory.
Add two output Heroicons icon packs, making them four in total: hi_outline_icons.rs, hi_solid_icons.rs, hi_mini_icons.rs and hi_micro_icons.rs, same as shown in the Heroicons page.

If possible, I’d appreciate it if you could split these changes into separate PRs.

Also, unrelated to this PR, I was considering other modifications as separate PRs:

This one looks good as well. Again, if it’s a major change, it would be great if you could split it into separate PRs before submitting.