• at some point, 'apply' a text style from the dialog; in the course of

action, the Name() function is called on the font_instance instance that's going to be used for the text. this function was unsetting the size field so that it doesn't appear in 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