I’ve noticed that colors listed in the PDF that can be found in the Style Guide linked here are changed in the new files.
So I think that the document has to be reviewed.
In this occasion I propose to add to the colors in the aqua gradient equivalent Pantone and convert to CMYK using the official value.
@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%)
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.
As I created the new SVG files, I’m guessing this has something to do with me.
Re midpoint colour. I used the original originals as a starting point for all files (the files that used to be on box.com). These files have #017f98 as the midpoint so that explains why the new files also have #017f98 and not #057f99 as the midpoint.
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:
I also thought that those were the right colors
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.
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.
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.
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
width=600
svg=classicpress-logo-wordmark-gradient-on-transparent.svg
# H is used as a placeholder for the final image height,
# which is currently unknown
png_tmp=${svg%.svg}-${width}xH.png
inkscape $svg --export-width=$width --export-png=$png_tmp
height=$(identify -format '%h' $png_tmp)
png=${svg%.svg}-${width}x${height}.png
mv -v $png_tmp $png
# and repeat for other PNG sizes
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
If you check my FB profile, you’ll discover that I’m in a camplicate relationship with Adobe
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).