[sugar] icon assistance/validation

[Eben Eliason]

Hello all -
I wanted to formally conclude this thread by pointing out the tangible
outcome of the discussion.

I've posted the sugar-iconify script to the wiki.  You can find a download
link and "man" page here: http://wiki.laptop.org/go/Sugar-iconify.  This
page also links to the more comprehensive guide on making Sugar icons, which
is located here: http://wiki.laptop.org/go/Making_Sugar_Icons.  The latter
page compiles most of the information I found on the multitude of older
pages which all contained partial and occasionally inaccurate information,
and which now redirect to this new authoritative source.  The new page has
been organized and supplemented with additional details, and sections exist
both for making use of the sugar-iconify script and for manually editing the
SVGs by hand.

I still have some more details and examples to flesh out before I call it a
day, but the content already there should serve anyone well when getting
started with the creation of Sugar icons.  If you notice any
inconsistencies, still have questions, or find any bugs in the posted
script, please let me know or post feedback in the discussion page on the
wiki.  Thanks!

Happy icon hacking!

- Eben



On Tue, Mar 18, 2008 at 11:19 PM, Eben Eliason <eben.eliason at gmail.com>
wrote:

>
>
> On Tue, Mar 18, 2008 at 6:09 PM, Gary C Martin <gary at garycmartin.com>
> wrote:
>
> > On 18 Mar 2008, at 20:13, Eben Eliason wrote:
> >
> > > I can remove the stroke-opacity altogether.  As mentioned before, I
> > > don't have any particular goal in mind with respect to that
> > > property...I just implemented it at the same time as fill-opacity
> > > because it was easy to add.  I do want to keep the fill-opacity so we
> > > can take advantage of it in the future, though.  It is something that
> > > may not be implemented immediately, but would make the code much
> > > cleaner once we are able to support it.
> >
> > What would happen to overlapping fill areas if opacity starts getting
> > fiddled with? My understanding is that the overlap areas will be
> > additive and there for more opaque than non-overlapping areas leading
> > to fuggly shapes appearing. Icon designers would need to always build
> > all non trivial fill shapes out of little bits of non-overlapping
> > primitives. That's quite a tall order.
> >
>
> Yeah, the more I've been playing with this, the more I'm realizing that it
> might not be feasible.  The "hack", while semantically less clean and
> requiring a few more lines of code, actually makes development of the icons
> easier in general, and ensures that their look will be retained.
>
>
> >
> > If there really is some great feature that needs alpha, can the SVG
> > not just be rendered in to a pixbuff, and then the pixbuff be
> > composited into a widget with alpha. This way the SVG is 'flattened'
> > so that you can dial up/down the transparency across the whole image
> > without fuggly bits appearing.
> >
>
> Well, not exactly, as the goal is to render the "strokes" opaque gray and
> the "fills" transparent (Those are in quotes since you can have both in
> either color, technically).  I suppose, however, that you could easily use
> the entities to paint strokes white and fills black, render it to a pixbuff,
> and apply it as a mask to a solid of the desired color.  That would
> certainly do the right thing.
>
> Of course, in order for this to serve the purpose we're after, you have to
> be able to create the pixbuff with the fill at various levels of gray, and
> treat the result as a true alpha channel, and not as a bitmask.  If you want
> to take a stab at this approach, feel free.
>
> - Eben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080321/993c61d7/attachment.htm