Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated Martinique Country Flag #1116

Open
wants to merge 12 commits into
base: master
Choose a base branch
from
Open

Conversation

thierryc
Copy link

This pull request addresses issue #623 by updating the Martinique flag. It replaces the previous pull request #624.

•	The new flag has been redrawn and optimized.
•	Both the SVG and PNG versions have been updated.
•	The flag is now centered vertically and rounded, ensuring consistency with other Twemoji flags.

This update ensures that the Martinique flag matches the visual style of the rest of the emoji set.

The source is Wikipedia

https://commons.wikimedia.org/wiki/File:Flag-of-Martinique.svg

https://en.wikipedia.org/wiki/Martinique

image

@Mercury13
Copy link

I would redo the SVG a bit: it is not optimized for deficiencies of SVG renderers.

  1. If two filled spaces are together, one should overlap another.
  2. If they meet at the edge, this overlap should go away from edge.

@Mercury13
Copy link

About 2 — there’s an exception: one of the filled spaces is really small. E.g. Sweden: just draw the cross, blue fringe is almost invisible and is even part of style.

@thierryc
Copy link
Author

Thanks for the insightful comments, @Mercury13! I’ll definitely follow your advice and update my PR accordingly.

@thierryc
Copy link
Author

Hi @Mercury13

I’m looking for some advice on how to effectively overlap two shapes. I have two options in mind:

  1. Slight Overlap: Make one shape slightly larger than the other, allowing for a few pixels of overlap.
  2. Full Overlap: Completely overlap one shape over the background shape.

Which approach do you think would work best? Any insights or recommendations would be greatly appreciated! Thanks!

image image

@thierryc
Copy link
Author

Hi @Mercury13,
I’ve updated the SVG file to include the “Full Overlap” option, where one shape completely overlaps the background shape.
Could you please confirm if this is the correct implementation? Thanks in advance!

@Mercury13
Copy link

1f1f2-1f1f6

@Mercury13
Copy link

Mercury13 commented Oct 10, 2024

(see SVG’s wireframe)
Not optimized at all, use any software you want to optimize.

@Mercury13
Copy link

Mercury13 commented Oct 10, 2024

Here’s wireframe of a random tricolour (Germany). My remake, of course.
image

@Mercury13
Copy link

“Full overlap” etc are probably meant for embroidery/cutting machines. We should make overlaps for ourselves.

@Mercury13
Copy link

Conversely, these options meant for embroidery make pixel rendering really horrible.

@thierryc
Copy link
Author

Thank you @Mercury13 for the clarification—it makes sense. 👍
I appreciate your advice and will make the necessary changes. The PR should be ready for merging soon.

@thierryc
Copy link
Author

thierryc commented Oct 10, 2024

@Mercury13 I followed your advice, and it’s really helpful. I noticed that many other flags don’t align with those guidelines.
I applied the changes to the Martinique flag and submitted them. Last commit fix the last confit issue.

@Mercury13
Copy link

Not enough. And I have made for you:
#1116 (comment)

@Mercury13
Copy link

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
   viewBox="0 0 36 36"
   version="1.1"
   id="svg3"
   sodipodi:docname="1f1f2-1f1f6.svg"
   inkscape:version="1.4-beta3 (01c8a1c, 2024-08-28, custom)"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs3" />
  <sodipodi:namedview
     id="namedview3"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscape:showpageshadow="2"
     inkscape:pageopacity="0.0"
     inkscape:pagecheckerboard="0"
     inkscape:deskcolor="#d1d1d1"
     inkscape:zoom="32"
     inkscape:cx="16.671875"
     inkscape:cy="26.796875"
     inkscape:window-width="1680"
     inkscape:window-height="998"
     inkscape:window-x="-8"
     inkscape:window-y="-8"
     inkscape:window-maximized="1"
     inkscape:current-layer="svg3" />
  <path
     d="m 36,27 c 0,2.209 -1.791,4 -4,4 H 4 C 2.9840384,31 2.0564945,30.621157 1.3509404,29.997044 L 9,15 h 24 l 3,3 z"
     fill="#231f1e"
     id="path1"
     sodipodi:nodetypes="sssccccs" />
  <path
     d="M 36,18 V 9 C 36,6.791 34.209,5 32,5 H 4 C 2.9838056,5 2.0560696,5.3790161 1.3504555,6.0033847 L 6,18 Z"
     fill="#00a650"
     id="path2"
     sodipodi:nodetypes="csssccc" />
  <path
     d="M 1.351,6.004 1.35,6.003 C 0.522,6.736 0,7.808 0,9 v 18 c 0,1.193 0.522,2.264 1.351,2.997 L 17.5,18 Z"
     fill="#ef1923"
     id="path3"
     sodipodi:nodetypes="ccssccc" />
</svg>

@thierryc
Copy link
Author

Thank you @Mercury13 for doing this! I now have a much clearer understanding of how to manage overlapping tasks—very interesting. I learned something valuable today, and I appreciate it. I just have one suggestion regarding the optimization of the SVG file itself.

