227889 - [xft] font matching does not follow CSS matching algorithm

Status: RESOLVED INCOMPLETE

(Core Graveyard :: GFX: Gtk, defect)

Description

[Brian Ryner (not reading)]

With the following fonts installed on my system (fontconfig fc-list output):

LucidaTypewriter:style=Bold:weight=200
LucidaTypewriter:style=Regular:weight=100
Verdana:style=Bold Italic:weight=200
Verdana:style=Bold:weight=200
Verdana:style=Regular:weight=100
Verdana:style=Italic:weight=100

and these CSS properties:

font-family: LucidaTypewriter, Verdana;
font-style: italic;

the font matching does not follow
http://www.w3.org/TR/CSS21/fonts.html#algorithm . In particular, the matching
algorithm specifies that font-style must match as follows:

'italic' will be satisfied if there is either a face in the UA's font database
labeled with the CSS keyword 'italic' (preferred) or 'oblique'. Otherwise the
values must be matched exactly or font-style will fail.

There is no italic style for LucidaTypewriter, so it should move on to Verdana
and use that.  Instead, it uses non-italic LucidaTypewriter.

Comment 1

[Brian Ryner (not reading)]

Attachment: testcase

Comment 2

[Brian Ryner (not reading)]

Looking at the code, it's probably similarly not possible for a bitmapped font
to be skipped if it's not available at the requested size (which the spec also
says should happen).

Comment 3

[keithp]

The solution worked out for scalable fonts was to synthesize an oblique face
when not available so that the font-style property would always match; this
makes it essentially identical to all of the other properties which are
secondary to the family name in match priority.

So, the only remaining issues are with bitmap fonts.  As bitmap fonts continue
to grow less and less important, I think we should focus on conformance with the
specification, rather than an ideal result.  The UA is allowed discretion in the
matching of bitmap font sizes (so that the current scheme which allows arbitrary
error is conformant, if not ideal).  But, font styles provide no wiggle room to
claim conformance with the current implementation.

It seems to me that the CSS specification requires an application-specified
font-style to be of primary import, more important in fact than the family name
when selecting a font.  If so, I can add a new matching table entry which places
strongly bound slant values above strongly bound family names, while leaving
weakly bound slant values below weakly bound family names.  That, and a bit of
code to make slant comparisons equate italic and oblique should fix the problem.
  
Let me know if this will suffice, and I'll add it to fontconfig which is
scheduled to have a release (2.3) shortly.  I was hoping to have localized
family and style names ready for that release, but if this issue is blocking CSS
conformance in Mozilla, I can make a release without that functionality and pend
the family and style name changes until 2.4.

Comment 4

[Brian Ryner (not reading)]

That's how I would read the spec... what you suggested sounds like it should fix
the problem.  Thanks.

Comment 5

[keithp]

Hmm. Well, the code was certainly easy to write, but now I'm getting a very
undesireable result.  Asking for 'bitstream vera serif:italic' yields another
family (Times New Roman), because there is no "real" slanted form of Bitstream
Vera Serif.  The matching rules can't "look ahead" to see the rendering
manipulation rules which construct a shear transformation to artifically oblique
the font.

So, unless I can figure out a way around this, I've got the choice between a
version which works well with scalable fonts but is non-conformant with bitmap
fonts and a version which is conformant with all fonts but works poorly with
scalable fonts.

I haven't thought of a way to reconcile these two versions and come up with
something that can admit scalable fonts as being "obliquable" and yet skip over
bitmap fonts.

One possiblity would be to add artificial obliquing to bitmap fonts; it would be
easy to add a slight slant when loading them.  I'd rather sacrifice the
experience with bitmap fonts than with scalable ones.

Other suggestions would be welcome, and of course I'll keep thinking as well.

Comment 6

[tor]

There's also the issue of aliases I was discussing with you today.
Currently a match request of "helvetica,serif" will get expanded to
"helvetica,<list of fonts in serif alias>,serif, <list of fonts in
alias containing helvetica>,sans-serif".  Without a helvetica font
installed, the usual out-of-box case on linux, this will return a
serif font while we would prefer a reasonable helvetica substitution.

Comment 7

[Hixie (not reading bugmail)]

tor: We would?

Comment 8

[tor]

hixie: I would certainly expect a page that specifies just helvetica (to
which we add serif as the fallback) to display in a sans-serif font.

