Misdetection: oblique vs italic

[dhardy]

Using standard DejaVu system fonts:

$ fc-list
...
/usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique

Properties detected by fontdb:

name	family	style	weight	stretch	monospace	path	index
DejaVuSans-Oblique	DejaVu Sans	Italic	Weight(400)	Normal	FALSE	/usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf	0

[RazrFalcon]

DejaVuSans-Oblique.ttf is called Oblique, but not marked as one. An Oblique font must have the 9th bit in OS/2/fsSelection to be set. And it's not.

[dhardy]

I wonder if it's a deliberate mis-parameterisation. Practically, most people don't care for the difference between oblique and italic, and when they do they would normally select a specific font face. (I'd guess. I'm not a designer.)

Implication: maybe APIs shouldn't differentiate the two at all? (Matching logic like this is too precise — e.g. if one selects an "oblique" style and only very few fonts match exactly, then "weight" matching has to come from that set. This is more a concern with "stretch" since that is matched earlier.)

[RazrFalcon]

I have 2500 font on my machine and none of them are Oblique. Not sure if this is style is still used nowadays.

The current matching algorithm is based on the CSS spec. I don't think we should change it.

I will check why fontconfig thinks that this font is Oblique.

[dhardy]

I guess the specifics of the matching algorithm shouldn't matter: this matching only happens within a single font family. If there's no match, CSS says try the next candidate family (which fontdb doesn't implement, but it's easy enough by iteration over query — what is not so trivial is handling generic family names).