Within an application, how can I enforce fontconfig to return scalable
fonts only? In other words, I want the equivalent to
<fontconfig>
<selectfont>
<rejectfont>
<pattern>
<patelt
name="scalable"><bool>false</bool></patelt>
</pattern>
but without adding that to a local fontconfig config file.
Werner
On 01/16/11 00:47, Werner LEMBERG wrote:> > Within an application, how can I enforce fontconfig to return scalable > fonts only? In other words, I want the equivalent to > > <fontconfig> > <selectfont> > <rejectfont> > <pattern> > <patelt name="scalable"><bool>false</bool></patelt> > </pattern> > > but without adding that to a local fontconfig config file.Humm. I''m out of ideas right now. behdad> Werner
>> Within an application, how can I enforce fontconfig to return >> scalable fonts only? In other words, I want the equivalent to >> >> <fontconfig> >> <selectfont> >> <rejectfont> >> <pattern> >> <patelt name="scalable"><bool>false</bool></patelt> >> </pattern> >> >> but without adding that to a local fontconfig config file. > > Humm. I''m out of ideas right now.For out project (lilypond) it''s quite important to have fontconfig return only scalable fonts. Perhaps it makes sense to add a new function to fontconfig which controls that? I can try to circumvent the issue (this is, using FreeType stuff to test whether a font is scalable), but then it would be necessary that fontconfig returns a list of fonts which exactly fit the search pattern so that I can iterate its elements (or perhaps fontconfig itself provides such an iterator). Is this possible? Werner
On 01/20/11 15:07, Werner LEMBERG wrote:> For out project (lilypond) it''s quite important to have fontconfig > return only scalable fonts. Perhaps it makes sense to add a new > function to fontconfig which controls that?There are some proposals for revamping font matching to allow that.> I can try to circumvent the issue (this is, using FreeType stuff to > test whether a font is scalable), but then it would be necessary that > fontconfig returns a list of fonts which exactly fit the search > pattern so that I can iterate its elements (or perhaps fontconfig > itself provides such an iterator). Is this possible?Check out FcFontSort(). behdad> Werner >
>>>>> "WL" == Werner LEMBERG <wl at gnu.org> writes:WL> For out project (lilypond) it''s quite important to have fontconfig WL> return only scalable fonts. Perhaps it makes sense to add a new WL> function to fontconfig which controls that? You could try having a project-specific top-level fonts.conf. It should have an <include> block which includes the system''s fonts.conf (the location of which should get chosen by ./configure) and which then rejects bitmap fonts. Something like: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <!-- Start with the system conf --> <include ignore_missing="yes">/etc/fonts/fonts.conf</include> <!-- Reject bitmap fonts --> <selectfont> <rejectfont> <pattern> <patelt name="scalable"><bool>false</bool></patelt> </pattern> </rejectfont> </selectfont> </fontconfig> -JimC -- James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
[fontconfig 2.8.0]>> I can try to circumvent the issue (this is, using FreeType stuff to >> test whether a font is scalable), but then it would be necessary >> that fontconfig returns a list of fonts which exactly fit the >> search pattern so that I can iterate its elements (or perhaps >> fontconfig itself provides such an iterator). Is this possible? > > Check out FcFontSort().Thanks. If I interpret this function correctly, the application itself has to decide how `near'' the match is. For example, doing fc-match -s utopia:regular on my GNU/Linux box, the first few elements are UTRG____.pfa: "Utopia" "Regular" UTRG__12-ISO8859-1.pcf.gz: "Utopia" "Regular" UTRG__12.pcf.gz: "Utopia" "Regular" DejaVuSans.ttf: "DejaVu Sans" "Book" DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold" DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique" DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique" LiberationSans-Regular.ttf: "Liberation Sans" "Regular" arial.ttf: "Arial" "Normal" ... so the application must actually test whether the font name is still the one which is actually searched for. It seems that FontConfig doesn''t provide a function which only returns the list of fonts which *exactly* match the pattern. Any reason for this? Or am I missing something? On the other hand, saying fc-match -s -a utopia:regular starts with UTRG____.pfa: "Utopia" "Regular" putr.pfa: "Utopia" "Regular" UTB_____.pfa: "Utopia" "Bold" putb.pfa: "Utopia" "Bold" UTI_____.pfa: "Utopia" "Italic" putri.pfa: "Utopia" "Italic" UTBI____.pfa: "Utopia" "Bold Italic" putbi.pfa: "Utopia" "Bold Italic" UTRG__12-ISO8859-1.pcf.gz: "Utopia" "Regular" UTRG__12.pcf.gz: "Utopia" "Regular" UTB___12-ISO8859-1.pcf.gz: "Utopia" "Bold" UTB___12.pcf.gz: "Utopia" "Bold" ... I wonder how this can be called `sorted''... Why has putb.pfa (having a different font series value) a higher priority than UTRG__12-ISO8859-1.pcf.gz? Werner
On 01/21/11 02:16, Werner LEMBERG wrote:> [fontconfig 2.8.0] > >>> I can try to circumvent the issue (this is, using FreeType stuff to >>> test whether a font is scalable), but then it would be necessary >>> that fontconfig returns a list of fonts which exactly fit the >>> search pattern so that I can iterate its elements (or perhaps >>> fontconfig itself provides such an iterator). Is this possible? >> >> Check out FcFontSort(). > > Thanks. If I interpret this function correctly, the application > itself has to decide how `near'' the match is. For example, doingHi Werner, Welcome to the mess that is fontconfig! :)> fc-match -s utopia:regular > > on my GNU/Linux box, the first few elements are > > UTRG____.pfa: "Utopia" "Regular" > UTRG__12-ISO8859-1.pcf.gz: "Utopia" "Regular" > UTRG__12.pcf.gz: "Utopia" "Regular" > DejaVuSans.ttf: "DejaVu Sans" "Book" > DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold" > DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique" > DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique" > LiberationSans-Regular.ttf: "Liberation Sans" "Regular" > arial.ttf: "Arial" "Normal" > ... > > so the application must actually test whether the font name is still > the one which is actually searched for. > > It seems that FontConfig doesn''t provide a function which only returns > the list of fonts which *exactly* match the pattern. Any reason for > this? Or am I missing something?Well, it''s not that clear cut. For example, you may ask for Times New Roman, and fontconfig will give you Liberation Serif, or Nimbus Roman No9, or Tinos, and they are all real substitutes for Times New Roman.> On the other hand, saying > > fc-match -s -a utopia:regular > > starts with > > UTRG____.pfa: "Utopia" "Regular" > putr.pfa: "Utopia" "Regular" > UTB_____.pfa: "Utopia" "Bold" > putb.pfa: "Utopia" "Bold" > UTI_____.pfa: "Utopia" "Italic" > putri.pfa: "Utopia" "Italic" > UTBI____.pfa: "Utopia" "Bold Italic" > putbi.pfa: "Utopia" "Bold Italic" > UTRG__12-ISO8859-1.pcf.gz: "Utopia" "Regular" > UTRG__12.pcf.gz: "Utopia" "Regular" > UTB___12-ISO8859-1.pcf.gz: "Utopia" "Bold" > UTB___12.pcf.gz: "Utopia" "Bold" > ... > > I wonder how this can be called `sorted''... Why has putb.pfa (having > a different font series value) a higher priority than > UTRG__12-ISO8859-1.pcf.gz?Most probably because UTRG__12-ISO8859-1.pcf.gz has a limited charset, which in the minds of fontconfig is inadequate for your language of choice (en_US?). Checkout fontconfig/src/fcmatch.c:_FcMatchers to see how fontconfig orders fonts. behdad> > Werner >
> Welcome to the mess that is fontconfig! :):-) Honestly, FontConfig seems to work quite nice, but it lacks someone who is taking care of, for example, by improving the documentation or adding features.>> It seems that FontConfig doesn''t provide a function which only returns >> the list of fonts which *exactly* match the pattern. Any reason for >> this? Or am I missing something? > > Well, it''s not that clear cut. For example, you may ask for Times > New Roman, and fontconfig will give you Liberation Serif, or Nimbus > Roman No9, or Tinos, and they are all real substitutes for Times New > Roman.Well, I consider FontConfig as *the* interface to the fonts of an operating system, and there are situations where a substitution is simply the wrong action. I would prefer if there were functions which returned an empty list in case the match isn''t exact, say.>> UTRG____.pfa: "Utopia" "Regular" >> putr.pfa: "Utopia" "Regular" >> UTB_____.pfa: "Utopia" "Bold" >> putb.pfa: "Utopia" "Bold" >> UTI_____.pfa: "Utopia" "Italic" >> putri.pfa: "Utopia" "Italic" >> UTBI____.pfa: "Utopia" "Bold Italic" >> putbi.pfa: "Utopia" "Bold Italic" >> UTRG__12-ISO8859-1.pcf.gz: "Utopia" "Regular" >> UTRG__12.pcf.gz: "Utopia" "Regular" >> UTB___12-ISO8859-1.pcf.gz: "Utopia" "Bold" >> UTB___12.pcf.gz: "Utopia" "Bold" >> ... >> >> I wonder how this can be called `sorted''... Why has putb.pfa >> (having a different font series value) a higher priority than >> UTRG__12-ISO8859-1.pcf.gz? > > Most probably because UTRG__12-ISO8859-1.pcf.gz has a limited > charset, which in the minds of fontconfig is inadequate for your > language of choice (en_US?).Maybe. However, then the documentation is not correct or imcomplete since the result is simply surprising, and this is always a bad sign... Werner