Tag Archive for stylesheet

Changing to web fonts

While you can add Windows fonts to Linux installations, I have found that their display can be flaky to say the least. Linux Mint and Ubuntu display them as sharp as I’d like but I have struggled to get the same sort of results from Arch Linux while I am not so sure about Fedora or openSUSE either.

That has caused me to look at web fonts for my websites with Google Web Fonts doing what I need with both Open Sans and Arimo doing what I need so far. There have been others with which I have dallied, such as Droid Sans, but these are the ones on which I have settled for now. Both are in use on this website now and I added calls for them to the web page headers using the following code (lines are wrapping due to space constraints):

<link href=”http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,400,300,600,700” rel=”stylesheet” type=”text/css“>
<link href=’http://fonts.googleapis.com/css?family=Arimo:400,400italic,700,700italic‘ rel=’stylesheet‘ type=’text/css‘>

With those lines in place, it then is a matter of updating font-family and font declarations in CSS style sheets with “Open Sans” or “Arimo” as needed while keeping alternatives defined in case the Google font service goes down for whatever reason. A look at a development release of the WordPress Twenty Twelve theme caused me to come across Open Sans and I like it for its clean lines and Arimo, which was found by looking through the growing Google Web Fonts catalogue, is not far behind. Looking through that catalogue now causes for me a round of indecision since there is so much choice. For that reason, I think it better to be open to the recommendations of others.

Adding GNOME 3 to Linux Mint 11

On the surface of it, this probably sounds a very strange thing to do: choose Linux Mint because they plan to stick with their current desktop interface for the foreseeable future and then stick a brand new one on there. However, that’s what last weekend’s dalliance with Fedora 15 caused. Not only did I find that I could find my way around GNOME Shell but I actually got to liking it so much that I missed it on returning to using my Linux Mint machine again.

The result was that I started to look on the web to see if there was anyone else like me who had got the same brainwave. In fact, it was Mint’s being based on Ubuntu that allowed me to get GNOME 3 on there. The task could be summarised as involving three main stages: getting GNOME 3 installed, adding extensions and adding the Cantarell font that is used by default. After these steps, I gained a well-running GNOME 3 desktop running on Linux Mint and it looks set to stay that way unless something untoward has yet to emerge.

Installing GNOME 3

The first step is to add the PPA repository for GNOME 3 using the following command:

sudo add-apt-repository ppa:gnome3-team/gnome3

The, it was a case of issuing my usual update/upgrade command:

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

When that had done its thing and downloaded and installed quite a few upgrades along the way, it was time to add GNOME Shell using this command:

sudo apt-get install gnome-shell

When that was done, I rebooted my system to be greeted by a login screen very reminiscent of what I had seen in Fedora.While compiling this piece, I have seen that GNOME Session could need to be added before GNOME Shell but I do not recall doing so myself. Maybe dependency resolution kept any problems at bay but there weren’t any issues that I could remember beyond things not being configured as fully as I would have liked without further work. For sake of safety, it might be a good idea to run the following before adding GNOME Shell to your PC.

sudo apt-get install gnome-session && sudo apt-get dist-upgrade

Configuration and Customisation

Once I had logged in, the desktop that I saw wasn’t at all unlike the Fedora one and everything seemed stable too. However, there was still work to do before I was truly at home with it. One thing that was needed was the ever useful GNOME Tweak Tool. This came in very handy for changing the theme that was on display to the standard Adwaita one that caught my eye while I was using Fedora 15. Adding buttons to application title bars for minimising and maximising their windows was another job that the tool allowed me to do. The command to get this goodness added in the first place is this:

sudo apt-get install gnome-tweak-tool

The next thing that I wanted to do was go adding some extensions so I added a repository from which to do this using the command below. Downloading them via Git and compiling them just wasn’t working for me so I needed another approach.

sudo add-apt-repository ppa:ricotz/testing

With that is place, I issued the below commands to gain the Dock, the Alternative Status Menu and the Windows Navigator. The second of these would have added a shutdown option in the me-menu but it seems to have got deactivated after a system update. Holding down the ALT key to change the Suspend entry to Power off… will have to do me for now. Having the dock is the most important and that thankfully is staying the course and works exactly as it does for Fedora.

sudo apt-get install gnome-shell-extensions-dock
sudo apt-get install gnome-shell-extensions-alternative-status-menu
sudo apt-get install gnome-shell-extensions-windows-navigator

Adding Cantarell

The default font used by GNOME 3 in various parts of its interface is Cantarell and it was defaulting to that standard sans-serif font on my system because this wasn’t in place. That font didn’t look too well so I set to tracking the freely available Cantarell down on the web.  When that search brought me to Font Squirrel, I downloaded the zip file containing the required TTF files. The next step was to install them and, towards that end, I added Fontmatrix using this command:

sudo apt-get install fontmatrix

