Bug 105 - adding detection of graphite enabled fonts to fontconfig
Summary: adding detection of graphite enabled fonts to fontconfig
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.2
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: Keith Packard
QA Contact:
URL: http://graphite.sil.org
Depends on:
Reported: 2003-08-15 01:36 UTC by Daniel Glassey
Modified: 2004-12-03 22:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

add detection of graphite enabled fonts (2.75 KB, patch)
2003-08-15 01:37 UTC, Daniel Glassey
Details | Splinter Review
detect OT layout scripts and silgraphite fonts (7.31 KB, patch)
2003-11-19 08:02 UTC, Daniel Glassey
Details | Splinter Review
use capability instead of fontcap (7.33 KB, patch)
2004-02-28 08:53 UTC, Daniel Glassey
Details | Splinter Review
IPA test file with stacked diacritics (272 bytes, text/plain)
2004-12-04 15:23 UTC, Daniel Glassey
allow capability matching (762 bytes, patch)
2004-12-04 17:09 UTC, Daniel Glassey
Details | Splinter Review

Description Daniel Glassey 2003-08-15 01:36:48 UTC
Will attach a patch in a mo which allows fontconfig to detect whether or not a 
font has a 'Silf' TrueType table in it which indicates that it can be used by 

SILGraphite is a rendering engine that has the complex layout information in the 
 font rather than the layout engine so it doesn't have to be implemented in 
every layout engine, particularly useful for minority language fonts and others 
that use the unicode PUA.

It has been tested on freetype 2.1.4 but it should work on other versions of 

We are developing a module for using SILGraphite with pango and having this in 
fontconfig would really help that.

We are also looking at making a cairo backend so it would help with that as 

Comment 1 Daniel Glassey 2003-08-15 01:37:43 UTC
Created attachment 50 [details] [review]
add detection of graphite enabled fonts
Comment 2 Keith Packard 2003-08-15 09:35:44 UTC
The mozilla folks would like to detect OpenType files as well; should we have
some general mechanism for listing all of the available parts of the TrueType file?

As an aside -- the patch as it stands is rather scary looking with predefined
constants used as pointer offsets; if there isn't a way to do this with standard
FreeType interfaces, we'll have to get the necessary changes into that library
before we can add this capability to fontconfig.
Comment 3 Daniel Glassey 2003-08-15 10:28:11 UTC
>As an aside -- the patch as it stands is rather scary looking with predefined
>constants used as pointer offsets; if there isn't a way to do this with 
>standard FreeType interfaces, we'll have to get the necessary changes into that 
>library before we can add this capability to fontconfig.

There is - freetype 2.1.4 has the FT_Load_Sfnt_Table which I used in the patch 
if that version is detected.
So, if fontconfig is made to depend on freetype 2.1.4 or later, the freetype 
version detection stuff and the alternative table loading code can be removed 
and FT_Load_Sfnt_Table can just be used.
Comment 4 Keith Packard 2003-08-15 10:42:09 UTC
Sorry, I lost the call to the SFNT function when my eyes were caught by the
constants in the pointer arithmetic code.  We can depend on FreeType 2.1.4 for
this feature, so let's lose the scary bits.

I'd also like to figure out how this patch should relate to the desire to detect
fonts that support GSUB/GPOS positioning information as used by Pango.  It would
be nice to solve both of those at the same time without an ever increasing list
of  font attributes.  Perhaps a single 'layout' value with 'graphite, gsub/gpos'
values?  That way you could look for fonts with graphite layout capabilities and
Mozilla could look for fonts with gsub/gpos layout capabilities.
Comment 5 Owen Taylor 2003-08-15 11:58:19 UTC
What I was thinking was somthing like the following - you would
have a set of "font capabilities" identified by string. The two
that seem immediately useful are

 Truetype table names:
  ttable:GPOS ttable:Silf 

