Investigate options for embedding the font into the SVG so as to allow the SVG to be easily portable.
Convert OpenSans to an SVG font* and embed it into the SVG
Remove unnecessary characters; should only need unaccented alphanumerics, dash, and period. For static badges, would be possible to remove all glyphs that the badge does not use. Be wary of excessive filesize.
Convert OpenSans to an SVG font* and link externally
Best option, but may be a concern as Firefox restricts cross-domain font linking.
Convert to Outlines
If all else fails, static badges can be converted to outlines and it will work just fine. Leaves us with no solution for dynamic badges ala gemfury's gem version badge.
*Licensing should not be an issue, but double check to be safe that it does not conflict.
So... with the realization that SVG have the glaring security holes that they do... does this still hold any relevance?
Can still distribute the SVGs to allow for dynamic badges but then it's not really of use to embed the font anymore.
As far as GitHub, based on @kneath's response on twitter I doubt SVG is a likely scenario for embedding the Shields.
I've been looking into a way to create a Redcarpet renderer that extends the Markdown one with a new image tag that allows two sources — one at 1x and the second at 2x. I think that's the most practical idea given the limitations in order to achieve retina shields.
Now the problem is that it introduces a dependency on the GitHub team, but since @sferik was asking how he could help the effort, maybe there's a chance. 😸
How would detection for that work? Picturefill?
Yeah, that's the only viable option I see. Basically update Markdown to support an extra 2x source like this:
![I'm a banana](banana.png|banana_retina.png)
<div data-picture data-alt="I'm a banana">
<div data-src="banana_retina.png" data-media="(min-device-pixel-ratio: 2.0)"></div>
<img src="banana.png" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
Since Picturefill is ridiculously small, that makes it a decent candidate.
Yeah, I kind of figured as much, was just curious since it's going to be another dependency on github's end to accomplish.
Unfortunately it's really not possible for us to get the image dimensions before hand (and know how to resize it for a retina or not). I forget the reasons (I feel like it was another security issue), but it's something I wanted really badly for completely unrelated reasons (page jumps on slow connections).
I think a much better philosophy would be to choose a hard-coded height, and suggest that style of embedding. Instead of:
![I'm a banana](banana.png)
You would include:
<img src="banana.png" height="38" />
Browsers are smart enough to resize the width accordingly, but this allows for images that are 76px high to show up as 38px high.
It sucks to have to tie image-generation to embedding style, but this new future can be confusing sometimes.
That's a pragmatic solution.
I've updated the example with a @2x pixel doubled version in the README
I think it looks alright on my non-retina screen but it does change the font rendering dramatically. I'm wondering if I shouldn't switch the font rendering to strong. See the last example. What do you think @ackerdev?
@1x on non-retina screen
@2x on non-retina screen with sharp font rendering
@2x on non-retina screen with strong font rendering (left column only)
Retina version looks great over here 🤘
The last option looks best to me by a long shot.
@kneath There are two retina versions. 😜
Font rendering strategies aren't really that noticeable on retina screens. Strong or not, it looks about the same. I'd optimize for the non-retina versions when looking for text rendering strategies.
The @2x's aren't equivalent images–the "sharp" image is at normal res and "strong" is properly @2x
Strong looks better from weight of the text being closer, though the PSD is a bit outdated by now so I'm not sure how it will end up different regarding the SVG export.
I'll export the demo image @2x sometime today from the SVG (with other text-rendering modes like you have if they seem pertinent) and post it here for consideration.
@2x Semibold + Crisp
Strong anti-aliasing seems like it's closest so far, but becomes blurry... Also tried crisp rendering, making font weight 'semibold', and a few other things... If I come across anything else I'll be sure to post it here.
(Also, Strong was exported from Illustrator to png with "Subpixel" antialiasing option)
Semibold font weight + Crisp rendering is closest so far. Could probably reduce the vertical scale by 10% and it might look pretty darn close. Will play around more with that tomorrow, but semibold+crisp looks like the winning combo from here.
Will post an update if I find a better rendering combo.
@ackerdev Semibold + Crisp is is definitely my favorite here. Although it seems this new swanky font rendering we're allowed now that we produce the shields @2x is pushing the text slightly too high because of the anti-aliasing.
Have you tried lowering it a bit?
@olivierlacan Known issue. Had to fanagle it around to make it render in the right spot when exported to raster format. :)
Oh cool, do you have time to export into @2x for all the existing badges?
I'm starting to see the Code Climate badges roll out into repos, I would hate to make everyone do a second roll out with retina-friendly shields right after they updated all their READMEs for Shields 1.0 😸
Not right this moment, but perhaps something I can take a whack at later tonight.
edit: make that tomorrow night.
Found out that exporting with "Type Optimization (Hinted)" also helps sharpen up that font. Subpixel AA was causing the fonts to blur out at the normal resolution
A: @2x Semibold + Sharp + Hinted AA
B: @2x Semibold + Strong + Hinted AA
@2x Semibold + Crisp + Subpixel AA
I think A looks the best so far, looks closest to the original's weight and looks readable to me.
@olivierlacan let me know if you agree or which one looks best and I can spin up codeclimate's new badges and get them going tonight. The rest I can work on over the weekend, no markup changes were needed for their @1x's anyway so less rush needed.
Again, I didn't bother touching the placement of the text yet, just trying to keep things consistent to tell which font treatment actually works best. Will take care of it for when I go through with it.
Can't you make them bigger?
All of them look like flysquat on my 27" Thunderbolt display.
The effective font-size is 4pt and especially white text on green/yellow is a pain to decipher.
Is there use-case for these badges where screen estate is at a premium?
Closing now that we've moved on.
TL;DR solution: SVGs cannot be embedded from a third-party due to security issues. Instead, generate PNGs @2x and use img tag with fixed height.
Server: allow arbitrary hex colors.
Fixes #12 since that ensures Buckler parity.