Comment 9

[Hixie (not reading bugmail)]

Why?

If the author wanted to default to something other than the user's default, he 
would have said:

   font-family: Helvetica, sans-serif;

Comment 10

[tor]

I like to make the reasably safe assumption that most web designers
are idiots, and when they say "font-family: helvetica" they mean "a
font without the twiddly bits".

Comment 11

[Hixie (not reading bugmail)]

Then you should suggest that to [e-mail], but in the meantime, our doing 
that would be non-compliant.

Comment 12

[Brian Ryner (not reading)]

I agree with Hixie.  This is not a case where an alias exists for Helvetica
itself.  This is fontconfig appending sans-serif fonts to the end of the list so
that if no families you gave in your pattern matched, it can come up with
something close to one of them.  What the author says explicitly should always
be preferred.

However, in the case tor is talking about, I'm wondering whether the 'serif' was
specified in CSS, or if we just appended it to the pattern because no CSS
generic font families were listed.  If that's the case, we may want to examine
that code, because I think we're defeating fontconfig's attempt to find a
reasonable default font based on the font you wanted to match.

Comment 13

[tor]

I'm talking about the case where only a single font was specified, ex:

  <font style="font-family: helvetica">Helvetica</font>

Comment 14

[Brian Ryner (not reading)]

See

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#462

and 

http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#1193

for the code I think could be changed.  It seems to me that if no generic font
was specified in css, we should go ahead and call FcConfigSubst without
appending 'serif' to the pattern.  Then we could inspect the pattern to see if
fallback fonts are in place... if not, we could then append serif and call
FcConfigSubst again.  Just an idea.

Comment 15

[keithp]

Ok, I had been assuming that the 'serif' entry in the pattern came from the
document and not from the browser configuration.  If you don't append 'serif',
things will work as desired.  Fontconfig will continue to ensure that as much of
the Unicode space is covered as can be managed from the available fonts, the
pattern only changes the order in which fonts are considered for inclusion. 
Seems like an opportunity to fix a bug by deleting code.  Always the best
outcome when it works.

Comment 16

[tor]

Found what appear to be a couple bugs in our xft glue:

  * "serif" is being added to the font list before SetupFCPattern is called,
    where it could be handled by the generic font fallback.

  * if more than one generic is listed in the font list, only the mGeneric
    font will be added to the pattern.

Comment 17

[Brian Ryner (not reading)]

Ok, so... back to the oblique problem.  Could you not just check FC_SCALABLE and
cause that to match an oblique style?

Comment 18

[keithp]

Fontconfig computes a 'distance' from the pattern to each available font; the
list returned from FcFontSort is sorted based on that metric.  Seemed like a
good idea when I wrote the code, and it works really well most of the time. 
That overall distance is actually an ordered list of distances for each property
in the font and pattern; each of these is computed without reference to the
remaining pattern elements.  What you need to do in this case is *reorder* the
list of values depending on two things: 1) whether the font was scalable
(FC_SCALABLE) and 2) whether the configuration contained instructions to take
that scalable face and shear it when an oblique varient was requested.  I'm
having trouble figuring out how that can be managed, even assuming arbitrary
modifications to the existing code (which I'm not averse to).

I'll be the first to admit that fontconfig is probably too configurable; and
that configurability makes solving problems like this harder.  However, I've
seen people find uses for most of the flexibility it offers, so I'd like to work
within the current visible artifacts of the architecture (match/edit rules,
multi-valued pattern elements).

Again, I can "solve" this issue by shearing bitmap fonts where necessary.  I
think that violates the spirit of bitmap fonts, but I guess I wonder how hard we
should work to enable people to continue to use such horrors anyways.

Comment 19

[Hixie (not reading bugmail)]

tor: I was responding to your comment 6, where you said "helvetica,serif". If 
the author just says "helvetica" then we should default to the user's default 
font selection.

Comment 20

[Mats Palmgren (inactive)]

Does this bug still occur in a recent trunk build?

Comment 21

[Zack Weinberg (:zwol)]

The current font-handling code bears very little resemblance to what it was at the time this bug was last discussed, and it rather sounds like it was a fontconfig issue rather than a bug in Firefox anyway.

If there is still a problem here, please file a new bug in Core:Graphics with a self-contained testcase; if possible, use @font-face in this test case so everyone is looking at exactly the same font(s).