Around 20 o'clock on Sep 6, Brian Stell wrote:
> > + Font matching / substitution
> > + Glyph fill in
>
> These are 1st on my list.
Ok. I suggest we use the existing Xft matching mechanism to locate
suitable fonts. It would be augmented with Unicode coverage information,
this can be leveraged to perform additional matches to find additional
fonts for glyph fill-in.
Substitution is a different problem; the current Xft config file syntax
leaves a bit to be desired. I was thinking of Juliusz's example:
Arial:weight=Black -> ArialBlack:weight=Medium
While this could probably be considered "correct", I don't think
applications are likely to present the face in this form. In addition,
I believe the font patterns would have to be extended so that this
modified weight attribute was associated with the modified face name, the
alternative is to mismatch when ArialBlack is not available.
Instead of editing the incoming pattern, perhaps we should consider
editing the font names instead -- apply the edits to the fonts and leave
the patterns alone. This has the advantage of fixing the ArialBlack
problem above while also making matching marginally faster.
The problem is then how to disambiguate among multiple matches:
match family == "times" edit family = "times new roman,times,serif";
match family == "times new roman" edit family = "times new roman,times,serif";
A match on "times new roman" hits both of these, and they appear equally
valid. Make the RHS order drive the match like:
match family == "times" edit family = "times,times new roman,serif";
match family == "times new roman" edit family = "times new roman,times,serif";
Now "times" matches "times", but we'd prefer it to match "times new roman"
instead if that's available.
We could allow multiple values on the LHS and rank them by order:
match family == "times new roman,times" edit family = "times new roman,times,serif";
This has the advantage/disadvantage of combining all equivalent fonts into one
statement; it makes adding new fonts quite a bit harder. We could create
a new statement that combined these two nearly equal sides into one:
substitute {
"times new roman"
"times"
"serif"
}
This has the significant advantage of being declarative instead of
imperative -- it's a lot easier to describe what this statement does in
terms not involving XftPattern. However, it doesn't even come close to
solving Juliusz's example. I'd live without a solution to that though;
the general populace doesn't understand that weight comes in more than two
kinds.
Once the font has been selected, I think we should apply a new set of
rules to adjust how the glyphs are rasterized. The current Xft mechanism
uses additional parts of the XftPattern to drive that conversion; that
seems like a nice way to pass data through the font configuration
mechanism back to the rasterization engine.
Should this configuration be shared in the common font configuration file?
Or should it be specific to the rasterizer? I argue that both are
reasonable -- attributes like 'anti-alias' and 'rgba' are specific to the
output device, but attributes like artificial obliquing are generic.
I propose that we allow rasterizer-specific configuration to share the
global configuration file, that will require some discipline to avoid
conflicting attributes between different rasterizers, perhaps we would
wrap the rasterizer specific configuration in separate sections:
rasterizer 'X' {
match { size > 8 size < 14 edit anti-alias = false; }
}
Are the existing match/edit rules reasonable for this task? Should they
take their cues from the matched font, the input pattern or both? Or
should we replace them with something different?
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