Script names for OpenType layout (GSUB, GPOS, JSTF I think are
the ones 

  otlayout:arab otaylor:deva

I think a single feature that was true if the script was found
in *any* of the OpenType tables, is good enough. The main reason
why I want access to the OTL ScriptTag records is to make sure
that the FreeFont problem stays solved: right now it doesn't
have any OpenType tables, so just selecting for fonts that 
have GSUB is good enough, but I'm afraid they'll start adding
in OpenType tables piecemeal for some ranges and not others.

Then the question of matching rule comes into place - since 
Graphite conceptually covers all scripts, we'll have ranges
where Pango can accept either an OpenType font or a Graphite

So, really, what I'd like for:


is that fonts with either otlayout:arab or ttable:Silf sort
above all other fonts, but no ordering is implied between
the two. I'm not sure how that integrates into the matching

Actually, it's possible that Pango doesn't add them to the
pattern at all, but instead once it gets the fonts back,
just ignores the ones without the necessary capabilities. 
After all, this is an all-or-nothing thing, a font without
the right tables is useless.

And actually, there are some advantages in Pango to letting
the shapers decide whether a font is OK rather than providing
the information in advance; the main possible
disadvantage being speed. The sooner we find the right fonts, 
the better.
Comment 6 Daniel Glassey 2003-09-03 14:58:15 UTC
is the proposal then to move the relevant opentype stuff from pango to 
fontconfig and use it to detect the OT layout scriptnames? 
and then use that and the tt table detection code to detect specific tables. 
or are we aiming to detect all tables? 
Comment 7 Owen Taylor 2003-09-03 15:10:03 UTC
The idea is we'd move as much of the OpenType code as necessary - I
think it would be 5% or so. What I'm suggesting is that we start off
with two types of font capabilities:

 names of TrueType tables (tttable:Silf)
 names of scripts supported by the OpenType tables in the font (otlayout:deva)
Comment 8 Daniel Glassey 2003-09-05 07:38:57 UTC
Just to let you know, I've got as far as hopefully detecting the scripts and 
silf table and putting that into fontcaps. I just want to test it before I 
post it here. Most of it is basically derived from the opentype stuff from 
pango so I'm not sure what that means in terms of licensing, attribution and 
Comment 9 Keith Packard 2003-09-05 09:25:36 UTC
Thanks for the update; please post a patch when you're ready.  Would you like
this bug assigned to you then?
Comment 10 Jungshik Shin 2003-09-05 10:08:33 UTC
>  names of scripts supported by the OpenType tables in the font 
> (otlayout:deva)

 Just storing the name of scripts may not be sufficient if more than one
distinct sets of GSUB/GPOS are used for a single script. For instance, Windows
Korean fonts have opentype GSUB features for vertical layout (and some made by
Adobe have GSUB tables for Hanja -> Hangul reading), but none of them has
ljmo,vjmo, tjmo GSUB lookups. With just script names stored, I'd end up matching
fonts only with vertical layout lookup or Hanja->Hangul look when looking for a
font with Jamo lookups.  
Comment 11 Daniel Glassey 2003-09-05 11:29:08 UTC
jshin: so you are wanting a list of all the OT features as well? 
or to check for specific ones? 
like (otfeature:ljmo) 
would this be part of fontcap or would it want to be in a separate fc feature? 
keithp: I don't mind where it is assigned, it'll need checked before it could 
be committed anyway. 
Comment 12 Owen Taylor 2003-09-05 11:45:26 UTC
I don't know if we want to get too fancy here - I don't see any way to
fit the complete:

 Table / Script / Language System / Feature

Hierarchy of OpenType into fontconfig in a nice way. Being able to
match for only fonts that have


Is only going to be necessary if you think that your shaper should ignore
other Korean fonts - which is probably wrong. In general, we should do
the best we can with the font the user has selected.
Comment 13 Jungshik Shin 2003-09-05 18:26:01 UTC
> your shaper should ignore other Korean fonts - which is 
> probably wrong. In general, we should do the best we can with 
> the font the user has selected

   That's generally true. However, overridng the user selection with too rigid a
criterion is different from picking a font based on an incomplete piece of
information. Moreover, not always does a user 'select' a font. Sometimes we have
to prioritize fonts in a particular order and present them  to help  select the
best font. Othertimes, we have to work with an incomplete font spec. (e.g.
'serif', 'sans-serif'). In these and other situations, we may want/need  more
fine-grained information than just a list of scripts.  

  IMHO, we don't have to preserve the complete hierarchy of opentype tables. In
addition to tttables and otlayouts(or otscripts?), putting otfeatures in
'fontcap' should work, shouldn't it?

> jshin: so you are wanting a list of all the OT features as well? 
> or to check for specific ones? 

  I guess the former is necessary during the scanning(by fc-cache) and with it,
the latter just comes, doesn't it? That is, I think a list-type is better than a
boolean type for a specific feature.

In attachment 50 [details] [review], you used FcBool for SilGraphite (perhaps as the first shot).
You're going to generalize it  per Owen's suggestion that a list of Truetype
tables(not all of them but a subset of them that are important in determining
'fontcap') be stored, aren't you? 

Comment 14 Daniel Glassey 2003-11-19 08:02:39 UTC
Created attachment 77 [details] [review]
detect OT layout scripts and silgraphite fonts

changed patch from what I mistakenly sent to list to use the right include
syntax for freetype
Comment 15 Daniel Glassey 2004-02-28 08:53:51 UTC
Created attachment 109 [details] [review]
use capability instead of fontcap

fontcap sounds like a kludgy name for it, I prefer the sound of capability

btw does anyone have any comments about the patch? How does it look?
Comment 16 Keith Packard 2004-12-04 14:02:17 UTC
I've applied the patch to CVS, but I can't really test to make sure it works
(other than to note that some fonts have OT capabilities).
Comment 17 Daniel Glassey 2004-12-04 15:21:38 UTC
Thanks :)
If you have a graphite enabled font e.g Doulos SIL
you can find that it is graphite enabled.

To test this out:
there is a patch to pango in http://bugzilla.gnome.org/show_bug.cgi?id=135697
that allows you to select a script engine to use by preference if the font can
use it otherwise it will use the script specific engine. install it.

If you get silgraphite from cvs 

install it

in the directory contrib/pangomod there is a pango module. Further instructions
are in the README there.

I'm about to attach a file that shows a good example of its use with the Doulos
SIL font and stacking diacritics and tie bars that are just wrong with pango

ss of how it should look at http://www.crosswire.org/~dglassey/diacrit2.png
Comment 18 Daniel Glassey 2004-12-04 15:23:22 UTC
Created attachment 1472 [details]
IPA test file with stacked diacritics

test file that should look like http://www.crosswire.org/~dglassey/diacrit2.png
in gedit
Comment 19 Keith Packard 2004-12-04 16:22:01 UTC
Please feel free to verify that CVS fontconfig does what's necessary; I didn't
change the functionality in the provided code, but did make a few stylistic
changes.  I'm off to more fontconfig bugs now, hoping to clean out bugzilla for
a 2.3 release sometime before the new year.
Comment 20 Daniel Glassey 2004-12-04 17:09:55 UTC
Created attachment 1473 [details] [review]
allow capability matching

I failed to include matching support for capabilities in the other patch but fc
CVS works successfully with the pango module so it isn't essential but is added
here for completeness

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.