>- at some point, 'apply' a text style from the dialog; in the course of
>Name() function is called on the font_instance instance that's going to be
>for the text. this function was unsetting the size field so that it doesn't
>the font descr
Good catch. I did not guess that Name was the culprit so tried to work
around it instead.
Meanwhile, I have now used pango_font_description_better_match() in font
selector where it matches the style of the text with the list of fonts it
has in the dialog. I assume this is what Pango also uses internally when
selecting a font that matches a description, and therefore we won't have any
more bugs like the one where the actual font of the selected object and the
font highlighted in the list are different.
However this is only a beginning: we have Pango fully working, but the way
it works does not satisfy me. The font_describe function in particular is
buggy: for example it returns "italic" for an "oblique" font and seems to
completely disregard condensedness. In fact this kind of problems is what I
expected from it, and now I want to bring back my "manual" fuzzy match
mechanism and embed it into the new system because it worked quite
satisfactorily before. Below is an outline; any comments are welcome.
The main idea of my fuzzy matcher is its reliance on font names to fugure
out font features. Yeah, this is ugly, but it's really the only sensible
way. For many features, there are no bits in the font itself that we can
query, or they are not present in all formats, or they are simply not set
(most common). So the way we'll do font matching is basically by doing a lot
of string parsing and comparisons.
Here's what we'll need:
- A new font_description struct (or class) that will hold the family name,
the standard weight/style/stretch/variant bits, and the exact face name. The
bits are filled in by parsing the face name, but the face name may contain
more style descriptions (e.g. "Outline" or "Alternate" or "Swash Caps") that
we need to store too.
- Each font_instance will have a member font_description that is filled in
when it's created.
- The data in font_description is filled in from PangoFontFace which in turn
is got from PangoFontFamily in FontFactory. That's the only place where we
can get this information about a font installed in the sysrtem, because here
we can call get_face_name on the face and parse it - we can't do that with a
PangoFont, and font_describe is useless.
- A function that creates a font_description from CSS style. Fills in all
the bits and, possibly, sets the face name too from the -inkscape-face:
extension CSS property which we will need if we really want to support
arbitrary fonts beyond the limitations of CSS. (This may wait, but the
infrastructure to support -inkscape-face: will be in place.)
- A function that returns the best match font_instance from a FontMap and
font_description. Does this by searching through all famililes and faces in
the map and finding the best one, using all of the information in
font_description including the one that Pango ignores. (This is more or les
how the old nr_type_directory worked.)
The last two functions will be used everywhere to get from a CSS style to
font_instance, instead of the current Face(descr).
That's how I see it at the moment. Comments welcome.
Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com