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
Created attachment 50 [details] [review]
add detection of graphite enabled fonts
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.
>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.
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.
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:
Script names for OpenType layout (GSUB, GPOS, JSTF I think are
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,
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?
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)
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
Thanks for the update; please post a patch when you're ready. Would you like
this bug assigned to you then?
> names of scripts supported by the OpenType tables in the font
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.
jshin: so you are wanting a list of all the OT features as well?
or to check for specific ones?
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.
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.
> 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?
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
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?
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).
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
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
Created attachment 1472 [details]
IPA test file with stacked diacritics
test file that should look like http://www.crosswire.org/~dglassey/diacrit2.png
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.
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