search

hanigamal / phpliteadmin

Automatically exported from code.google.com/p/phpliteadmin
0 stars 0 forks source link

Favicon size and license issues #185

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I went to check the favicon we are using since r300 (and serving from svn) to 
see if we could encode it and included as a resource in the source cose: a 
16x16 image should not be that large.

That's when I realized that the favicon is actually a full "desktop" icon 
ranging from 16x16 to 256x256 in 8 and 32bit versions, summing up at a whopping 
*152KB*. Moreover, the icon comes from here:

http://www.softicons.com/free-icons/toolbar-icons/database-application-icons-by-
artistsvalley/regular-filter-feather-icon

and has a license stating that "The icons should not be packaged or sold in any 
form of individual libraries or stand alone products."  We are borderline here, 
since we don't exactly package it, but the license also requires attribution.

I'd like to replace it with a smaller favicon, based on either the b/w feather 
or the logo on the Google Code pages. If small enough, we can also encode it as 
a 'data' URL or an internal resource (see issue #157).

Original issue reported on code.google.com by dreadnaut on 3 Mar 2013 at 1:31

GoogleCodeExporter commented 9 years ago 
ähm. Teryaki, was this your source of the icon?

I agree that we should better use another icon if this is the case. And that 
152kb is too big anyway!

I converted the project-page logo into a 16*16 ico-file. It is attached. One 
version with white background, one transparent. The transparency is not perfect 
yet, as there is a white/light border around the icon

Original comment by crazy4ch...@gmail.com on 7 Mar 2013 at 1:15

GoogleCodeExporter commented 9 years ago 
Hmm. Attachment fail!?

Original comment by crazy4ch...@gmail.com on 7 Mar 2013 at 1:18

Attachments:

GoogleCodeExporter commented 9 years ago 
We could also use a PNG image, if smaller (w/ optipng, pngcrush or similar). 
The only browser which would have trouble with a png favicon is IE6 (see 
http://stackoverflow.com/questions/1344122/favicon-png-vs-favicon-ico-why-should
-i-use-pngs-instead-of-icos ).

At that point, we can resize the prject logo, which is transparent and has no 
white outline:
http://code.google.com/p/phpliteadmin/logo?cct=1358201836

Original comment by dreadnaut on 7 Mar 2013 at 1:47

GoogleCodeExporter commented 9 years ago 
Here's a 16x16 png file, down to 438B, which become 606 bytes as a data: URL.

We can either include it inside the <head> tag (+606B each page load) or as a 
resource (+1 http request, cacheable, no increase in page size).

Original comment by dreadnaut on 8 Mar 2013 at 3:17

Attachments:

GoogleCodeExporter commented 9 years ago 
Looks great. A factor of 350 smaller ;-)

I think both approaches are okay. With the resource approach, we also get IE7 
to work (although I think that's of no importance at all for the favicon).

But the faster solution is also the resource. In PLA, you usually do at least 5 
clicks. That's at least 3KB of favicon loaded with the data-url approach. With 
the resource approach, it is 438B + 1 http request. This already beats it and 
it scales a lot better when you do a lot of clicks.

We could also consider serving it from google svn again, which I think is also 
very good because they have fast servers in cdns, headers properly set for 
caching, enables proxy-caching, uses spdy and so on. And a cookieless request 
from a different  server in parallel can be a lot faster than a request from 
the same server with session cookie and so on.

But in the end, we are talking about serving a 438B favicon. It doesn't matter 
much.

Original comment by crazy4ch...@gmail.com on 9 Mar 2013 at 1:17

GoogleCodeExporter commented 9 years ago

Original comment by crazy4ch...@gmail.com on 9 Mar 2013 at 3:20

GoogleCodeExporter commented 9 years ago 
As I wrote before, I don't like too much serving from svn:
- I'm not sure it doesn't go against some of Google's term of service
- requires an internet connection
- breaks the "all-included" style (another "principle" we might discuss about, 
btw —somewhere else)

and as you said, it all just for a tiny icon :)

I also like the resource style more, so I'll get this ready together with #157; 
this way we can retract the larger icon before release.

Original comment by dreadnaut on 10 Mar 2013 at 10:37

GoogleCodeExporter commented 9 years ago 
Bad news: no version of IE accepts a png favicon, not even IE10. I had to 
switch to .ico, which means 1.1KB of binary data for the image above.

Good news: ico files compress very well, so we can store and output 'deflated' 
data by adding the correct header:

  header('Content-encoding: deflate');
  echo base64_decode( .... );

Very good news: ico -> gzdeflate -> base64_encode gives us 380B of data, even 
less than the png file! :)

gzdeflate() might be a good idea for resources in general, once we have the 
build script ready! (Issue #190)

Original comment by dreadnaut on 10 Mar 2013 at 11:24

GoogleCodeExporter commented 9 years ago 
Attached is a patch against... my other patch in Issue #157, just to get an 
idea of the code involved.

Original comment by dreadnaut on 10 Mar 2013 at 11:29

Attachments:

GoogleCodeExporter commented 9 years ago 
Updated patch for this too, much simpler code.

I'll also place the new favicon in a 1.9.4/resources/ subdirectory. At the same 
time, I'll remove the larger file in the /themes/ directory.

Original comment by dreadnaut on 13 Mar 2013 at 12:27

Attachments:

GoogleCodeExporter commented 9 years ago 
I replaced the resource string with the gzipped (vs deflate) version, and 
committed as r354. I forgot the commit message though, I added it as a comment.

Original comment by dreadnaut on 13 Mar 2013 at 8:01

GoogleCodeExporter commented 9 years ago

Original comment by dreadnaut on 13 Mar 2013 at 8:02

GoogleCodeExporter commented 9 years ago 
Great, thanks.

Maybe I should "purge" (permanently delete) the old favicon from svn just to be 
on the safe side (regarding the license). But as svn doesn't make this too 
simple (see my blog post 
http://blog.christosoft.de/2012/02/subversion-svn-permanently-remove-files-from-
repository-history/ ) I might do it after the release of 1.9.4.

Original comment by crazy4ch...@gmail.com on 13 Mar 2013 at 8:17

GoogleCodeExporter commented 9 years ago 
Looks dangerous :-p  Since the icon was added and removed between 1.9.3 
and 1.9.4 we never actually released it or packaged it, so it might be 
fine anyway.

Original comment by dreadnaut on 13 Mar 2013 at 8:21

GoogleCodeExporter commented 9 years ago 
It's not that dangerous. You get a dump in step2 which is your life-saving 
backup. If you want to, you can install the dump somewhere to make sure it is 
working. If the filtered dump won't work, you can import the old one again.

I have done it several times and it always worked out. But it's something you 
don't do without a good reason. And yes, we never really released or packaged 
the file, but it will still be available from svn unless we purge it. Not a big 
deal, but I just prefer to be on the safe side.

Original comment by crazy4ch...@gmail.com on 13 Mar 2013 at 11:54

GoogleCodeExporter commented 9 years ago 
I'm uploading the favicon as png, together with the other logos, so we have a 
separate copy.

Original comment by dreadnaut on 15 Mar 2013 at 3:30