New logos and colors

Simone, can you be more specific about which specific files have changes? I will recheck them.

1 Like

Every (colored vector) file…
Note that I’ve just edited my post above:

There was a wrong RGB value (153 instead of 152).

I haven’t previous files, but the middle point of the gradient is moved from 50% to
<stop offset="0.505" stop-color="#017f98"/> 50.5%.

1 Like

The previous files can be found here:

@Simone to help us make sense of this, which color values changed, and what are the old and the new values?

I think the “correct” values are the ones that are already in use across our various sites, such as the gradient at the top of the forums: linear-gradient(-135deg, #3ebca6 0, #057f99 50%, #006b81 100%)


This matches the guidelines.

New files are all like this:
linear-gradient(-135deg, #3DBCA6 0, #017F98 50.5%, #006B81 100%)

Old files from your link (that have broken vectors):

  • feather-gradient.svg linear-gradient(-135deg, #3FBDA7 0, #077F99 50%, #076B81 100%) (wrong)
  • icon-gradient.svg linear-gradient(-135deg, #3DBCA6 0, #017F98 50%, #006B81 100%) (wrong)
  • logo-gradient.svg linear-gradient(-135deg, #3DBCA6 0, #017F98 50%, #006B81 100%) (wrong) with the text being #017F98 (wrong)

As you can see there are many little differences in values everywhere…

Maybe we can use only SVGs as vector files, they can be opened by Illustrator and Inkscape. And then provide an Illustrator PDF option for press with CMYK colors.


1 Like

Here there are the SVGs

  • Fixed colors
  • Checked angle (it’s ok)
  • Fixed names (the files were renamed but not the title in SVG)

Please take a look at them and also tell me something about my idea for CMYK logos, so I can make PDFs.



As I created the new SVG files, I’m guessing this has something to do with me. :slightly_smiling_face:

Re midpoint colour. I used the original originals as a starting point for all files (the files that used to be on These files have #017f98 as the midpoint so that explains why the new files also have #017f98 and not #057f99 as the midpoint.

<stop offset="0" stop-color="#3dbca6"/><stop offset="0.5" stop-color="#017f98"/><stop offset="1" stop-color="#006b81"/>

The wording is also #017f98 in each case, the same as the midpoint.

For information, the actual difference between #017f98 and #057f99 isn’t noticeable to the naked eye. In the example below “Clas” is #017f98 and “sic” is #057f99.


Re midpoint position. This can be explained by my using 3 decimal points instead of 2. When I open the .ai file and save to 2dp, I get this:

<stop offset="0.5" stop-color="#017f98"/>

Not sure if this helps?


I also thought that those were the right colors :slightly_smiling_face:
Bringing SVGs to linear-gradient(-135deg, #3ebca6 0, #057f99 50%, #006b81 100%) was pretty easy… much more than your job of closing paths!
I hope I’ve not introduced errors so if someone wants to check…
I’ve not done any PR…
EPS and AI are still original…

I took a little time to watch at the CMYK conversion and created a PDF in the same folder test-CMYK.pdf.


Ok, so we are talking about a maximum difference of 6 color values (out of 255), with the largest difference being in color values that are close to 0. This is definitely something we should fix, but fortunately it’s not something that should cause visual differences.

I am pretty sure I understand why this happened, too…

This is a good idea, our “master” format should be a text-based format. This has a lot of advantages:

  • Associated with open-source tools, not proprietary (though people can still use Illustrator if they want).
  • Changes can be reviewed and managed by reading the file before/after and taking advantage of git/GitHub’s diff tools.
  • Plain text formats are the best choice for long-term archival.

We’ll probably want to keep a .eps version but I think we can drop the .ai files. Thoughts on that?

We’re an online project, and when you open a CMYK PDF for viewing on a screen, it just looks wrong. People have commented on this in the past.

Also, I suspect these changed color values were caused by unwanted color conversions in the first place.

All of this is worth avoiding. We need to be sure to use RGB as our “master” color format, and I’m skeptical that we even need to provide CMYK versions. A single PDF is probably ok, but I think it might be even better to (1) not do this until we really need it, and (2) automate the conversion when we do need it.

If all of that makes sense, let’s just worry about the SVG files for now, and write a script to generate the rest of the files automatically each time the SVGs change.

:upside_down_face: Remember this? Gradient angles (funny)


It’s fixed in my fork. (After a review) it’s ready for merging and removing unnecessary files.

I can take a look at it. Bash and imagemagik could be used for that?




1 Like

Sorry I can’t be of more use here. Thanks for straightening things out, @Simone and @1stepforward.


Let’s be sure to check the transparency of the resulting .png files, but this should be fine.

1 Like

I’ve done a PR for the new SVG.

In my develop branch there are the script used for generating other formats.

Mainly it uses CairoSVG. ImageMagic delegates to other apps in an unpredictable manner and results were scary!

I’m not very happy and needs decisions:

  • PNG output is OK, transparency, respect of colors, good antialiasing…
  • PDF output is quite good, transparency, respect of colors. There is a box used to make the gradient compatible. Using it for vinil-cutting or laser-cutting will require a little effort to correct the files, but for desktop publishing is ok.
  • EPS output is weired



Just wondering if we’re over-thinking this? The logo isn’t likely to change often, if at all. So once the files are correctly generated (using whatever tool works best), isn’t that job done?

We could also add a message on the website saying “please contact us for other formats / sizes” or words to that effect if necessary.

Or am I missing something?

1 Like

I don’t think automating this is overkill.

Our logos should change infrequently, but we still need a standardized process for re-generating the other logo files, that doesn’t just live in one person’s head (so far that has been Michelle).

If we do that in code instead, we are at least making all the information available for the next time this comes up.

@Simone how about using inkscape instead? This will simplify things a good bit, it supports all the export formats we want. The only tricky bit is finding the PNG image height, but we can just do the export first, and then read the height from the resulting image:

# these two variables would be defined in a loop instead

# H is used as a placeholder for the final image height,
# which is currently unknown
inkscape $svg --export-width=$width --export-png=$png_tmp
height=$(identify -format '%h' $png_tmp)
mv -v $png_tmp $png

# and repeat for other PNG sizes

More information:

Also I think we shouldn’t generate individual PDF files for each asset for now, or is there a reason we need this specific format?


Thank you for the hints on inkscape.

Now the develop branch on my repo does this:

  • Convert to PNG, but using Cairo. Conversion with InkScape looks good, but the resolution is weired. Seems (just a minute googling) that it can’t deal properly with resolutions.
  • Height is calculated from the SVG because identify adds the need of ImageMagick.
  • EPS output from Inkscape is wrong, has duplicated paths and opened paths, that are very hard to fix for someone that needs to properly use paths (vinyl cutting…)
  • PDF output is nice, so I’ve preferred to output only PDF, no EPS.

Consideration about EPS vs PDF: while in general I prefer (for Desktop publishing) to get an EPS logo, today a correct PDF is just the same, but is more friendly to non-DTP users. As example… PDF are required from cake-designers to print the logo on the cake :wink:

If you check my FB profile, you’ll discover that I’m in a camplicate relationship with Adobe :rofl:



Can you provide more details on this issue with resolutions? Cairo-svg is the least common of all of these proposed dependencies.

I agree we shouldn’t use IM to manipulate vector files, but using identify to read the height of a PNG is fine, and makes for much simpler code.

Cairo PNGs have the right number of pixels @ 72dpi. So the size changes.

InkScape SVG have the right number of pixels and the fixed size of 156mm and the dpi changes to meet the right number of pixels. InkScape is not respecting --export-dpi=72.

If this is not a problem the script will be much easier and will depend only on InkScape (no need to use identify because InkScape outputs the width when generating the file).


Let’s assume this is not going to be a problem and fix it later if needed. The most important thing for a PNG is the pixel size.

I found a couple of related links and potential fixes if we need them later:

I’m also curious why Inkscape isn’t generating correct EPS files, but I guess if we need to leave that format out for now, then that’s fine.

Ok. So I’ve deleted the old PR (that was only about correcting colors) and created a new PR with both color correction and the script that generate other assets.
If you want you can merge.

Resolution is not really important. Adding the requirement of ImageMagick is a big overhead for something that has very little importance.

Someone who want to (example) print in a vinyl-cutter can use SVG or PDF (with a one-minute cleanup work).

What I can’t understand is why it’s generating correct PDF files :sweat_smile:


1 Like