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. 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 freetype2. 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 well. Regards, Daniel
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: 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 font. So, really, what I'd like for: Sans:fontcaps=otlayout:arab,ttable:Silf 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 machinery. 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.
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 stuff
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 > (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.
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.
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 GSUB:hang:<default>:ljmo 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).
Thanks :) If you have a graphite enabled font e.g Doulos SIL http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=DoulosSILfont 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 https://sourceforge.net/cvs/?group_id=66144 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 otherwise. 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 in gedit
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
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.