That gave me a tool with a nice user interface but I made a mistake when using it. This was because I (wrongly) thought that it would copy files from the folder that I told the import function to use. Extracting the TTF files to /tmp meant that would have had to happen but Fontmatrix just registered them instead. A reboot confirmed that they hadn’t been copied or moved at all and I had rendered the user interface next to unusable through my own folly; the default action in Ubuntu and Linux Mint is that files are deleted from /tmp on shutdown. The font selection capabilities of the GNOME Tweak Tool came in very handy for helping me converting useless boxes into letters that I could read. Another step was to change the font line near the top of the GNOME Shell stylesheet (never thought that CSS usage would end up in places like this…) so that Cantarell wasn’t being sought and text in sans-serif font replaced grey and white boxes. The stylesheet needs to be edited as superuser so the following command is what’s needed for this and, while I used sudo, gksu is just as useful here if it isn’t what I should have been using.

sudo gedit /usr/share/gnome-shell/theme/gnome-shell.css

Once I had extricated my system from that mess, a more conventional approach was taken and the command sequence below was what I followed, with extensive use of sudo to get done what I wanted. A new directory was created and the TTF files copied in there.

cd /usr/share/fonts/truetype
sudo mkdir ttf-cantarell
cd ttf-cantarell
sudo mv /tmp/*.ttf .

To refresh the font cache, I resorted to the command described in a tutorial in the Ubuntu Wiki:

sudo fc-cache -f -v

Once that was done, it was then time to restore the reference to Canterell in the GNOME Shell stylesheet and reinstate its usage in application windows using the GNOME Tweak Tool. Since then, I have suffered no mishap or system issue with GNOME 3. Everything seems to be working quietly and I am happy to see that replacement of Unity with the GNOME Shell will become an easier task in Ubuntu 11.10, the first alpha release of which is out at the time of my writing these words. Could it lure me back from my modified instance of Linux Mint yet? While I cannot say that I am sure of those but it certainly cannot be ruled out at this stage.

Tinkering with Textpattern

Textpattern 5 may be on the way but that isn’t to say that work on the 4.x branch is completely stopped though it is less of a priority at the moment. After all, version 4.40 was slipped out not so long ago as a security release, a discovery that I made while giving a section of my outdoors website a spring refresh. During that activity, the TinyMCE plugin started to grate with its issuing of error messages in the form of dialogue boxes needing user input to get rid of them every time an article was opened or saved. Because of that nuisance, the guilty hak_tinymce plugin was ejected with joh_admin_ckeditor replacing it and bringing CKEditor into use for editing my Textpattern articles. It is working well though the narrow editing area is causing the editor toolbars to take up too much vertical space but you can resize the editor to solve this though it would be better if it could be made to remember those size settings.

Another find was atb_editarea, a plugin that colour codes (X)HTML, PHP and CSS by augmenting the standard text editing for pages and stylesheets in the Presentation part of the administration interface. If I had this at the start of my redesign, it would have made doing the needful that bit more user-friendly than the basic editing facilities that Textpattern offers by default. Of course, the tinkering never stops so there’s no such thing as finding something too late in the day for it to be useful.

Textpattern may not be getting the attention that some of its competitors are getting but it isn’t being neglected either; its users and developer community see to that. Saying that, it needs to get better at announcing new versions of the CMS so they don’t slip by the likes of me who isn’t looking all the time. With a major change of version number involved, curiosity is aroused as what is coming next. So far, Textpattern appears to be taking an evolutionary course and there’s a lot to be said for such an approach.

Easier to print?

One matter that really came to light was how well or not the pages on here and on my hill walking and photography website came out on the printed page. After spotting a WordPress Codex article and with an eye on making things better, I have made a distinction between screen and print stylesheets. The code in the XHTML looks like this:

<link rel=”stylesheet” href=”/style.css” type=”text/css” media=”screen” />
<link rel=”stylesheet” href=”/style_print.css” type=”text/css” media=”print” />

The media attribute seems to be respected by the browsers that I have been using for testing (latest versions of Firefox, MSIE and Opera) so it then was a matter of using CSS to control what was shown and how it was displayed. Extraneous items like sidebars were excluded from the printed page in favour of the real content that visitors would be wanting anyway and everything else was made as monochrome as possible with images being the only things to escape. After all, people don’t want to be wasting paper and ink in this cash strained times and there’s no need to have any more colour than necessary either. Then, there’s the distraction caused by non-functioning hyperlinks that has inspired the sharing of some wisdom on A List Apart. Returning to my implementation, please let me know in the comments what you think of what I have done on here and if there remains any room for improvement.

position: static?

CSS positioning seems to be becoming a nightmare when it comes to IE6 support. While I am aware that the likes of 37signals have stopped making their products work with it, there remain a lot of people who stick or are stuck with the old retainer. I am one of the latter because of the continued use of Windows 2000 at my place of work, though a Windows Vista roll-out has been mooted for a while now. If nothing else, it keeps me in the loop for any inconsistencies that afflict the display of my websites. Positioning of an element within the browser window rather than within its parent element is one of these and it looks as if specifying a position of relative in a stylesheet is part of this. Apparently, it could be down to its non-triggering of IE’s haslayout property. It might be a hack but I have found that static positioning has helped. I’ll continue to keep my eye out for a better solution if it exists but the static option seems to have no detrimental effect in IE7, IE8, Firefox, Safari, Chrome or Opera.

  • As is commonly the case with places like these, all the views that you find expressed on here in postings and articles are mine alone and not those of any organisation with which I have any association, through work or otherwise. With regards to any comments left on the site, I reserve the right to reject any that are inappropriate. Otherwise, whatever is said is the sole responsibility of whoever is leaving the comment.