Finding a portable retina-compatible solution #12

Closed
ackerdev opened this Issue Feb 8, 2013 · 20 comments

Projects

None yet

5 participants

@ackerdev
Contributor
ackerdev commented Feb 8, 2013

Investigate options for embedding the font into the SVG so as to allow the SVG to be easily portable.
Possibilities include:

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.
References:
http://nimbupani.com/about-fonts-in-svg.html
http://frabru.de/c.php/article/SVGFonts-usage

@ackerdev
Contributor
ackerdev commented Feb 9, 2013

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.

@olivierlacan
Contributor

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. 😸

@ackerdev
Contributor
ackerdev commented Feb 9, 2013

How would detection for that work? Picturefill?

@olivierlacan
Contributor

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)

Then output:

<div data-picture data-alt="I'm a banana">
  <div data-src="banana.png"></div>
  <div data-src="banana_retina.png" data-media="(min-device-pixel-ratio: 2.0)"></div>
  <noscript>
    <img src="banana.png" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">
  </noscript>
</div>

Since Picturefill is ridiculously small, that makes it a decent candidate.

@ackerdev
Contributor
ackerdev commented Feb 9, 2013

Yeah, I kind of figured as much, was just curious since it's going to be another dependency on github's end to accomplish.

@kneath
kneath commented Feb 11, 2013

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.

@olivierlacan
Contributor

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
@1x on non-retina screen example

@2x on non-retina screen with sharp font rendering
@2x on non-retina screen with sharp font rendering example

@2x on non-retina screen with strong font rendering (left column only)
@2x on non-retina screen with strong font rendering example

@kneath
kneath commented Feb 11, 2013

Retina version looks great over here 🤘

@sferik
Contributor
sferik commented Feb 11, 2013

The last option looks best to me by a long shot.

@sferik
Contributor
sferik commented Feb 11, 2013

@kneath There are two retina versions. 😜

@kneath
kneath commented Feb 11, 2013

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.

@ackerdev
Contributor

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.

@ackerdev
Contributor

@1x Original
travis_passing

@2x Sharp
travis_passing_2x

@2x Strong
travis_passing_2x_strong

@2x Semibold + Crisp
travis_passing_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.

@olivierlacan
Contributor

@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?

@ackerdev
Contributor

@olivierlacan Known issue. Had to fanagle it around to make it render in the right spot when exported to raster format. :)

@olivierlacan
Contributor

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 😸

@ackerdev
Contributor

Not right this moment, but perhaps something I can take a whack at later tonight.

edit: make that tomorrow night.

@ackerdev
Contributor

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

For comparison,
@2x Semibold + Crisp + Subpixel AA
travis_passing_2x_semibold_crisp

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.

@m-o-e
m-o-e commented Feb 17, 2013

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?

inches
cm

@ackerdev
Contributor
ackerdev commented Mar 9, 2013

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.

@ackerdev ackerdev closed this Mar 9, 2013
@espadrine espadrine added a commit that referenced this issue Feb 19, 2014
@espadrine espadrine Server: allow arbitrary hex colors.
Fixes #12 since that ensures Buckler parity.
c73f7d0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment