Technology Tales

Fixing Background Image Display in GNOME Shell 3.10

On upgrading from Ubuntu GNOME 13.10 to Ubuntu GNOME 14.04, a few rough edges were to be noticed. One was the display of my chosen background image: it was garbled. Later, I discovered that there is a maximum width of 2560 px for background images in GNOME Shell these days and that things get messy beyond that.

In my case, the image width was around 6000 px and I was used to its getting resized in GNOME Shell 3.8 and its predecessors. It seems that the functionality got removed after that though so the workaround of manual image resizing in the GIMP needed to be employed. Though having big images open in memory creates an additional overhead, not handling them very well at all looks like a bug caused by setting 2560 px as a maximum screen width for the GNOME Shell panel and the complete removal of Nautilus from desktop rendering duties. Let’s hope that sense is seen with ever larger screen sizes and resolutions coming our way.

It’s the sort of thing that did get me looking at adding on Cinnamon 2.2 for a while before setting background image scaling using the indispensable GNOME Tweak Tool was discovered. LinuxG.net has a useful tutorial on this for anyone with such an adventurous streak in them. For now though, I am OK with my set up but the GNOME project’s focus on minimalism could affect us in other ways so I can see why Clem Lefebvre started the Cinnamon one primarily for Linux Mint and the desktop environment is appearing elsewhere too. After all, Gedit lost its menu bar in GNOME 3.12 so it’s just as well that we have alternative choices.

Update 2014-05-06: It seems that the desktop image bug that afflicts GNOME Shell 3.10 got sorted for GNOME Shell 3.12. At least, that is the impression that an Antergos instance in a VirtualBox virtual machine gives me.

Improving Font Display in Fedora 15

When I first started to poke around Fedora 15 after upgrading my Fedora machine, the definition of the font display was far from being acceptable to me. Thankfully, it was something that I could resolve and I am writing these words with the letters forming them being shown in a way that was acceptable to me. The main thing that I did to achieve this was to add a file named 99-autohinter-only.conf in the folder /etc/fonts/conf.d. The file contains the following:

<?xml version=”1.0″?>
<!DOCTYPE fontconfig SYSTEM “fonts.dtd”>
<fontconfig>
<match target=”font”>
<edit name=”autohint” mode=”assign”>
<bool>true</bool>
</edit>
</match>
</fontconfig>

This forces autohinting for all fonts so that text looks better than it otherwise would. Apparently, Fedora 15 has seen the incorporation of the TrueType bytecode interpreter (BCI) into FreeType now that its patent has expired. To my eyes, this has worsened font rendering so I incorporated the above from a post by Kevin Kofler and it seems to have done the trick for me. However, I also have added the GNOME Tweak Tool and that allows you to alter the autohinting settings too so it may be a combination of the two actions that has helped. Anything that helps rendering of letters like k only can be a good thing. Another Linux distribution whose font rendering has not satisfied me is openSUSE and I am now set to wondering if the same approach would help there too, albeit without the GNOME Tweak Tool until a GNOME 3 version of that distro comes to fruition.

Worth the attention?

The latest edition of Web Designer has features and tutorials on modern trends one new ways to use fonts and typography in websites. One thing that’s at the heart of the attention is the @font-face CSS selector. It’s what allows you to break away from the limitations of whatever fonts your visitors might have on their PC’s to use something available remotely.

In principle, that sounds a great idea but there are caveats. The first of these is the support for the @font-face selector in the first place though the modern browsers that I have tried seem to do reasonably OK on this score. These include the latest versions of Firefox, Internet Explorer, Opera and Chrome. The new fonts may render OK but there’s a short delay in the full loading of a web page. With Firefox, the rendering seems to treat the process like an interleaved image so you may see fonts from your own PC before the remote ones come into place, a not too ideal situation in my opinion. Also, I have found that this is more noticeable on the Linux variant of the browser than its Windows counterpart. Loading a page that is predominantly text is another scenario where you’ll see the behaviour more clearly. Having a sizeable image file loading seems to make things less noticeable. Otherwise, you may see a short delay to the loading of a web page because the fonts have to be downloaded first. Opera is a particular offender here with IE8 loading things quite quickly and Chrome not being too bad either.

In the main, I have been using Google’s Fonts Directory but, in the interests of supposedly getting a better response, I tried using font files stored on a test web server only to discover that there was more of a lag with the fonts on the web server. While I do not know what Google has done with their set up, using their font delivery service appears to deliver better performance in my testing so it’ll be my choice for now. There’s Typekit too but I’ll be hanging onto to my money in the light of my recent experiences.

