1. phpLiteAdmin Avatar phpLiteAdmin
  2. phpLiteAdmin
  3. public
  4. Issues

Favicon size and license issues

Issue #185 resolved
dreadnaut created an issue

Originally reported on Google Code with ID 185

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

Reported by dreadnaut on 2013-03-03 13:31:03

Comments (16)

  1. Christopher Kramer 
    ä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

    Reported by crazy4chrissi on 2013-03-07 13:15:10 - Status changed: Accepted

  3. dreadnaut reporter 
    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

    Reported by dreadnaut on 2013-03-07 13:47:18

  4. dreadnaut reporter 
    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).

    Reported by dreadnaut on 2013-03-08 15:17:48 - Status changed: Started

    <hr> * Attachment: logo.png<br>logo.png

  5. Christopher Kramer 
    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.

    Reported by crazy4chrissi on 2013-03-09 13:17:23

  7. dreadnaut reporter 
    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.

    Reported by dreadnaut on 2013-03-10 10:37:30

  8. dreadnaut reporter 
    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)

    Reported by dreadnaut on 2013-03-10 23:24:09

  9. dreadnaut reporter 
    Attached is a patch against... my other patch in Issue #157, just to get an idea of
the code involved.

    Reported by dreadnaut on 2013-03-10 23:29:54

    <hr> * Attachment: favicon-rxxx.diff

  10. dreadnaut reporter 
    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.

    Reported by dreadnaut on 2013-03-13 12:27:47

    <hr> * Attachment: favicon-rxxx.diff

  11. dreadnaut reporter 
    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.

    Reported by dreadnaut on 2013-03-13 20:01:55 - Status changed: Fixed

  13. Christopher Kramer 
    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.

    Reported by crazy4chrissi on 2013-03-13 20:17:35

  14. dreadnaut reporter 
    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.

    Reported by dreadnaut on 2013-03-13 20:21:54

  15. Christopher Kramer 
    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.

    Reported by crazy4chrissi on 2013-03-13 23:54:45

  16. dreadnaut reporter 
    I'm uploading the favicon as png, together with the other logos, so we have a separate
copy.

    Reported by dreadnaut on 2013-03-15 15:30:04

  17. Log in to comment
Assignee
–
Type
proposal
Priority
minor
Status
resolved
Component
–
Milestone
–
Version
–
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!