Adventures & experiences in contemporary technology
While I have a previous posting from 2009 that discusses adding Microsoft’s Core Fonts to the then current version of Fedora, it did strike me that I hadn’t laid out the series of command that were used. Instead, I referred to an external and unofficial Fedora FAQ. That’s still there but I also felt that I was leaving things a little to chance given how websites can disappear quite suddenly.
Even after next to four years, it still amazes me that you cannot install Microsoft’s Core Fonts in Fedora as you would in Ubuntu, Linux Mint or even Debian. Therefore, the following series of steps is as necessary now as it was then.
The first step is to add in a number of precursor applications such as wget for command line file downloading from websites, cabextract for extracting the contents of Windows CAB files, rpmbuild for creating RPM installers and utilities for the XFS file system that chkfontpath needs:
sudo yum -y install rpm-build cabextract ttmkfdir wget xfs
Here, I have gone with terminal commands that use sudo but you could become the superuser (root) for all of this and there are those who believe you should. The -y switch tells yum to go ahead with prompting you for permission before it does any installations. The next step is to download the Microsoft fonts package with wget:
sudo wget http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
Once that is done, you need to install the chkfontpath package because the RPM for the fonts cannot be built without it:
sudo rpm -ivh http://dl.atrpms.net/all/chkfontpath
Once that is in place, you are ready to create the RPM file using this command:
sudo rpmbuild -ba msttcorefonts-2.0-1.spec
After the RPM has been created, it is time to install it:
sudo yum install --nogpgcheck ~/rpmbuild/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
When installation has completed, the process is done. Because I used sudo, all of this happened in my own home area so there was a need for some housekeeping afterwards. If you did it by becoming the root user, then the files would be there instead and that’s the scenario in the online FAQ.
Many of us with the opportunity to work from home will have met up with logging via a Citrix server. With that in mind, I set to getting an ICA client going on my main Ubuntu box at home. There is information scattered about the web in the form of question on the Ubuntu forum and a step-by-step guide by Liberian Geek. To summarise the process that I followed here, you have to download a copy of the Citrix Receiver installer for Linux from the company’s website. There, you’ll see DEB and RPM packages along with a tarball for other systems. The latter needs a bit more work so I got the x86 DEB package and installed that in the usual way using Ubuntu’s Software Centre to do the installation following the download. Needing to start the Citrix connection via a browser session meant that a browser restart was needed too. That wasn’t the end of the leg work because Thawte certificate errors were to stop me in my tracks until I downloaded their root certificates from their website. Once the zip file was on my PC, I extracted it and copied the required certificate (Thawte Server CA.cer from the thawte Server CA directory) to /usr/lib/ICAClient/keystore/cacerts on my system; it helped that the error message had told me which was the one I needed from the collection in the zip file. With that matter addressed, the connection happened without a glitch and I was able to get to working without recourse to a Windows virtual machine. For once, Linux wasn’t to be excluded from one of the ways of using computers that has been getting more prevalent these days.
Update 2012-04-14: On an equivalent installation on Linux Mint Debian Edition, I found that the installation location for the certificate had moved to /opt/Citrix/ICAClient/keystore/cacerts. This was for the 64-bit edition.
Update 2012-12-17: The above applied to an installation of version 12.10 on 32-bit Ubuntu GNOME Remix too.
On thing that I recently had to investigate was the possibility of converting CGM vector graphics files into Postscript and from there into PDF. Having used ImageMagick for converting images before, that was an obvious option. However, that cannot process CGM files on its own and needs a delegate or helper application as well. This is the case with raw digital camera files too with UFRaw being the program chosen. For CGM images, the more obscure RALCGM is what’s needed and tracking it down is a bit of an art. The history is that it was developed at the U.K.’s Rutherford Appleton Laboratory but it seems that it was left go off into the wilderness rather than someone keeping an eye on things. With that in mind, here are the installation packages for Windows and Linux (RPM):
RALCGM is a handy command line tool that can covert from CGM to Postscript on its own without any need for ImageMagick at all. From what I have seen, fonts on graphical output may look greyer than black but it otherwise does its job well. However, considering that it is a freely available tool, one cannot complain too much. There are other packages for doing vector to raster conversion and the ones that I have seen do have GUI‘s but the freedom to look at for cost software wasn’t mine to have. The required command looks something like the following:
ralcgm -d PS -oL test.cgm test.ps
The switch -d PS uses the software’s Postscript driver and -oL specifies landscape orientation. If you want to find out more, here’s a PDF rendition of the help file that comes with the thing:
It should have been as straightforward as following the instructions on the openSUSE website but a bug in VMware Tools derailed things on me. The usual procedure would have you starting by selecting Install VMware Tools from the VM menu before popping into the virtual machine to do the rest. Once binutils, gcc, gcc-c++, kernel-source and make are in place, next steps should involve using YaST to install the RPM for you to run the vmware-config-tools.pl script from the terminal.
However, a bug in compat_slab.h puts a stop to any hopes of installing the vmhgfs component. That’s needed if you want to enable the shared folders feature; looking in /mnt/hgfs then would get you to any shared folders Everything else will be there but why miss out on one piece of functionality when it come in useful?
Having found a useful thread on the subject, here’s my way forward: it is as the expected procedure up to the point of installing the RPM. With VMware Tool installation on a Linux guest, you have two options: use RPM as described or use the compressed tarball. The latter seems the better course. Extract the contents into a folder and navigate to that folder. When there go into vmware-tools-distrib/lib/modules/source and extract the file vmhgfs.tar. Proceed into the resulting vmhgfs-only contained wherever you put it and perform the following edit of compat_slab.h:
Change
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
to
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 22) || defined(VMW_KMEMCR_HAS_DTOR)
After that, recreate and replace vmhgfs.tar before issuing the following command in the terminal window while in the vmware-tools-distrib directory: ./vmware-config-tools.pl (anything prefixed with "./" picks up the file from the current working directory rather than where system binaries are stored). A kernel compilation will be involved but all of the defaults should be sensible. Hopefully, all will work well after this.
Update: I am left with a number of outstanding issues that I need to resolve. Lack of internet access from the VM is one of them and a constant forgetfulness regarding the nationality of my keyboard (it’s British) might be another. In the interim, I have removed VMware tools until I can spend some time setting these to rights. Internet access has returned and British keyboard layout is being interpreted correctly in the meantime…