After my brush with remote font loading, I am inclined to wonder if the current hype about fonts applied using the @font-face directive is deserved until browsers get better and faster at loading them. As things stand, they may be better than before but the jury’s still out for me with Firefox’s rendering being a particular irritant. Of course, things can get better…

Exploring the mobile web

With a change of job ahead of me, I decided to make my web usage a little more mobile. The result was the purchase of a Blackberry 8520 Curve on a T-Mobile pay-as-you-go tariff to complement my existing phone. Part of the attraction was having email on the move and a little web access too. On both accounts it hasn’t though GPRS isn’t the speediest for web browsing and you get to appreciating mobile versions of websites. It’s just as well that this website that you’re reading has a mobile version.

Hooking the Blackberry up to GMail was no problem once I had paid my dues and the necessary set up was done for me; it was only then that the required option was available through the set up screens. RIM’s own web browser may be no slouch when it comes to rendering websites but I put Opera Mini in place as well for those times when the default option could be bettered and they exist too. Speaking of RIM applications, there’s one for Twitter too though I added Übertwitter for sake of greater flexibility (it can handle more than one account at a time, for example). In addition, I have instated applications for WordPress and LinkedIn too and it was then that I stopped myself spending too much time in Blackberry App World. If I was of the Facebook persuasion, I might be interested in the default offering for that as well but I have learnt to contain myself.

Of course, there are limitations to the device’s capabilities with regards to email and web on the move. Long emails still need desktop access (messages can get truncated) and mobile unfriendly websites will take an age to load and explore; a small screen means much more finger work. After all, this is a small device so the observations aren’t really surprising; it’s just that I encounter the reality of life on a small screen now. Nevertheless, useful site like those from Google and the Met Office have a mobile variant though I’d like to see the latter including its rain radar as part of the package.

Speaking of life on a smaller scale, there’s the size of the keyboard to consider too. So far, I haven’t had much practice with it but I am unsure as how some craft longer blog entries with the the tiny keys. Then, there’s the ever-present threat of arm discomfort and RSI that you have to watch. For that reason, I’ll stick with use for an hour at a time rather than going mad altogether. Navigating around the screen using the tiny trackpad is something to which I am adjusting and it works well enough too so long as you’re not looking through long web pages or emails.

To bring this piece to a close, the new gadget has been finding uses and I don’t plan on leaving it idle after paying over £150 for it. Apart from acting as an expensive calculator, it has already travelled abroad with me with roaming not being a problem; I may have failed to get it to work with hotel broadband but there was EDGE availability to keep things connected together. All in all, the device is earning its keep and teaching me a few things about mobile handheld computing with my main website in process of being made more mobile compatible with the front page and the photo gallery gaining versions for handheld devices after the same was done for the outdoors blog earlier this year (might make the design look more like the rest of the site though). Without something on which to do some real testing, that idea may not have become reality like it is. It may be no desktop substitute but that’s never to say that these devices may never get near that situation. After all, there was a time when no one could imagine the same for laptop PC’s and we all know what has happened with them.

A late “advance” sighting?

Somewhat infuriatingly, Google released its own browser, Chrome, into the wild near the end of last year but only for Windows. My experiences with it on that platform are that it works smoothly, albeit without many of the bells and whistles that can be got for Firefox. While an unofficial partial port was achieved using Crossover Chromium and there is the Chromium project with all its warnings and the possibility to add a repository for its wares to Ubuntu’s software sources, we have been tantalised rather than served so far. However, that was recently bettered by the release of early access versions. In reality, these can be said to be alpha versions so not everything works but it’s still Chrome and without the need for Windows or WINE. The rendering engine most importantly seems to be the equal of what you get on Windows while ancillary functions like bookmark handling seem incomplete. In summary, the currently available deb packages are a work in progress but that’s better than not having having anything at all.

Opera and table display

I have encountered something very strange with my hillwalking blog and I have to admit that am at something of a loss as to how to resolve it. Opera (version 9.x), it seems, is not displaying the date corresponding to the first post of a particular month. You can see the effect on the right for the current month and, yes, the tenth of the month has a post associated with it. What compounds the mystery is that the same issue doesn’t affect this blog, so some further investigation is very much in order. However, the cascading element of CSS doesn’t help much when trying to track down the cause of this sort of thing. While, it’s irritating, I don’t have any definite answers yet and so would appreciate some suggestions. In the meantime, I’ll be staying on the lookout for a fix. Curiously, all’s fine on Firefox and IE.