Free font styles software for linux

Font Mate application helps you to see how fonts look on your computer, and it also helps you find symbol characters.

Using Font Mate

There isnt much to it: Font Mate shows you a list of all the fonts installed on your computer. Choose any font from the list and it will show you what all the characters in that font look like. Choose any one of those characters and you will see an enlarged version of it at the bottom of the page (with its ASCII code in decimal and hex, should you be interested). Click the button to copy that character to the clipboard if you want to use it in another application.

Works on...

We wrote Font Mate originally for Mac OS X, but we have included versions for Windows and Linux too. We wrote it using REALbasic, a great tool for cross-platform rapid development. Source is available on request.

How much?

Font Mate is freeware. Download, use, share as you wish. No warranty is offered, and we accept no liability for anything strange or nasty that it might do to your computer.

And another thing

If you like Font Mate, why not have a look at our main site at tellura.co.uk and check out our other products and services?

Gnome Font Sampler lets you browse your installed fonts using whatever color, size, attributes (Bold/Italics/Underline), and example text you like.
Main features:
- Quickly compare your fonts
- Select font size, text color, background color, bold, italics, underline, and example text used
- Preview fonts before adding them to the list
- Pretty good keyboard control
- It costs $0 and is Free software
Enhancements:
- New application icon.
- Improved keyboard control (navigate font lists and choose fonts using just the keyboard).

Fontlinge project is a font management and organisation for TrueType & PostScript.
Fontlinge searches for font files, sorts them into folders by name and look and with human readable names, stores gathered font information in a database, generates previews and posters, finds and removes duplicates, and reunites PostScript font families.
Also, Fontlinge has a Web interface to browse through your fonts. It shows detail previews and font info, provides font download as a tarball, and has the possibility to sort fonts.
Main features:
- find your fonts
- rename files, i.e. from AGARBI.TTF to Adobe_Garamond_Bold_Italic.ttf
- create a folder-structure
- move the files to the right place
- find and removes duplicate files
- reunion postscript fontfiles
- create previews

FONTpage is a Python font viewing and image-generating utility. It displays system fonts and allows you to change the font size and color, background color, font face, bold, and italics.
It also has the ability to input the text to be displayed, which you can choose to save as a PNG file. It is handy to view fonts and styles quickly, or to make "logo" graphics.
It was written to supersede wxFontView, as the pyGTK toolkit is much lighter and more widely used.
Enhancements:
- New "Display Font" feature opens popup window with complete alphabet (upper and lower case) and 0-9.
- Window shows current font with current size -- use multiple windows to compare different fonts.
- Font size now scales up to 256 pts (was 128)
- Config file will now track last window dimensions when the application is restarted.
- If user font directory directory (~/.fonts) does not exist, FONTpage will create one. This is to facilitate installing and deleting fonts, which FONTpage will only do on a per-user basis. (This is to avoid problems.)

Font Manager is a font manager for GNOME. Font Manager cannot do any font management tasks yet, but is already useful for picking fonts.
Main features:
- List installed fonts
- Add previews for installed fonts
- Open font properties from context menu
- Set system fonts from the font manager
- Make the font manager installable

x-fontperf is a small utility to measure font rendering/loading time in an x11 environment. Originally intended to see if there is any notable performance difference between a separate font server and local font rendering.
It actually does three different tests:
1) Loading the same font several times
Gives you an average loading time for this particular font. If you use a font already in use in your x-session this should be really quick as this font will be reused and not actually loaded again (cached)
2) Loading the same font in different sizes (incrementing)
Default is from 6 to 144 pixel. Interesting to see how rendering time increases with font size (see option -v)
3) Loading all available fonts
This should give you a good estimate on average fontloading time. Also a good test to stress your system and check if all fonts are loadable (see option -e)
Sample output:
x-fontperf -v
x-fontperf: Copyright (c) Holger Pfaff - http://pfaff.ws
x-fontperf: version 1.1 from 26-Mar-2004
x-fontperf: connected to server: :0.0
x-fontperf: server vendor: Gentoo Linux (XFree86 4.3.0, revision r3)
x-fontperf: vendor release: 40300000
x-fontperf: total of 6406 fonts found
x-fontperf: basefont: -*-helvetica-*-*-*-*-12-*-*-*-*-*-iso8859-1
x-fontperf: loading basefont 100 times ... 6292 usec 62 usec/font
x-fontperf: loading font from pixel size 6 to 144 ... 2977820 usec 21578 usec/font
x-fontperf: loading all 6406 available fonts ... 34965472 usec 5458 usec/font
Usage:
Usage: x-fontperf ...
-display X-display to use
-v Increase verbosity (may falsify results)
-e Show errors during tests
-n Number of iterations for test 1 [100]
-min Minimum pixel size for test 2 [6]
-max Maximum pixel size for test 2 [144]
-foundry Foundry of font [*]
-family Family of font [helvetica]
-weight Weight of font [*]
-slant Slant of font [*]
-setwidth Set width of font [*]
-addstyle Additional style of font [*]
-pixelsize Pixel size of font [12]
-pointsize Point size of font [*]
-resolutionX X resolution of font [*]
-resolutionY Y resolution of font [*]
-spacing Spacing of font [*]
-avgwidth Average width of font [*]
-registry Registry of font [iso8859]
-encoding Encoding of font [1]
Verbosity can be increased in three steps by specifying -v several times. No-
tation -vvv is not supported. Use -v -v -v. Errors opening fonts are not shown
by default. Use -e to see them.
-n specifies the number of iterations for test 1. The default of 100 (shown in
brackets) should be ok for most systems. Increase/decrease values for fast/slow
systems
-min/-max specifies the minimum/maximum pixel size for test 2. Pixel sizes are
incremented by one.
The last block of arguments is for specifying the basefont to use for tests 1
and 2. These follow the standard x11 font naming scheme. Again: defaults are
shown in brackets.
Enhancements:
- first public version 1.0

