Shields as a Service

[ackerdev]

Let's discuss what we will need for the possibility of offering Shields as a Service. What considerations do we need to make to ensure that it is feasible and robust?

[ackerdev]

API interactivity I was thinking of something like /travisci/ackerdev/myrepo/shield.png, which should in turn interact with a vendor's API to get the appropriate result to generate the dynamic PNG. This would require vendors to link through us for badge functionality, but removes the dependence of maintenance from the vendors.

Image generation SVGs are awesome. It would be pretty easy to set up a base SVG to work with, and then manipulate it's nodes on the fly to quickly generate dynamic badges. Problem: Converting SVGs to PNGs is a hassle. The way that I tried (and failed) at CodeClimate's shields was to use the 'rsvg' lib for imagemagick. I got as far as spitting out a converted version, but the external font absolutely mangled it. Could possibly be remedied by embedding the font into the SVG. Alternatively, and this could be considered going the long way around the problem, I believe we could use Phantom to make a capture of the SVG (as long as it can come out with a transparent background). Don't know too much about Phantom, so would be great if anyone more familiar can weigh in.

[afeld]

I was just able to convert the badge SVG to a PNG with the following steps:

1. Download an arbitrary badge SVG file, e.g. rubygems_version.svg
2. Download the Open Sans font package
3. Download the imagick_type_gen script and save as imagick_type_gen.pl
4. Run the following:

chmod +x imagick_type_gen.pl
./imagick_type_gen.pl ./path/to/OpenSans-Regular.ttf > type.xml
# imagemagick doesn't seem to like the extra quotes around the font-family
sed -i.bak "s/'OpenSans'/Open Sans/g" rubygems_version.svg

# do the actual conversion
MAGICK_CONFIGURE_PATH=`pwd` convert rubygems_version.svg rubygems_version.png

open rubygems_version.png

Voila! Anyway, there's a relatively small number of possible shields, right? For everything but version numbers, it's only a handful. It might be easiest to pre-generate them and then have this service pull from a directory.

Another option would be to have a service that generates and caches them. I'd be happy to put something together with magickly (which uses imagemagick under the hood), if there's any interest. Should be pretty straightforward, actually.

[ackerdev]

Nice, though that still requires librsvg doesn't it?

Anyway, there's a relatively small number of possible shields, right?

CodeClimate has 41, Coveralls has just generated their 101, and GemFury's gem badge has a nigh-infinite amount. It has to be a dynamic solution to be viable (though of course we can cache badges from vendors that are largely static, ala travis & gemnasium).

[afeld]

Not sure... do you know how to find that out? I just have imagemagick installed via homebrew.

$ convert -version
Version: ImageMagick 6.8.0-10 2012-12-16 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC
Features:  OpenCL

$ identify -list format
   Format  Module    Mode  Description
-------------------------------------------------------------------------------
...
      SVG  SVG       rw+   Scalable Vector Graphics (XML 2.7.8)
...

In any case, this sounds like a great use case for magickly :-) Will try to make a little sample service this weekend.

[ackerdev]

Hmm... that's right, ImageMagick comes with a default SVG renderer... I forget why I used librsvg. Maybe I'm misled because I thought it would have solved my font problem? I forget, it's been about a month since I originally tried to convert them with imagemagick.

Anyway, you would have to be installing imagemagick with the --with-rsvg (I think that's what it is) flag in homebrew to get librsvg (and a ton of the other deps, which is why I'm not too fond of it). You could brew search rsvg to see if you have it, but it doesn't look like you do.

[kookster]

I spent some time fiddling with this, and I get an image to render, but it doesn't look much like the png files: vs

by adding -background to the imagemagick call, I at least get the corners to look right:

convert -background transparent template.svg result.png

I'm guessing that is not the right font, first off, even though I did the convert above, so fiddling with that now.

[kookster]

looking under the covers, it seems convert is formatting a call to inkscape for the actual svg->png. I wonder if it might be easier to go straight to that?

> convert -verbose -background transparent template.svg result.png
"inkscape" "template.svg" --export-png="/var/tmp/magick-67103-okfqUBOeGP7" --export-dpi="90,90" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0" > "/var/tmp/magick-67103jaAF40pZHoJx" 2>&1
mvg:/var/tmp/magick-671031U3Kq_F2Gzbh=>/var/tmp/magick-671031U3Kq_F2Gzbh MVG 77x19 77x19+0+0 16-bit sRGB 1.65KB 0.020u 0:00.009
template.svg SVG 77x19 77x19+0+0 16-bit sRGB 1.65KB 0.000u 0:00.000
template.svg=>result.png SVG 77x19 77x19+0+0 16-bit sRGB 0.000u 0:00.009

