Hi, Simple question: How do I install a font such as Frutiger so that styles like "black", "ultra black", and "Extra Black Condensed" actually do something? Another example would be installing Eurostile such that "Extended #2", "Extended #2 Bold" etc. work. Although it is a simple question I would guess that I''ve put somewhere in the region of 60 hours of work into finding or working out an answer over the space of several years. I did have a solution in the days before the binary font cache: I put the font files into the normal place, ran fc-cache and then ran a Perl script over the resulting font.cache-1 files which systematically fixed all the errors in them which prevented the example fonts above and several dozen others working properly. With the advent of the binary cache - apparently with no documented format - this is no longer possible, and was never desirable anyway. Having just moved to a new machine I thought I''d give it another try instead of simply running the old versions from before the disasterous change to the cache file but after another whole day wasted I give up. What is the solution? How do I install a normal, industry-standard font on Linux so that it just works without having to edit xml, Perl, or C code? Gentoo amd64 Freetype 2.3.2 Fontconfig 2.4.2 Thomas Worthington
On Sat, 2007-04-07 at 00:58 +0100, Thomas Worthington wrote:> Hi, > Simple question: > > How do I install a font such as Frutiger so that styles like "black", > "ultra black", and "Extra Black Condensed" actually do something? Another > example would be installing Eurostile such that "Extended #2", "Extended > #2 Bold" etc. work.An example of what fontconfig is generating and what you would like to see would be helpful. While the binary format of the cache file is not documented outside of the source code, the new capabilities of the configuration system are reasonably well disclosed and include the ability to manipulate the contents of the cache file as the fonts are scanned. I find the Frutiger fonts, in particular, to be quite badly named as they are delivered. Frutiger LT 65 Bold is marked as belonging to the Frutiger LT 45 Light family (as a Bold weight). Frutiger LT 55 Roman is marked as belonging to the Frutiger LT 55 Roman family (as a Book weight). These are the only two weights I have at present; I''d like to know what weights the other variants are marked with. However, I understand their predicament -- much software provides access to only two weights (Roman and Bold), so they''ve taken this very sophisticated family and crammed it into this UI.> Although it is a simple question I would guess that I''ve put somewhere in > the region of 60 hours of work into finding or working out an answer over > the space of several years. I did have a solution in the days before the > binary font cache: I put the font files into the normal place, ran > fc-cache and then ran a Perl script over the resulting font.cache-1 files > which systematically fixed all the errors in them which prevented the > example fonts above and several dozen others working properly. With the > advent of the binary cache - apparently with no documented format - this > is no longer possible, and was never desirable anyway.You can edit the results automatically using match/edit rules that operate while the fonts are being scanned. Take a look at the 80-delicious.conf file for an example of fixing up incorrectly reported fonts. If you have a generally useful suggestion on fixing Frutiger, we could include that with an upcoming fontconfig release. Are you actually finding it difficult to access these fonts in applications by name? Or are you just hoping to make the names more natural? -- keith.packard@intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070406/cbe326c7/attachment.pgp
Le samedi 07 avril 2007 ? 00:58 +0100, Thomas Worthington a ?crit :> How do I install a font such as Frutiger so that styles like "black", > "ultra black", and "Extra Black Condensed" actually do something? Another > example would be installing Eurostile such that "Extended #2", "Extended > #2 Bold" etc. work.A lot of this breakage is not at fontconfig but app level. Many apps only recognize the four legacy variants (normal, italic, bold, bold italic). Or if they are intended to recognize more, have a bug somewhere where a coder assumed these four. It would really be more productive if you pinged the authors of broken apps instead of faking things at the fontconfig level. Or you''ll be burned in a few years when the binary font cache is replaced by something else. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070407/8220fbcd/attachment.pgp
Le mardi 10 avril 2007 ? 17:34 +0100, Thomas Worthington a ?crit :> On Sat, 07 Apr 2007 09:56:16 +0100, Nicolas Mailhot > <nicolas.mailhot@laposte.net> wrote: > > > Le samedi 07 avril 2007 ? 00:58 +0100, Thomas Worthington a ?crit : > > > >> How do I install a font such as Frutiger so that styles like "black", > >> "ultra black", and "Extra Black Condensed" actually do something? > >> Another > >> example would be installing Eurostile such that "Extended #2", "Extended > >> #2 Bold" etc. work. > > > > A lot of this breakage is not at fontconfig but app level. Many apps > > only recognize the four legacy variants (normal, italic, bold, bold > > italic). Or if they are intended to recognize more, have a bug somewhere > > where a coder assumed these four. > > Well, do you have an example of an app which works so that I can test > this? Inkscape, Gimp, and Opera, all show the problem. Scribus does not, > but I''m under the impression that it does its own font search at startup > without recourse to fontconfig.ask on #dejavu, the folks there are pretty knowledgeable about the apps that fail to digest their fonts> > It would really be more productive if you pinged the authors of broken > > apps instead of faking things at the fontconfig level. > > Tried that. > > > Or you''ll be > > burned in a few years when the binary font cache is replaced by > > something else. > > That is why I would rather the system worked instead of haveing to hack > around it.The system can only made working at the app level. That''s where the bugs are. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070410/aed63c33/attachment.pgp
On Tue, 10 Apr 2007 17:43:40 +0100, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:> > ask on #dejavu, the folks there are pretty knowledgeable about the apps > that fail to digest their fonts >So, you don''t personally know of any apps which work correctly on common fonts such as Eurostile, Helvetica, and Frutiger? Is that right? Thomas
Le mardi 10 avril 2007 ? 17:50 +0100, Thomas Worthington a ?crit :> On Tue, 10 Apr 2007 17:43:40 +0100, Nicolas Mailhot > <nicolas.mailhot@laposte.net> wrote: > > > > ask on #dejavu, the folks there are pretty knowledgeable about the apps > > that fail to digest their fonts > > > > So, you don''t personally know of any apps which work correctly on common > fonts such as Eurostile, Helvetica, and Frutiger? Is that right?I''m not interested enough in this problem to remember which apps work and which do not. I''m interested enough to have tried to understand why it happens, and remembered the answer, but that''s about it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070410/ff175304/attachment.pgp
On Sat, 07 Apr 2007 02:56:14 +0100, Keith Packard <keithp@keithp.com> wrote:> On Sat, 2007-04-07 at 00:58 +0100, Thomas Worthington wrote: >> Hi, >> Simple question: >> >> How do I install a font such as Frutiger so that styles like "black", >> "ultra black", and "Extra Black Condensed" actually do something? >> Another >> example would be installing Eurostile such that "Extended #2", "Extended >> #2 Bold" etc. work. > > An example of what fontconfig is generating and what you would like to > see would be helpful.Eurostile appears to be the biggest problem. There is Eurostile and Eurostile Extended. From fc-list|sort I get: Eurostile:style=Bold Eurostile:style=Bold Condensed Eurostile:style=Bold Extended #2 Eurostile:style=Bold Oblique Eurostile:style=Condensed Eurostile:style=Demi Eurostile:style=Demi Oblique Eurostile:style=Extended #2 Eurostile:style=Medium Eurostile:style=Oblique But from fc-match "Eurostile" I get EUEX____.PFB: "Eurostile" "Extended #2" when I expect EU______.PFB: "Eurostile" likewise, fc-match "Eurostile-12:Demi" also gives the result: EUEX____.PFB: "Eurostile" "Extended #2" Note that "Demi" is listed on fc-list as one of the available styles. I get similar results from Helvetica where fc-match "Helvetica" and fc-match "Helvetica:Bold" give the expected results: hv______.pfb: "Helvetica" "Regular" and hvb_____.pfb: "Helvetica" "Bold" but fc-match "Helvetica:Narrow" gives the Regular style and filename again: hv______.pfb: "Helvetica" "Regular"> I find the Frutiger fonts, in particular, to be quite badly named as > they are delivered. Frutiger LT 65 Bold is marked as belonging to the > Frutiger LT 45 Light family (as a Bold weight). Frutiger LT 55 Roman is > marked as belonging to the Frutiger LT 55 Roman family (as a Book > weight). These are the only two weights I have at present; I''d like to > know what weights the other variants are marked with. > > However, I understand their predicament -- much software provides access > to only two weights (Roman and Bold), so they''ve taken this very > sophisticated family and crammed it into this UI. > >> Although it is a simple question I would guess that I''ve put somewhere >> in >> the region of 60 hours of work into finding or working out an answer >> over >> the space of several years. I did have a solution in the days before the >> binary font cache: I put the font files into the normal place, ran >> fc-cache and then ran a Perl script over the resulting font.cache-1 >> files >> which systematically fixed all the errors in them which prevented the >> example fonts above and several dozen others working properly. With the >> advent of the binary cache - apparently with no documented format - this >> is no longer possible, and was never desirable anyway. > > You can edit the results automatically using match/edit rules that > operate while the fonts are being scanned. Take a look at the > 80-delicious.conf file for an example of fixing up incorrectly reported > fonts. If you have a generally useful suggestion on fixing Frutiger, we > could include that with an upcoming fontconfig release. > > Are you actually finding it difficult to access these fonts in > applications by name? Or are you just hoping to make the names more > natural? >The answer to that is quite complex but it might be easier to simply explain what I used to do with the human-readable cache files. For fonts where fontconfig was giving strange answers I replaced the cache data in such a way that "Helvetica Narrow" appeared as a totally separate font with only the one style ("regular), unrelated in anyway to any other font called "Helvetica"; I did the same for all fonts with styles not in the list italic bold oblique roman regular medium normal As it seemed to be styles not on this list which were most often troublesome. The result was a long, somewhat unorganised list of fonts, to be sure, but far more importantly, I could access any font in any style I had installed in any program I had. The other good thing about this was that I did not have to do anything in particular for any style not on this list; they were all treated the same. If I had a font called "swinging60s" in styles "groovy", "cool," and "hip" it made no difference to me, they would just appear as three separate fonts which I could use without creating any special matching rules. This is an important point on a system with over 100 fonts on it. The idea of using such rules seems far outside the desired functionality for a modern font system. I can cope with one or two special cases, but to ask a designer trying out Inkscape or any othe program to edit XML files, and then to *take those files with them* to every new machine ever afterwards is madness! The installation of a font should ideally consist of putting the font file(s) into a directory called "Fonts" period. The real world and the many arbitary and strange names that exist and will continue to exist surely makes any attempt to use matching rules ultimately futile and unwieldy. Certainly, given the choice of accessing fonts in a crude way and not being able to access them at all without editing XML files, I think the vast majority of designers would take the former, as would I. Thomas Worthington
On Tue, 10 Apr 2007 18:01:08 +0100, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:> Le mardi 10 avril 2007 ? 17:50 +0100, Thomas Worthington a ?crit : >> On Tue, 10 Apr 2007 17:43:40 +0100, Nicolas Mailhot >> <nicolas.mailhot@laposte.net> wrote: >> > >> > ask on #dejavu, the folks there are pretty knowledgeable about the >> apps >> > that fail to digest their fonts >> > >> >> So, you don''t personally know of any apps which work correctly on common >> fonts such as Eurostile, Helvetica, and Frutiger? Is that right? > > I''m not interested enough in this problem to remember which apps work > and which do not.I''m not asking for a list of all applications divided into those which work and which do not; I''m asking for a single example of a program which uses fontconfig and does not stumble over common everyday fonts.> I''m interested enough to have tried to understand why > it happens, and remembered the answer, but that''s about it. >Your answer was to claim that all bugs in font handling are at the app level; when asked for any evidence of that, all you do is shrug your shoulders and say you''re not interested enough to explain yourself. Either you know from using applications that correctly handle fonts that it is not the fault of fontconfig, or you do not know where the problem lies. If it''s the former then why not say? Thomas
Have you had any luck with this, in particular can you duplicate the mismatch between fc-list and fc-match? I have tried several machines and they all reproduce the problem but since I set up all of them that does not necessarily confirm it. TW On Sat, 07 Apr 2007 02:56:14 +0100, Keith Packard <keithp@keithp.com> wrote:> On Sat, 2007-04-07 at 00:58 +0100, Thomas Worthington wrote: >> Hi, >> Simple question: >> >> How do I install a font such as Frutiger so that styles like "black", >> "ultra black", and "Extra Black Condensed" actually do something? >> Another >> example would be installing Eurostile such that "Extended #2", "Extended >> #2 Bold" etc. work. > > An example of what fontconfig is generating and what you would like to > see would be helpful.Eurostile appears to be the biggest problem. There is Eurostile and Eurostile Extended. From fc-list|sort I get: Eurostile:style=Bold Eurostile:style=Bold Condensed Eurostile:style=Bold Extended #2 Eurostile:style=Bold Oblique Eurostile:style=Condensed Eurostile:style=Demi Eurostile:style=Demi Oblique Eurostile:style=Extended #2 Eurostile:style=Medium Eurostile:style=Oblique But from fc-match "Eurostile" I get EUEX____.PFB: "Eurostile" "Extended #2" when I expect EU______.PFB: "Eurostile" likewise, fc-match "Eurostile-12:Demi" also gives the result: EUEX____.PFB: "Eurostile" "Extended #2" Note that "Demi" is listed on fc-list as one of the available styles. I get similar results from Helvetica where fc-match "Helvetica" and fc-match "Helvetica:Bold" give the expected results: hv______.pfb: "Helvetica" "Regular" and hvb_____.pfb: "Helvetica" "Bold" but fc-match "Helvetica:Narrow" gives the Regular style and filename again: hv______.pfb: "Helvetica" "Regular"> I find the Frutiger fonts, in particular, to be quite badly named as > they are delivered. Frutiger LT 65 Bold is marked as belonging to the > Frutiger LT 45 Light family (as a Bold weight). Frutiger LT 55 Roman is > marked as belonging to the Frutiger LT 55 Roman family (as a Book > weight). These are the only two weights I have at present; I''d like to > know what weights the other variants are marked with. > > However, I understand their predicament -- much software provides access > to only two weights (Roman and Bold), so they''ve taken this very > sophisticated family and crammed it into this UI. > >> Although it is a simple question I would guess that I''ve put somewhere >> in >> the region of 60 hours of work into finding or working out an answer >> over >> the space of several years. I did have a solution in the days before the >> binary font cache: I put the font files into the normal place, ran >> fc-cache and then ran a Perl script over the resulting font.cache-1 >> files >> which systematically fixed all the errors in them which prevented the >> example fonts above and several dozen others working properly. With the >> advent of the binary cache - apparently with no documented format - this >> is no longer possible, and was never desirable anyway. > > You can edit the results automatically using match/edit rules that > operate while the fonts are being scanned. Take a look at the > 80-delicious.conf file for an example of fixing up incorrectly reported > fonts. If you have a generally useful suggestion on fixing Frutiger, we > could include that with an upcoming fontconfig release. > > Are you actually finding it difficult to access these fonts in > applications by name? Or are you just hoping to make the names more > natural? >The answer to that is quite complex but it might be easier to simply explain what I used to do with the human-readable cache files. For fonts where fontconfig was giving strange answers I replaced the cache data in such a way that "Helvetica Narrow" appeared as a totally separate font with only the one style ("regular), unrelated in anyway to any other font called "Helvetica"; I did the same for all fonts with styles not in the list italic bold oblique roman regular medium normal As it seemed to be styles not on this list which were most often troublesome. The result was a long, somewhat unorganised list of fonts, to be sure, but far more importantly, I could access any font in any style I had installed in any program I had. The other good thing about this was that I did not have to do anything in particular for any style not on this list; they were all treated the same. If I had a font called "swinging60s" in styles "groovy", "cool," and "hip" it made no difference to me, they would just appear as three separate fonts which I could use without creating any special matching rules. This is an important point on a system with over 100 fonts on it. The idea of using such rules seems far outside the desired functionality for a modern font system. I can cope with one or two special cases, but to ask a designer trying out Inkscape or any othe program to edit XML files, and then to *take those files with them* to every new machine ever afterwards is madness! The installation of a font should ideally consist of putting the font file(s) into a directory called "Fonts" period. The real world and the many arbitary and strange names that exist and will continue to exist surely makes any attempt to use matching rules ultimately futile and unwieldy. Certainly, given the choice of accessing fonts in a crude way and not being able to access them at all without editing XML files, I think the vast majority of designers would take the former, as would I. Thomas Worthington
On Thu, 2007-04-19 at 13:55 +0100, Thomas Worthington wrote:> Eurostile appears to be the biggest problem. There is Eurostile and > Eurostile Extended.Why is it called ''Extended''? That''s an odd style name. My guess would be that it is an expanded variant, can you confirm this? And, is this a TrueType font? If so, it would be very useful to see the output of fc-cache run on this font with FC_DEBUG=256 as that will show us the contents of the OS2 table that is supposed to specify the set width of the font.> but fc-match "Helvetica:Narrow" gives the Regular style and filename again:Try Helvetical:condensed; there is no mapping of the width name ''narrow''. Alternatively, Helvetica:style=Narrow should also work fine.> The result was a long, somewhat unorganised list of fonts, to be sure, but > far more importantly, I could access any font in any style I had installed > in any program I had.If applications would simply list the styles available along with the family names, that would be true today. Unfortunately, many of them have boolean medium/bold and roman/italic buttons which makes the job of fontconfig a lot harder. Take a look at the Gnome or KDE font selector dialogs; they provide a family name and a style name. This can access all of the fonts you use without resorting to merging the family and style names. Applications which retain a simplistic notion of font variation should be fixed, although getting OpenOffice to change will probably take years. The problem is confounded as the style names for fonts include information about slant, width, weight, caps styles and numerous other bits of information. Merging all of this information with the family name would make even existing simplistic applications harder to use as the ''style'' selection in all applications would cease to have any meaning. Without keeping fonts unified by family name, applications like Mozilla cannot take general font specifications and convert them into a range of related glyphs -- fetching the ''condensed variant'' of the ''serif'' font requires that whatever family is used for ''serif'' has the same family name as the condensed version.> The idea of using such rules seems far outside the desired functionality > for a modern font system. I can cope with one or two special cases, but to > ask a designer trying out Inkscape or any othe program to edit XML files, > and then to *take those files with them* to every new machine ever > afterwards is madness!As Inkscape uses the usual Gnome font dialog, it should be able to reach all of the fonts on your system, as long as they have unique family/style combinations. If not, that dialog is just broken and needs to be fixed. I don''t see a simple solution that can work without fixing applications so that they present the full list of style options for each family. -- keith.packard@intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20070419/49772dbd/attachment.pgp
Many foundries (including major ones like Linotype) use "Extended" instead of "Expanded". And note that macStyle (which predates the OS/2) table uses "Extended". ;) --deh!
Qianqian Fang
2007-Jul-15 21:11 UTC
[Fontconfig] strange behavior for font with partial bitmap embedding
hi I am working toward a new CJK font including both the outline data and embedded bitmap glyphs. The embedded bitmaps only cover the CJK characters (Hanzi), at 9,10,11,12pt; while the outline part covers most Latin, Hanzi, Korean, Japanese and other symbols (35206 characters in total). The font does not include hinting instructions for now and only include the medium face (therefore the fake-bolding process is called when needed) I observed a rather strange behavior with this font, which can be summarized below: 1. at size 10pt, if I turn on AA+hinting+subpixel rendering, the Hanzi part are shown correctly, with the embedded bitmaps, however, the Latin characters were displayed without AA. http://bbs.dartmouth.edu/~fangq/blog/upload/aa_hinting_subpix.png 2. if I turn on AA+subpixel from my desktop, the Latin characters were rendered ok, with smooth outlines, but all normal face Hanzi (suppose to be displayed with the embedded bitmaps) become blanks (not the bold face). http://bbs.dartmouth.edu/~fangq/blog/upload/aa_subpix.png this test was done on Xubuntu 7.04, Xfce 4.4.0, fontconfig 2.4.2-1ubuntu1, freetype2 2.2.1-5ubuntu1.1 the locale was under zh_CN(similar for other zh_* locales). Need to mention that the font behaves normal in OpenOffice 2.2: (for autohinting off) http://wenq.org/gallery/albums/userpics/10002/zenhei_prezixiao3_openoffice_en.png (for autohinting on) http://wenq.org/gallery/albums/userpics/10002/zenhei_prezixiao3_openoffice2_en.png The reason for making this partially embedded fonts is because I have seen a strong consensus among the Chinese users that a pleasing rendering requires bitmaps for Hanzi, and AA for Latin or low-density glyphs. I know little about fontconfig, just curious if this behavior is by design or a potential bug of fontconfig. This font is not officially released yet, please let me know if you need a copy to test and debug. any other feedback on this matter is also appreciated. Qianqian
mpsuzuki at hiroshima-u.ac.jp
2007-Aug-01 04:54 UTC
[Fontconfig] strange behavior for font with partial bitmap embedding
Hi, Either I know little about fontconfig, but saying a few can be better than nothing. On Sun, 15 Jul 2007 17:11:43 -0400 Qianqian Fang <fangq at nmr.mgh.harvard.edu> wrote:>I know little about fontconfig, just curious if this behavior >is by design or a potential bug of fontconfig.Although fontconfig can store the information to switch anti-aliasing and subpixel rendering, the rasterization itself is executed out of fontconfig. The fontconfig has no responsibility how to these control switches are used in font rasterization. Just fontconfig replies the defined value for boolean anti-aliasing and RGB ordering for subpixel rendering, per the query for each face. It must be noted that fontconfig can store single value per face, for these control switches. In the other words, fontconfig cannot control these values per glyph. I think, you want the rasterizer to work as following strategy: 1. If the face includes bitmap glyph at requested pixel size, the rasterizer should use it to display the glyph. 2. If the face doesn''t include bitmap glyph at requested pixel size, the rasterizer should make anti-aliased (and subpixel-rendered) image from vector data. But these strategy is out of the control which fontconfig can. I think, the 1st behaviour you mentioned should be checked by Xft (I guess OpenOffice.org uses fontconfig but does not use Xft, so the rendering behaviour is different from most GNOME applications, as you found). Yet I don''t have good idea for the simplest test. The lost of glyph is big impact (and not expected), I''m not sure the 2nd behaviour is the bug /or not. I guess hinting switch on GNOME font panel just changes the autohinting of FreeType2, so the exist of TrueType native bytecode hinting is not critical parameter. Regards, mpsuzuki
Qianqian Fang
2007-Aug-02 02:56 UTC
[Fontconfig] strange behavior for font with partial bitmap embedding
(I cc-ed a copy to freetype2 mailing list of this discussion, my original question was posted at http://lists.freedesktop.org/archives/fontconfig/2007-July/002639.html ) thank you mpsuzuki for explaining this to me. I had a hard time to isolate the problem and it is always confusing for me that the font rendering in Linux is related to multiple modules, freetype2,fontconfig, pango, Xft etc. I send my question to this list in the hope that some font experts may hear my question and direct me to the right direction. Indeed, I had suspected that fontconfig does not manipulate font information down to the glyph level, maybe <blank> is the only exception. However I was curious on the accuracy/legitimacy of the returned font information for this situation where font has partial coverage of bitmaps at specific sizes. In another word, because fontconfig does not have the granularity to describe the details of a font (it perhaps was not designed for this), will the returned incomplete info mislead the rendering engine? For example, when a program want to draw a 10pt ''A'' and request fontconfig to provide a list of fonts and font properties (such as embeddedbitmap), and this partially embedded font happen to be the top of the list. Will fontconfig tell the program that this font has embedded bitmaps if it sees an embedded bitmap at10pt ''A''? or it sees more than one embedded bitmaps at 10pt? or it sees more than one embedded glyph in the whole font? or if it set embeddedbitmap to true based on the percentage of the bitmap coverage? or not telling the program about this at all? A more complex situation is when the program want to draw a bold 10pt ''A'' and ''A'' only has medium face outline data, while ''B''-''z'' has embedded bitmap for 10pt. what would fontconfig do in this situation? anything that can potentially mislead the rendering afterward? again, I am not familiar with either fontconfig and freetype2, just hoping this is something that I can learn, even the rough idea, about the rendering and help me to pinpoint the problem next time. thank you for your further input. Qianqian mpsuzuki at hiroshima-u.ac.jp wrote:> Hi, > > Either I know little about fontconfig, but saying a few > can be better than nothing. > > On Sun, 15 Jul 2007 17:11:43 -0400 > Qianqian Fang <fangq at nmr.mgh.harvard.edu> wrote: > >> I know little about fontconfig, just curious if this behavior >> is by design or a potential bug of fontconfig. >> > > Although fontconfig can store the information to switch > anti-aliasing and subpixel rendering, the rasterization > itself is executed out of fontconfig. The fontconfig has > no responsibility how to these control switches are used > in font rasterization. Just fontconfig replies the defined > value for boolean anti-aliasing and RGB ordering for > subpixel rendering, per the query for each face. > > It must be noted that fontconfig can store single value > per face, for these control switches. In the other words, > fontconfig cannot control these values per glyph. I think, > you want the rasterizer to work as following strategy: > > 1. If the face includes bitmap glyph at requested pixel > size, the rasterizer should use it to display the glyph. > > 2. If the face doesn''t include bitmap glyph at requested > pixel size, the rasterizer should make anti-aliased > (and subpixel-rendered) image from vector data. > > But these strategy is out of the control which fontconfig > can. I think, the 1st behaviour you mentioned should be > checked by Xft (I guess OpenOffice.org uses fontconfig but > does not use Xft, so the rendering behaviour is different > from most GNOME applications, as you found). Yet I don''t > have good idea for the simplest test. > > The lost of glyph is big impact (and not expected), I''m not > sure the 2nd behaviour is the bug /or not. I guess hinting > switch on GNOME font panel just changes the autohinting > of FreeType2, so the exist of TrueType native bytecode hinting > is not critical parameter. > > Regards, > mpsuzuki > > > >