[racket-dev] Icons issues

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Dec 5 17:51:55 EST 2011

On Mon, Dec 5, 2011 at 4:45 PM, Neil Toronto <neil.toronto at gmail.com> wrote:
> On 12/05/2011 02:49 PM, Robby Findler wrote:
>>
>> Matthew, Neil, and I have been talking about how to resolve the
>> dependency problem. I think that the our thinking was that the best
>> plan is to break out a "pict" library that both slideshow and drracket
>> can safely depend on, and have the icons library depend on that.
>
>
> Yes. Then DrRacket could build its icons as it currently does, by combining
> primitive icons. Updating the primitive icons would only require changing
> the SVG sources and re-rendering the PNGs.
>
>
>> We didn't consider putting some of it into 'meta', tho. That makes a
>> lot of sense to me. Neil, Matthew, how does that sound?
>
>
> It could be the wrong thing to do in the future.
>
> I don't think it would help much now with size, if that's the issue, because
> the SVGs are only 400-800K uncompressed. (As XML, they compress well.) PNG
> renderings of the SVG icons in various colors and at various sizes take up
> almost all the space, and these have to be in any distribution that includes
> icons/main.rkt.
>
> If Racket could render SVGs, we could save space in every distribution,
> allow icons to be arbitrarily colorized, and render them at arbitrary sizes
> instead of just sizes between 8 and 64. This would also make it wrong to
> move the SVGs to `meta'.
>
> I briefly looked into rendering SVGs just now. Apparently, Cairo can't do it
> natively. We'd need to use a third-party library like librsvg.
> Alternatively, I could make partial support for SVG rendering into a holiday
> project, for after the FLOPS deadline. I think our dc<%>s and brushes can
> handle everything in the icon SVGs except blur, which isn't strictly needed.
>
> At any rate, SVG-backed picts would be useful for more than just icons.

This would be the best thing. But I fear it wouldn't be done by the
release, so we probably need an intermediate solution.

The meta collection would be for dependency/cleanliness issues, not size.

Robby

>> Name: I think it is called the icons collection because that's where
>> the icons were before when Neil generalized things.
>
>
> Right. The logos were already there.
>
>
>> We could make a
>> 'sprites' collection and then move maybe even move planetcute into
>> that collection?
>
>
> I'd be okay with a `sprites' collection: `sprites/planetcute',
> `sprites/icons', `sprites/logos', etc.
>
>> On Mon, Dec 5, 2011 at 1:35 PM, Eli Barzilay<eli at barzilay.org>  wrote:
>>>
>>> * The "Making New SVG Icons" section should really be elsewhere -- and
>>>  IMO, this kind of text should go into some readme file...
>
>
> I agree. It's on my to-do list now.
>
>
>>> * And a minor picky point: when I compare
>>>  "magnifying-glass-left-shiny.svg" and
>>>  "magnifying-glass-left-diffuse.svg", they are both cropped at the
>>>  top (at least the way that they're rendered in Emacs),
>
>
> That's odd. They shouldn't be. Their page sizes are the same as every other
> icon, so I'd say the problem is in whatever library Emacs uses to render
> them.
>
>
>>>  but in
>>>  addition they're at different places (which is visible in the PNG
>>>  rendered files too).  I wouldn't have pointed it out, but it might
>>>  be some bug in your rendering script.
>
>
> I centered the icon using the entire picture, but centering it using just
> the magnifying glass (without the handle) is worth trying.
>
> Neil T



Posted on the dev mailing list.