I was also wondering the default dpi; 90 it seems.

[cainus]

Hey all... I took a shot at this with limited success. See my "size" shield?

https://github.com/cainus/percolator#readme

I tried both imagemagick and graphicsmagick for the svg conversion but settled on graphicsmagick because the output was more correct than imagemagick.

These guys ( http://badge.fury.io/ ) get it right though:

https://d25lcipzij17d.cloudfront.net/badge.png?title=npm&type=3d&v=1.0.11test

So... Any clue how they're doing that? I guess in the worst-case scenario I could end up just drawing it programmatically without svg.

Thanks

[kookster]

I have had good luck installing inkscape, then using it from the command line.

Here is a copy of the travis 'build passing' image I generated from the command line:

Here was the command: /Applications/Inkscape.app/Contents/Resources/bin/inkscape "travis_passing2.svg" --export-png="badge.png" --export-dpi="90,90" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0"

I think this is workable for running on my mac at least so I can make the images I need, so I'm going to move forward with it. I suppose you could do the same on linux, but I haven't tried that yet.

[kookster]

I have been tweaking the text a bit more, using a transform on it 'transform="scale(1,0.93968341)"' to get the height better, and have now produced this from command line: compared with this png from the repo:

This is really close I think, and now I am going to try and write up how to reproduce this result, and cleanup the template I am using for this. (I actually think the version I am getting from the command line looks a bit more readable, FWIW.)

What do you guys think?

[olivierlacan]

@kookster I actually like your render a bit better than ours. This is really good.

@cainus We could ask @rykov directly, that does look really good too.

I've been completely out of it for the last few months, I'm really sorry. Your experiments and any help getting something organized here would be much appreciated. @ackerdev and I bit off more than we could chew trying to build a gem before having a proper rendering process.

[olivierlacan]

@kookster Have you tried to produce a pixel doubled version? One of the reason the automated process is appealing is so that we can produce high density versions of all the badges very quickly if necessary.

[kookster]

@olivierlacan

No apologies needed. You guys gave an aesthetic blessing to all githubbers, but we all need to do other work eventually.

I did try out the render for retina by doubling the resolution specified in the inkscape command to --export-dpi="180,180" instead of `--export-dpi="90,90":

> /Applications/Inkscape.app/Contents/Resources/bin/inkscape "travis_passing2.svg" --export-png="badge_retina.png" --export-dpi="180,180" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0"

Looking at this version, it makes me think the way I am doing shadows (putting a 50% opacity dark fill text slightly lower than the white text) is not quite right, but perhaps playing with the offset can make it look better. I'll comapre against your other retina images and see how close it is getting.

In any case, since the only change necessary was the command line, it at least answers whether the retina can be generated automatically in the same way.

[cainus]

I've got my node.js version running with inkscape (on linux) now at least: http://wapiti.io/api/sizeBadges/prozess . Inkscape renders quite a bit better than the other libs, so thanks for that tip. I think I just have to fix the square corners on the right side (probably a bug in my dynamic image sizing) and the drop shadow. I'd certainly be interested to see how you got that drop shadow.

Thanks again for the pointers.

[kookster]

Here is a quick version of what I did before I get embroiled in family holiday stuff (not a complaint ;).

I installed inkscape from inkscape.org

If you want to run it as a GUI, you have to tell it when it runs where to find X11 (on mountain lion I used /Applications/Utilities/XQuartz).

It is nice to be able to run it to make sure the fonts are loaded properly, preview changes, and see what manipulations to the svg Inkscape makes when you do things like change the height (this is how I figured out the values I use for the transform: scale(x,y)): http://inkscape.org/doc/inkscape-man.html

I also needed to let Inkscape know how to find the Open Sans font. I unzipped the set of font files into ~/Library/Fonts/Open Sans, then added a ~/.fonts.conf file like this (apparently this is how it knows where to find user fonts, as X11 loads them):

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<dir>~/Library/Fonts</dir>
<match target="font">
   <edit name="rgba" mode="assign"><const>rgb</const></edit>
</match>
</fontconfig>

After that I went into the Inkscape.app install to find the command line executable bin, which is here (on Mac obviously): /Applications/Inkscape.app/Contents/Resources/bin/inkscape

The command line I started with is from watching the verbose output of call ImageMagick convert. It apparently bundles some old version of Inkscape in order to do the svg -> png conversion, which is where I got the idea of using inkscape directly.

> convert -verbose -background transparent travis_passing.svg badge_im.png
"inkscape" "travis_passing.svg" --export-png="/var/tmp/magick-37749PRYjIrHJWq0f" --export-dpi="90,90" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0" > "/var/tmp/magick-37749fhm4nS86L2K3" 2>&1
mvg:/var/tmp/magick-377493L8RJ0tK7BjE=>/var/tmp/magick-377493L8RJ0tK7BjE MVG 77x18 77x18+0+0 16-bit sRGB 1.71KB 0.010u 0:00.029
travis_passing.svg SVG 77x18 77x18+0+0 16-bit sRGB 1.71KB 0.000u 0:00.000
travis_passing.svg=>badge_im.png SVG 77x18 77x18+0+0 16-bit sRGB 0.010u 0:00.019

From this I used the following for standard size images: /Applications/Inkscape.app/Contents/Resources/bin/inkscape "travis_passing2.svg" --export-png="badge.png" --export-dpi="90,90" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0"

and this for retina: /Applications/Inkscape.app/Contents/Resources/bin/inkscape "travis_passing2.svg" --export-png="badge.png" --export-dpi="180,180" --export-background="rgb(0%,0%,0%)" --export-background-opacity="0"

Then I used a variety of svgs, and they all seemed to work so long as the text font family was updated to Open Sans. I did find when editing in Inkscape that I needed to save as an Inkscape svg, not a Plain svg, but the extra meta-data it added does not seem terrible, and it seemed to render the existing svgs from the shields project without issue.

I want to clean up the svg before I promote it, but here is my latest version: https://gist.github.com/kookster/5652987

A few tricks -

• I increased the opacity value of the shadow to 50%, and sneakily used a dark green color for the shadow on the green text (it felt sneaky anyway). This green may be unnecessary.
• I have fiddled alot with the y offset of the shadow text, not sure I have found the 'magic' value for this.
• I added a second identical white text element directly on top of the first. This made the white really pop, and much more closely match the existing png. No idea why this was needed, but it seriously helped.
• I tweaked the text in Inkscape GUI, and saw that it applied the following transform to make it the correct height: transform="scale(1.0,0.93968341)" It actually had a slightly higher than '1.0' x value, but it changed the width significantly, so I rounded back to 1.0, and it looks right.

Hopefully that is enough for anyone to get as far as I did, but I'll keep working to make this more systematic and templated.

[kookster]

@cainus I missed your message while I was typing mine. I used one of the shields/travis/travis_passing.svg to start with, and that seems to have corners that work. Maybe try the svg from my gist? https://gist.github.com/kookster/5652987

[cainus]

That was a huge help: http://wapiti.io/api/sizeBadges/Percolator and http://wapiti.io/api/scoreBadges/Percolator use the same dynamic svg generation code, so I have a working service now (with absolutely terrible code). It seems that the gradient markup from the travis svgs is much better than the gradient markup from https://github.com/olivierlacan/shields/blob/master/shield.svg .

I'd like to open source this at some point, but it's absolutely terrible. I took a bunch of shortcuts around the tougher problems (like computing text width), and there is no caching or memoization of anything so it would be a pretty terrible web service if used in production. I'd eventually like to just have a dead simple interface like

var shieldStream = shield(name, value, color);

Instead of the pile of assorted x's and y's I currently pass it.

Anyway... I'll keep improving this if no one comes up with anything better. I really appreciate the pointers so far.

ALSO: please let me know if it's still not looking quite right. I have almost no eye for detail whatsoever. ;)

[kookster]

@cainus - Those look good to me. I agree that a service will require more to scale. I think I will work on the ruby gem to be able to easily generate these, and a cleaned up svg. Then maybe a heroku build pack for Inkscape or something to turn this int a service.

Any tips on how you are calculating width based on text length would help. I figured I could try to to draw the text into an image by itself, and then measure it, or come up with some heuristic based on maximum char width.

Anyway, nice collaborating with you ;)

[kookster]

Making a heroku buildpack for inkscape sux, so it may not be usable for a heroku based service: http://stackoverflow.com/questions/16803478/make-a-heroku-buildpack-for-inkscape-using-vulcan

However, in researching buildpacks, I found this svg2png-cli module, and it is a phantomjs based project which may make more sense for deploying, and it renders pretty nicely:

Here is the project: https://github.com/skyzyx/svg2png-cli

Install: npm install svg2png-cli

Here is an example image using the same svg as I used with inkscape: svg2png -s 1 travis_passing2.svg

...and as a retina 2X: svg2png -s 2 travis_passing2.svg

I'm going to pursue tweaking the svg to be more optimal for this phantomjs based renderer, and then work on a buildpack to turn this into a heroku hosted service.

@cainus, it may also appeal to you since you are already making an npm based app, yes?

[olivierlacan]

This is fucking georgeous @kookster. We need to start rolling out Retina badges with this.

[cainus]

@kookster: looks great! (Sorry about the slow reply... I was on vacation last week.)

Phantom is a good choice for two reasons too: (1) it's probably easier (possible?) to run on heroku than inkscape (2) you might actually be able to use the dom's getBBox() or text.getComputedTextLength() to solve the other problem of text with variable length.

I just didn't expect the output to be that good, and the api is entirely based on reading and writing files, so it looked a bit inconvenient. I'll take a crack at this too though when I get a chance.

[kookster]

you don't need to use the file based CLI, you can use the underlying svg2png https://github.com/domenic/svg2png agreed on the heroku ease of deploy, playing with that now.

Andrew Kuklewicz

On Mon, Jun 3, 2013 at 9:01 AM, Gregg Caines notifications@github.comwrote:

@kookster https://github.com/kookster: looks great! (Sorry about the slow reply... I was on vacation last week.)

Phantom is a good choice for two reasons too: (1) it's probably easier (possible?) to run on heroku than inkscape (2) you might actually be able to use the dom's getBBox() or text.getComputedTextLength() to solve the other problem of text with variable length.

I just didn't expect the output to be that good, and the api is entirely based on reading and writing files, so it looked a bit inconvenient. I'll take a crack at this too though when I get a chance.

— Reply to this email directly or view it on GitHubhttps://github.com/olivierlacan/shields/issues/15#issuecomment-18839270 .

[cainus]

@kookster: totally agree... but if you take a quick peek at that, it requires file-io (and therefore filenames in the api) to work as well. There's not really anything about the problem that should require disk access, and the disk access makes the solution a little trickier for a few reasons, if you want to run it in production. ANYWAY... It's probably most valuable to just get it running first. :) Lemme know how you do... I might get a chance to check into it myself tonight.

[olivierlacan]

Might not be relevant since our goal for now isn't to serve the SVG files but the PNG output instead but this tool looks like a great way to shave some weight off of SVG files.

[chadwhitacre]

Hey all, I messed up. I accidentally launched a badge-as-a-service app (http://badgr.co/) without reading this ticket first. I'm sorry. :-(

@olivierlacan and I met at Waza in February, so I was aware of Shields (and acknowledge it at the bottom of Badgr.co). I needed a fully dynamic badge for Gittip (see https://github.com/gittip/www.gittip.com/issues/21) and I guess I shot first and asked questions later. Such is life. Sorry. :-(

Anyway, wanted to jump in here as soon as I became aware of this ticket. Looks like you're making good progress toward a solution here. How can I help? I would love to get Gittip in the mix as a badge vendor. I'm happy to contribute the badgr.co assets (domain, twitter handle, SSL cert, badger drawing :) ) if you're interested. Otherwise I'll just take it out back and shoot it when this gets launched. :-)

Again, my apologies. Keep up the good work! :-)

[ELLIOTTCABLE]

… and this is why I love @whit537.

[chadwhitacre]

Thanks for the heads-up, @ELLIOTTCABLE. :-)

[olivierlacan]

First, @whit537, allow me to salute the class. :+1:

I can honestly say the more the merrier here, you should not feel bad. I don't think any of us is staking a claim to own the badge space. :smile:

We both clearly want higher quality meta-data to be easily available to open source maintainers. Anything all of us can do to further that goal is fair game in my book.

@ackerdev and I have two things we care very much about: design and semantics

I need to specify my expectations when it comes to a usable badge aesthetic (with a simple graphic), and both @ackerdev and I (as weel as all the good people involved in this project) need to work together to establish simple guidelines on nomenclature. There is a reason we spent time discussing with each vendor and working to convince them not to use badges as billboards but instead concentrate on information that would be relevant to contributors first: [ function of the vendor | related data ].

I understand the flat aesthetic you adopted with badger, and it would probably make it easier to produce badges with a smaller footprint. Oddly what I miss from flat non-rounded badges is the affordance to click them, which is something I do want to encourage, so that people seek and discover more data related to the small piece of meta-data they were shown in a README for instance.

I want third party services to be promoted, albeit indirectly, through the value they create for maintainers and contributors alike. I worry that a flat aesthetic hinders that one goal.

Sure, we could let people pick a theme for their badges, but that defeats the very problem I aimed to solve in the first place. Apart from personal preference, there is no good reason why any badge should visually differ from another. Otherwise we risk seeing the trend we partly curbed with Shields reoccur: a cacophony of different badges, some well-designed, some sloppily put together by developers with little regard for proper presentation.

I definitely think we should offer color choices to developers, but only if the legibility of the color paired with the text is not sub-optimal. I honestly want to avoid the "ask first" approach we're currently stuck with as much as possible, but giving people complete free-reign is problematic for the very reason that caused the need for Shields in the first place: many developers suck a design or they don't really care.

But all this is a lot of talking. Doing is always more valuable, so good job :-) My fault for doing more talking than doing in the past few months.

[chadwhitacre]

Thanks, @olivierlacan.

I'm fully on board with the standardization of badge design across vendors, for the reasons you articulated. I think the flat design is nice, but that's not a hill I'm going to die on, or really fight very hard for at all. :-) I actually started out intending to implement the design you've converged on with Shields. I found myself limited by the tool I chose (Pillow, a fork of the venerable Python Imaging Library [PIL]), and the flat design that was easy for me to implement was also kind of appealing and trendy, so I launched with it. :-) The svg2png route that I see in this thread seems like a great way to implement the more complex design. If Badgr.co were in Node or svg2png were ported to Python I'd have the rounded design rolled out by now. Hmm ... ;-)

Now that I hear you articulate the nomenclature principle, I get where you're coming from there as well. How would you apply that to Gittip's case? Maybe [ donate | weekly ] or [ donate | Gittip ] or [ donate | username ]? I'm reluctant to suggest [ donate | $10 ], because it's unclear what that would mean; it could be any of the following:

• Amount the project has received cumulatively over time
• Amount the project received in some recent interval (week? month?)
• Amount the project is set to receive in some upcoming interval (week? month?)
• Target amount the project would like to receive
• Suggested donation amount (I think this is the most likely interpretation?)
• Amount a user signed in to the vendor's service is currently giving to the project

Also, if there were multiple funding mechanisms that the project supported such as both Flattr and Gittip, what would the badges be? Maybe [ donate | Flattr ] and [ donate | Gittip ]? Or maybe [ Flattr | username ] and [ Gittip | username ] after all? Thoughts?

[ELLIOTTCABLE]

@whit537 here's a suggestion for you (not the be-all-end-all, but just another one to consider): [ donations | $34/wk ]. Gets both the Gittip-spirit (always assumed to be weekly-forever, not a one-time-thing as people might assume), and makes it clear what it's talking about (what it's getting in donations right now).

Alternatively, [ donators | 9 ], which pretty clearly means 9 people donating right now. Doesn't as clearly convey the important (IMO) part, though, that being the Gittip structure of “weekly.”

I really like the first, because it's actually useful information on a project's landing-page / README: It's saying, “This project is currently being financed at $34 a week.” Which conveys both 1. this project has of continuing to exist in the future, and thus I can rely on it that much, and 2. the project is going to see development at minimum, because that's how much the developer is being paid to focus on it. That's useful information, and very intuitive, to any visitor.

As for more information, such as links to donate certain amounts … may I suggest a Testling-esque “table-image?” A bigger image, separate from the badge-image (which needs to be short, succinct, and descriptive), to show, say, a graph of contributions over time, or the number of contributors, or the top contributors (that'd be cool!) … you get the idea. Something to put at the bottom of the README, after the important stuff, not at the top.

Addendum: Wait, since when does Gittip support donations to a specific project? Did I miss that? Or are we talking about a coming-soon feature?

[chadwhitacre]

@ELLIOTTCABLE Here are some projects on Gittip:

• https://www.gittip.com/tastejs/
• https://www.gittip.com/JSFiddle/
• https://www.gittip.com/readthedocs/

There are ways to improve the experience for projects on Gittip, but the early adopters are on there today.

I like where you're going with [ donations | $34/wk ]. It fits the model of "metadata". It's not a call to action, I guess that happens elsewhere.

[cainus]

I've almost got a command-line tool working for this now. Someone else could take it and use it in a web service once it's complete (It'll probably take a few more days). It takes as parameters "png-name", "vendor-text", "status-text" and "color" (red, yellow, yellow-green, green, or gray) and writes the resulting png with the given name. The quality is pretty good AFAICT... I've tried imagemagick, inkscape, and now I'm finding that phantomjs is rendering them the best.

I'm using the svg's in this repo to get the styling right, with a javascript dom to manipulate them and get the dynamic sizing right. Node is probably an unfortunate dependency for some, but I don't think this would be very easy in another language just because I assume other languages don't have an SVG dom that can do things like getBBox() to easily compute text-width.

Anyway, if you're interested, let me know. I'm very happy to let someone else build the service around it, if anyone cares to.

[ELLIOTTCABLE]

@whit537, others: what about a hover-state? Can we achieve that within a README? Or, alternatively, an animated-SVG / .gif, that flashes multiple pieces of data and a call-to-action? (If so, please make it optional … not everybody will want their READMEs splattered with eye-catching animations. That said, done well, and subtly, it could be excellent.)

[ donations | $34/wk ]
[ donations | 9 ppl ]
[ give now! | <3 ]

[ackerdev]

I know, I'm late to the party.

+1 to everything @olivierlacan said. No bad blood between us and @whit537. (Seriously, who could be mad at a guy that nice) :smile:

As for the badge details, I'm definitely inclined to say that the donations | $34 / week model is best; gets across the point and even mirrors the very data shown on gittip itself. The only thing I worry about is what @whit537 brought up about other donation services, simply because the donation model is quite different. Though, since those services do not really keep a running tab I would be inclined to say that static donation services should mirror something closer to Flattr | username since I don't think Flattr | $653 really says anything truly useful if $653 is the total of all donations since existence (maybe it got that many donations 3 years ago before X new project came along and now it's been abandoned...).

@ELLIOTTCABLE An interesting approach, I'll give you that, though unfortunately we can't make use of hover-states to my knowledge. I also dislike the idea of offering gif animated badges. I think it adds visual noise we don't need, as we can generally get the most pertinent information available in one badge. The more subtle it is, the more it removes that visual noise, perhaps, but it also leads to people not realizing there's more information 'hiding' in the animation.

@cainus Nice. I haven't played with phantomjs through ruby, but I would have to imagine there would be a way to send JS to it. It really isn't the end of the world if it were to have to be done in node, if this were to be used as a service. (And having a node shield generator to offer would be cool too).

[chadwhitacre]

Thanks @ackerdev. :)

I went ahead and changed the Gittip text on badgr.co to [ donations | $34 / week ]. E.g.:

I also poked around: There is a PhantomJS clone for Python called Ghost.py, which could potentially be used to do the svg2png transform. I'm also not opposed to Node.

[cainus]

@whit537 @ackerdev Yeah I'm going to retract what I said about node being the only feasible way... I think you should be able to inject the manipulation js from any platform that can run phantom. I'll have a good first draft of that js soon. I'm just having some troubles with the right-most curves after dynamic resizing, but those are almost worked out.

[chadwhitacre]

@cainus Didn't @kookster already work this out (comment: https://github.com/olivierlacan/shields/issues/15#issuecomment-18653602)?

What's to work out? Do you just need his svg, or what?

[chadwhitacre]

Hey all, @olivierlacan and I are going to have a Google Hangout On Air tomorrow afternoon, June 13, at 3pm US/Eastern (time translator) to discuss this project. If anyone on this thread cares to join us that'd be awesome! Let's figure out a plan and get this launched!

If you want to be a part of the Hangout tomorrow then please drop me a line at chad@zetaweb.com. I'll email the link to join the Hangout tomorrow when the time comes.

Thanks! :D

[cainus]

@whit537 @kookster the tricky parts are dynamically sizing the width based on the contents of the text. What I'm aiming for is something where you can say

shield "build" "broken" "red" "brokenbuild.png"

or

shield "donations" "$46 / wk" "green" "somepng.png"

... etc, and it will spit out the proper png. That's tricky because different pieces of text have different widths. It wouldn't be so bad if it wasn't for the curved corners, but that's what makes these things look like buttons worthy of a click.

It's not that hard really... I've almost got it (using a tweeked version of @kookster 's svg). And I think you can use my javascript from any phantom wrapper.

[ackerdev]

@cainus @kookster I know I'm really late to the party and there's too much to catch up on... have you guys tried shield.svg in the root of this repo? I tried to make it as easy as possible to edit on the fly.

[cainus]

@ackerdev yeah I'm basing my work on a mash of your svg and a tweaked travis one that @kookster gave me, which is basically this: https://github.com/cainus/shielded/blob/master/lib/shield.svg . They're all easy to edit on the fly (I thought at first I could just use a template engine for this!), but the background and curved corners don't reflow when the text changes length, so I had to do that programmatically.

It works now. I just have to put the command-line interface up around it, so I'm pretty sure I'll have something to show tomorrow. Ruby and Python guys can steal my convert function from https://github.com/cainus/shielded/blob/master/lib/converter.js to use with phantom on their platform of choice. That's where all the magic is. "Scale X 2" works for retina usage too.

[ackerdev]

@cainus Yeah unfortunately SVG DOM doesn't work quite like HTML does in that respect, text can't be contained by another element for the rect or anything like that. Good to hear that you've got it working.

(Also, ignore the accidental close, logged back in and click to focus mouse on chrome before knowing it was over the close button...)

[ackerdev]

Looking at the SVG you linked, I see a lot of illustrator-junk in it that probably made that way harder than it needed to be. Resizing text with shield.svg should have been as simple as editing the appropriate rect.width and path's M value.

What is different about this new SVG that @kookster supplied? Did it fix an issue with shield.svg rendering?

[chadwhitacre]

Okay! Just wrapped up the call with @olivierlacan. Here it is: http://www.youtube.com/watch?v=DW_kDoeBEC0

There's a few notes from @ackerdev in IRC as well.

I believe where we stand is that we're going to let @ackerdev @cainus and @kookster finish up their excellent work on the PhantomJS rendering process, and then we'll see about wrapping it back up into a service. It sounds like the choice of Ruby, Node, Python, etc. to implement the service will be up to whomever steps forward and takes that on. :-)

Branding options:

• http://shields.io/ - @olivierlacan owns this and was planning to use it; currently redirects to Shields on GitHub.
• http://badgr.co/ - this is live now but renders wrong

[kookster]

@ackerdev you can see at the bottom of this comment where I describe the svg changes I made as 'tricks':

https://github.com/olivierlacan/shields/issues/15#issuecomment-18464125

[ackerdev]

@kookster Ah, okay. Just things to change how the badge looks, not particularly fixing any major issues with rendering out. Those can definitely be added to shield.svg.

[cainus]

@ackerdev It's actually trickier than just changing the M value. The code is pretty terrible still, but probably easy enough to see the other changes: https://github.com/cainus/shielded/blob/master/lib/converter.js#L82

That was a tough way to learn SVG. ;)

I'm certainly not opposed to simplifying or using different SVG either, as long as its got the end-result of @olivierlacan 's design.

It'll be usable sometime tomorrow. I'll build the node service too just because that'll probably only take me a half hour and it'll make it easier to show you guys the output for feedback. I have no eye for design whatsoever, so I've probably messed up one detail or another.

[kookster]

@cainus awesome. If you get this working as a node.js app/service, then we are done. I had started on a ruby-ish version, but I see no reason to continue if you get this working, and I can instead turn my attention back to the side project that got me interested in this in the first place ;)

[ELLIOTTCABLE]

I'm down for Node, @cainus. I'll take a second-look at your code when you're done, if you like; or if you've got anything you'd like to farm out to me, point me at the code and let me know. (=

[cainus]

@ELLIOTTCABLE @ackerdev @kookster @olivierlacan @whit537 :

Alright... It's running at: http://calm-shore-6115.herokuapp.com/?label=did%20it%20work?&value=yes!&color=green&scale=1

The server code is at: https://github.com/cainus/shield-server

The command-line tool and node library are at: https://github.com/cainus/shielded

Any feedback is appreciated. I have no eye for graphical detail whatsoever. The code is also just "first-pass" quality (ie it's terrible). Pull requests are appreciated as well of course. :)