New Fedora 13 Goddard Backgrounds Comming!

UPDATE 1st May 2011: If you wonder why this rather old post appeared on fedora [design] planet, it's because I discovered a typo in one of the post labels and fixed it, and the planets think the post got updated... Sorry about the noise.

Yes, it's the time of the release cycle again. The time where new wallpaper comes to your machines. Well, strictly speaking not yet but the design-team decided on the default wallpaper for Goddard (Fedora 13) Alpha and I've packaged it, prepared a scratch build and put it up for review. The division this time is like this:

• goddard-backgrounds — installs everything (and a kitchen sink ;-P)
• goddard-backgrounds-gnome — the default wallpaper for Gnome
• goddard-backgrounds-kde — installs the default wallpaper for KDE
• goddard-backgrounds-single — contains images for single screens
• goddard-backgrounds-dual — not yet present but will contain dual screen images
• goddard-backgrounds-extras-{single,dual,gnome,kde} — not yet present but if we put together extras wallpapers this is where they'll reside; the division is same as for the default ones

I hope this division is final (I really feel we need naming guidelines for this stuff as so far with every release we used a bit different naming scheme :-( ) and will be used without problems for all future wallpaper releases as well. Oh and here's a screenshot of it in action:


Update: Oh, and... One of the magic ways how to install the gnome versions without much hassle is this:
Start terminal, then

$ wget 'http://koji.fedoraproject.org/koji/getfile?taskID=1994836&name=goddard-backgrounds-gnome-12.91.0-1.fc14.noarch.rpm' 'http://koji.fedoraproject.org/koji/getfile?taskID=1994836&name=goddard-backgrounds-single-12.91.0-1.fc14.noarch.rpm'
$ pkcon install-local *goddard-backgrounds*

The '*' are there because wget saves the package as getfile?taskID... :-( Don't forget to remove the downloaded packages afterwards.

Yum-presto + University internet connection isn't a very good combo

Well, yum-presto is all cool and awesome and all, but with the lzma compression in F12 it's rather slow with rebuilding the rpms... Which means that with internet connection that can be found on many universities (up to about 10~11 MB/s when downloading from fast mirror) it's slowing the package download considerably. Here're the data from today's update.
<delta rebuild> | 79 MB 04:02
Presto reduced the update size by 65% (from 79 M to 28 M).
Package(s) data still to download: 136 M
Total 4.5 MB/s | 136 MB 00:30

Now, I wonder whether I should keep it or remove it (as half of time I use slow connection and the other half fast connection)...

YouTube and HTML5

So, I've noticed there's a html5 testing page on youtube. It won't work in gecko based browsers (it's not ogg theora) but it works on fully updated fedora 12 using a webkitgtk based browser (e.g. midori or epiphany; chromium builds still don't support video tag and I don't know anything about the webkit version in qt). The difference is great. Although not everything works as with Flash based youtube, some basic functions like pausing, seeking and such are already working smooth. And what's best is that the implementation is fully opensource (sans usage of patent encumbered codecs), does not crash as often (maybe does not crash at all, but I haven't done any rigorous testing) as adobe flash does and eats about half of the CPU compared to flash and nothing in paused state (while flash still eats CPU even when the youtube video is paused). I just hope the implementations will keep going forward an will make it's way away from just one testing video to full implementation.

The HTML5 enabled video (i.e. you don't need any browser plugins enabled, but you'll need some gstreamer stuff from rpmfusion [gst-ffmpeg] if you're using webkitgtk): http://www.youtube.com/html5

and the same video using flash: http://www.youtube.com/watch?v=uofWfXOzX-g

Very quick update: I've just noticed that when you hover over the video previews in the columns on the right side of the page, the hovered video will play in fast speed. Neat.

And another quick update: Right-click on the video and you can download it! I cannot wait for the day this will be the youtube.

Answer to: Why is my design blurry?

Short answer – unlike paper, display is a discrete medium.

Long answer, bellow.

When you prepare designs that will be printed, or when you are painting on paper, you usually do not have to care about some "pixel" grid. Thanks to the small size of dots when printing or the small size of paint particles when painting, you don't have to worry about fitting them in a grid, either because there is no grid at all or because the particles are much smaller than an eye could discern. On the other hand, displays have rather big grids, with resolution usually about 100 dpi, which means there are 100 particles per inch. You can easily imagine that with such small resolution, people with good eyes easily notice when something is not aligned to this grid, or isn't smoothed (we call it antialiasing).

For inkscape, cairo and other similar libraries and applications we can visualize the pixel grid like this:

The black lines represent coordinates used by cairo, inscape, ... while the squares inbetween are the actual pixels. Now imagine you'd like to draw a blue rectangle on (1,1) with width = 6 and height = 4. If you pass these numbers as its coordinates it will look like this:

This is fine, as the rectangle nicely fits into the grid. Such a rectangle would look crisp if displayed in 1:1

Now, if you decide to draw it with 1px wide border at the same coordinates with the same dimensions, how it will look like? Will the border be drawn outside the original rectangle or inside it? Neither is correct:

As you can probably guess, this will look blurry as the border ended up in between the pixels and thus is misaligned. You can correct this by shifting the position by 0.5px and making the dimensions smaller by twice the value:

If you now compare the two cases in original size, I think anyone can see (at least with the help of magnifier) the difference:


This work very similar for other shapes as well. It's important to bear in mind that the imaginary line in terms of coordinates marks the boundary of fills but the center of borders and that the grid lines are inbetween the pixels. You have to position your drawings appropriately in order to look crisp.

But what about fonts? See my previous post to see the main problem with them. Sadly inkscape does not offer better smoothing than greyscale for fonts, so you have to either use gimp, or align each letter manually (tedious).

Mark the difference (ugly fonts in Fedora?)

So, in my previous post there started appearing discussion about fonts antialiasing. So I though it would be better to spin off this discussion in a post of it's on, installed freetype-freeworld (which improved drastically fonts in chromium, but did nothing with gtk), fired up gimp and created this (click on the image to see it in its original size if it looks blurry):

The first line is no antialiasing, no hinting, the second one is antialiasing only, the third one is antialiasing+hinting and last one is antialiasing+hinting with forced autohinter. Looks like no hinting or autohinter is what can be achieved without installing the package from rpmfusion, while the third line needs the package with patented stuff in. Apparently, no antialiasing isn't a solution – we're not living in stone age, antialiasing without hinting is blurry and autohinter works good only for small sizes, on the other hand, the hinting without autohinter breaks on simple japanese… Make your own image about what's best.

And as a bonus: hinting without autohinter in chromium


autohinter in midori


Dunno how you, but I see the autohinter as best working for me.