[GH-ISSUE #1254] For 1x1 flags, use a different width/height than 512 #578

New issue

Closed

opened 2026-03-03 14:39:28 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 14:39:28 +03:00

Owner

Originally created by @mpsijm on GitHub (May 30, 2024).
Original GitHub issue: https://github.com/lipis/flag-icons/issues/1254

Not sure if this is desired or feasible, so feel free to close if you think it's not 🙂

When hacking away for #1251, I found it tedious to copy my changes from the 4x3 flags to the 1x1 version and vice versa, because they use different heights. Currently, 4x3 uses a viewBox of 640×480, and 1x1 uses 512×512. For triband flags like NL, this results in (inaccurate) fractions.

One suggestion could be to rescale the 1x1 flags to 480×480. I see several advantages:

The vertical measurements will be more consistent between the 4x3 and 1x1 flags, reducing the effort when (re-)designing them both at the same time.
480 has prime factors 2, 3, and 5, whereas 512 only has prime factor 2.

However, there are also some disadvantages:

For vertical triband flags (like FR), the inaccurate fractions remain in the 4x3 variant, because 640 is not divisible by 3.
- This could be fixed by changing the sizes to 1920×1440 and 1440×1440, or 960×720, or 480×360, but that's another can of worms.
Flags don't change that often, so it may not be worth the effort.

Regarding feasability: in theory, this can be achieved by adding a transform=scale(.9375) to all current flags, and use scripting to apply this transformation to all <rect>s and <path>s and what else (for one-off uses, I like to use this Inkscape plugin, but I don't know yet how to automate this for all flags at once). However, there will probably be flags where rounding errors need to be manually checked/corrected, and I'm not sure how well this works for charged flags with small details.

I'm curious to hear your opinions on this! 😄

Originally created by @mpsijm on GitHub (May 30, 2024). Original GitHub issue: https://github.com/lipis/flag-icons/issues/1254 Not sure if this is desired or feasible, so feel free to close if you think it's not :slightly_smiling_face: When hacking away for #1251, I found it tedious to copy my changes from the 4x3 flags to the 1x1 version and vice versa, because they use different heights. Currently, 4x3 uses a viewBox of 640×480, and 1x1 uses 512×512. For triband flags like `NL`, this results in (inaccurate) fractions. One suggestion could be to rescale the 1x1 flags to 480×480. I see several advantages: - The vertical measurements will be more consistent between the 4x3 and 1x1 flags, reducing the effort when (re-)designing them both at the same time. - 480 has prime factors 2, 3, and 5, whereas 512 only has prime factor 2. However, there are also some disadvantages: - For vertical triband flags (like `FR`), the inaccurate fractions remain in the 4x3 variant, because 640 is not divisible by 3. - This could be fixed by changing the sizes to 1920×1440 and 1440×1440, or 960×720, or 480×360, but that's another can of worms. - Flags don't change _that_ often, so it may not be worth the effort. Regarding feasability: in theory, this can be achieved by adding a `transform=scale(.9375)` to all current flags, and use scripting to apply this transformation to all `<rect>`s and `<path>`s and what else (for one-off uses, I like to use [this Inkscape plugin](https://github.com/Klowner/inkscape-applytransforms/), but I don't know yet how to automate this for all flags at once). However, there will probably be flags where rounding errors need to be manually checked/corrected, and I'm not sure how well this works for charged flags with small details. I'm curious to hear your opinions on this! :smile:

kerem closed this issue

2026-03-03 14:39:29 +03:00

kerem commented

2026-03-03 14:39:29 +03:00

Author

Owner

@lipis commented on GitHub (May 30, 2024):

The short answer that we won't do that.. too much effort for all those flags without a clear benefit.. they are not changing that often and It's pretty easy for me to do the changes for new flags.. or updating them!

@lipis commented on GitHub (May 30, 2024): The short answer that we won't do that.. too much effort for all those flags without a clear benefit.. they are not changing that often and It's pretty easy for me to do the changes for new flags.. or updating them!

kerem referenced this issue

2026-03-03 14:41:09 +03:00

[PR #578] [MERGED] Bump lint-staged from 9.0.2 to 9.1.0 #877