Choosefont is a simple but extremely efficient tool for quickly finding the required font in a large amount of fonts.

It was created due to the lack of decent font selection widgets in many application.

Apart from finding a font, Choosfont can also creat css, html and other code for the selected font, this code is automatically copied to the X clipboard.

OpenOffice::OODoc::Styles is a Perl module for document styles and layout processing.

This class is designed to handle styles, whether automatic or named, contained in styles.xml or content.xml. It inherits from the common OpenOffice::OODoc::XPath class and brings style-focused features.

This class should not be explicitly used in an ordinary application, because all its features are available in the OpenOffice::OODoc::Document class, in combination with other features. Practically, the present manual is provided to describe the style processing features of OpenOffice::OODoc::Document (knowing that these features are technically supported by the OpenOffice::OODoc::Styles component of the API).

Remember that named styles are those that the end user can see and edit using the Stylist tool in OpenOffice.org. Such styles usually have meaningful names and are stored in the styles.xml member. But an OpenDocument-compliant style may own two names, so-called name and display-name. The display-name is the name as its displayed by the office software, while the name is the main identifier. Both are displayable character strings, but they often differ. For a given display-name, the application software is allowed to set any arbitrary name. For example, with OpenOffice.org 2, the well-known pre-defined style whose display name is "Text body" is named "Text_20_body" (the space character is replaced by its hexadecimal value between two "_" characters). In the other hand, the name and the display-name generally dont differ when they contain letters and/or digits only. Remember that the name (and not the display-name) is the main identifier of a style element. So, such a method as getStyleElement("style name") uses the name attribute to retrieve a style descriptor (unless you change this behaviour through the retrieve_by document property).

Care should be taken particularly with predefined base styles in OpenOffice.org. These styles are described in styles.xml just like named styles, but they appear to the end user with localised names (in their local language), so the really displayed style name is neither the name nor the display-name stored attributes. For example, in the French distribution of OpenOffice.org, the "Text body" style appears as "Corps de texte", while its "display-name" is "Text body" and its "name" is "Text_20_body". However, this is not a problem for user-defined styles as the stored display-name is exactly the same as the effective display name.

There are also numerous "automatic" styles in a document which are created implicitly by the office application each time a particular set of presentation attributes is given to an element, but where no named style is referenced. Automatic styles which apply to the document body are stored in content.xml (but in an XML element isolated from the content). An automatic styles name can change randomly each time the document is edited or saved in OpenOffice.org.

Applications which access automatic styles will not want to indicate them using "hard-coded" names. The best way is to retrieve each automatic style via an object that is known to use it. Using a "hard-coded" name is all right for styles created by a program (the createStyle() method requires it), but such a name should only be considered to be stable for the duration of the session. If you want a program-created style name to be then respected by OpenOffice.org, you must create it as a named style.

This is no more complicated, but it is better to avoid making hundreds of styles visible to the user that they do not need to see.
There are some structural differences between the old OpenOffice.org 1.0 format and the new OASIS Open Document (ODF) one. A few of these differences arent made fully transparent by OpenOffice::OODoc. So, in some cases, a program including style definitions or updates doesnt produce exactly the same results with both OOo 1 and OOo 2 documents.

Some styles are more complex than others as they describe the page layout. These styles can themselves contain text and images. A page style, or a "master page", can actually define a header, a footer, margins, and a background. Headers and footers can contain text and images which can otherwise be handled by OODoc::Text and OODoc::Image. A background contains a colour and can also include a background image (several methods are possible).
Presentation of these objects is itself controlled by styles.

All of this leads to the conclusion that it is not enough just to associate each content element with a style. In reality, document styles form a rather complex network of interdependencies.
As for page styles, the OpenOffice.org format contains a concept which must be understood in order to use some of the following methods. By virtue of the principle of separation of content and presentation, the definition of a page style is based on two distinct objects: "master page" and "page layout". A "master page" object encompasses any page style content (i.e. the content of headers and footers) and links to a "page layout" object which describes page presentation characteristics (with large numbers of parameters from page dimensions to background colour to footnote separator size, etc.). Names which appear in the list of page styles in OpenOffice.org are actually names of "master pages". However, to work with physical aspects of the presentation, you have to access the associated "page layout".

To complicate matters, there are also header and footer styles. Each object contained in a header or footer (e.g. paragraph or image) has a style. The number and range of styles are much larger that you would imagine just looking at the Stylist tool in OpenOffice.org. Up to a point, OODoc::Styles methods make life easier for you by masking some of this complexity.
In OODoc::Styles methods, styles are normally indicated by their logical names (which must be unique), but, except where otherwise stated, they can also be indicated by their style element reference. Moreover, when a method is expecting a page layout as an argument but the programmer passes it a master page instead (whether by design or by mistake), it "knows" in most cases how to automatically select the associated page layout.

Defining a style requires a great many attributes. Some appear in code examples in this manual, but for a full list of possible attributes for each style, you must refer to the OpenOffice.org specification or publications derived from it.

OODoc::Styles module is designed to allow applications to manipulate any style and even create new ones. It is not recommended, however, to use it to create a presentation entirely from code. Here again, it is better to start from document templates which already contain at least a blank of each required style.