SVG Optimization: Enhancing File Size and Readability

I've reviewed the current SVG file and propose the following optimizations to reduce file size and improve readability:

  1. Remove Inkscape-specific tags and properties:

    • Deleted sodipodi:docname and inkscape:version attributes from the root <svg> element.
    • Removed the entire <sodipodi:namedview> element.
    • Eliminated xmlns:inkscape and xmlns:sodipodi namespace declarations.
  2. Simplify color definitions:

    • Replaced named colors with shorter hex codes where applicable. (#000000 -> #000)
  3. Clean up IDs and unused attributes:

    • Removed unnecessary id attributes from elements.
    • Deleted the empty <defs> element.

Here's a comparison of the original and optimized SVG:

- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <svg
   viewBox="0 0 36 36"
   version="1.1"
-  id="svg3"
-  sodipodi:docname="1f1f2-1f1f6.svg"
-  inkscape:version="1.4-beta3 (01c8a1c, 2024-08-28, custom)"
-  xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-  xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns="http://www.w3.org/2000/svg"
-  xmlns:svg="http://www.w3.org/2000/svg">
-  <defs
-     id="defs3" />
-  <sodipodi:namedview
-     id="namedview3"
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1.0"
-     inkscape:showpageshadow="2"
-     inkscape:pageopacity="0.0"
-     inkscape:pagecheckerboard="0"
-     inkscape:deskcolor="#d1d1d1"
-     inkscape:zoom="32"
-     inkscape:cx="16.671875"
-     inkscape:cy="26.796875"
-     inkscape:window-width="1680"
-     inkscape:window-height="998"
-     inkscape:window-x="-8"
-     inkscape:window-y="-8"
-     inkscape:window-maximized="1"
-     inkscape:current-layer="svg3" />
   <path
     d="m 36,27 c 0,2.209 -1.791,4 -4,4 H 4 C 2.9840384,31 2.0564945,30.621157 1.3509404,29.997044 L 9,15 h 24 l 3,3 z"
-    id="path1"
-    sodipodi:nodetypes="sssccccs" />
     fill="#231f1e" />
   <path
     d="M 36,18 V 9 C 36,6.791 34.209,5 32,5 H 4 C 2.9838056,5 2.0560696,5.3790161 1.3504555,6.0033847 L 6,18 Z"
-    id="path2"
-    sodipodi:nodetypes="csssccc" />
     fill="#00a650" />
   <path
     d="M 1.351,6.004 1.35,6.003 C 0.522,6.736 0,7.808 0,9 v 18 c 0,1.193 0.522,2.264 1.351,2.997 L 17.5,18 Z"
-    id="path3"
-    sodipodi:nodetypes="ccssccc" />
     fill="#ef1923" />
 </svg>

These changes result in a smaller file size and improved readability without affecting the SVG's visual output. By removing Inkscape-specific metadata and unnecessary attributes, we make the file more portable and easier to work with in different SVG editing tools.

I believe these optimizations strike a good balance between file size reduction and maintaining the SVG's structure. However, I'm open to discussion if you have any other suggestions for further improvements.

My optimized version:

<svg viewBox="0 0 36 36" xmlns="http://www.w3.org/2000/svg"><g fill="none" fill-rule="nonzero"><path d="m36 27c0 2.209-1.791 4-4 4h-28c-1.0159616 0-1.9435055-.378843-2.6490596-1.002956l7.6490596-14.997044h24l3 3z" fill="#231f1e"/><path d="m36 18v-9c0-2.209-1.791-4-4-4h-28c-1.0161944 0-1.9439304.3790161-2.6495445 1.0033847l4.6495445 11.9966153z" fill="#00a650"/><path d="m1.351 6.004-.001-.001c-.828.733-1.35 1.805-1.35 2.997v18c0 1.193.522 2.264 1.351 2.997l16.149-11.997z" fill="#ef1923"/></g></svg>

I will add it to the PR.

@Mercury13
Copy link

I wrote: optimize with whatever software you want.

In my Unicodia flags are Twemoji-based (made before SVGization of waved Noto flags, and just simpler). Rules are (a bit contradict to Twitter’s!):

Flags

These rules are intended to work around renderer deficiencies. Emoji are intended to be drawn in small size, and rendering SVG leaves half-pixel lines. Also white and black are main colours everywhere.

  • Joining fields:
    • Fields always overlap to at least 1/16 width. Example (England): you just draw a white rectangle, and a cross over it.
    • When fields are large, that overlap should shun the edge: Example (Ukraine, Poland and other bicolours): one half is a rectangle, the other is a hexagon, with two vertices making that overlap.
  • Colour scheme:
    • White is pure white FFF, black is Twitter black 141414.
  • White fields adjacent to background:
    • Small (Norway, US): just white
    • Medium, both ends are of the same colour (Argentina, Oman): outline of that colour
    • Medium, ends have different colour (France, Luxembourg): grey outline
    • Large (England, Slovakia): also grey outline
    • Difference: small = white field makes a negative space rather than a hole; large = coloured outline makes too much visual noise

@thierryc
Copy link
Author

Hi @Mercury13,

Thank you for sharing these guidelines! They are really sharp and interesting, and they offer great insights. I’ve reviewed them closely and made sure that my latest shape version aligns with these recommendations.

Regarding the flag colors: the flag should be red, green, and black. I’ve used the color values from the Wikipedia SVG reference, where black is set to #231F1E instead of pure black. Should I replace it with Twitter Black (#141414) instead? Also, for the red and green, should they remain as I set them, or should they be adjusted to fit a Twitter palette as well?

Looking forward to your feedback!

@Mercury13
Copy link

Black better replace. Red and green do not really matter, and it’s BETTER to check country’s flag habits and shift to Twitter’s palette.
As I’m from Ukraine, and until recently Russia was really close, I’ll better talk about them.
UKRAINE. Our flag used to be light-blue+yellow, and in 90s for the sake of practicality the blue became darker, but really dark blue like in Russia since 2014 means something special. No special considerations about yellow.
RUSSIA. Their flag is white-blue-red, and no special considerations, Pantone simple red and simple blue are used. So normal white, normal darker blue from palette, and normal red.

@thierryc
Copy link
Author

I understand your point @Mercury13. Some colors have meaning.

Aligning the black color does make sense, and I’ve updated it in the latest commit.
The other colors are now aligned with the ones used on Wikipedia.

Are we good with this now?

@Mercury13
Copy link

Another interesting point. Honduras: ≈2022 they changed flag to Maya blue, and even gave RGB, but as Twitter uses a bit dull colours, it’s better to find that line of colours in Pantone and choose a bit duller.

@thierryc
Copy link
Author

Interesting point @Mercury13

I’ve adjusted the colors of the Martinique flag to match the Pan-African colors already used by countries such as Ethiopia, Ghana, Malawi, and South Africa in the Twemoji flags.
This ensures consistency and coherence across flags that share similar symbolism.

@thierryc
Copy link
Author

Great teamwork, @Mercury13! Do you have the necessary access to merge this PR, or do you know who is responsible for handling it?

@thierryc
Copy link
Author

thierryc commented Oct 14, 2024

A small app to compare local emoji flag to twemoji. (iOS, macOS, Android) https://emoji-flags.netlify.app

@Mercury13
I wanted to check in on the status of Pull Request!

Looking forward to your update!

@thierryc
Copy link
Author

Hi @WebReflection,

When you have a moment, could you kindly take a look at my PR #1116? I’d really appreciate your feedback.

Also, I was wondering if this repository is still actively maintained. I’d love to know if there are any plans or updates for its future.

I also wanted to mention that I’ve submitted a PR on jdecked/twemoji,
Update country flag images: Martinique (PNG and SVG files) jdecked/twemoji#114

Thank you so much for your time!

Best regards,
Thierry

@WebReflection
Copy link
Contributor

WebReflection commented Oct 19, 2024

@thierryc its been like 10 years I don’t work at Twitter or don’t maintain this project + I only ever wrote and cared about the only part that never changed: the JS one.

I’m not a designer and I’ve never created a single emoji so I’m afraid I wouldn’t know how to help in general anyway.

@thierryc
Copy link
Author

@WebReflection Thank you so much for taking the time to respond to my message. This project is truly valuable as an open-source initiative. Would you happen to know who might be responsible for maintaining the repository or project at this point?
May be @jdecked ?

Thanks again!

@WebReflection
Copy link
Contributor

@thierryc to be honest, after all the changes that happened and the re-branding, I don't even know why this space is still active ... it should be called xemoji eventually and under the github.com/x account (I suppose) but again, long time I don't talk, meet, or see the lovely people I've worked with at Twitter (at that time) or that helped me publishing this (lovely indeed) project. I don't know about the license state anymore, I don't know anything about it anymore and I am not planning to fork or maintain this because, like I've said, I have no idea how to even produce emoji in here, I don't have time neither, and I think these days almost every browser is perfectly capable of producing something meaningful out of unicode chars so that while 10 years ago this project was the only way to have consistency on the Web, these days the need to have an emoji to image transformer seems to be not super productive out there.

That being said, I believe the current X still uses this projects as their emoji are still the same, universally, and look just like the one we have in here.

@thierryc
Copy link
Author

Thank you @WebReflection, I understand and agree 100%! A lot of things have changed from Twitter to X, indeed!

On GitHub, X still looks like a bird. 😉
On a side note, it looks like the X account on GitHub belongs to someone other than X Corp. github.com/x

This project jdecked/twemoji—it does look more up-to-date! I will dig on!

I completely agree about the general emoji support. However, there’s still the issue with flags on Windows. Unlike other platforms, Windows doesn’t display visually colored flag emojis; instead, it shows the country code as two letters. This happens because Windows doesn’t natively support regional flag emojis, which is a known limitation. Hopefully, this improves with future updates!

Thank you for your help and your kind response on a project you’re no longer in charge of.
I really appreciate it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants