Re: [Inkscape-devel] RE: [ inkscape-Bugs-973768 ] letterspacingbroken
Something to think about is how to cope with a conflict between -inkscape-face and the normal CSS font properties.
I think -inkscape-face should have precedence. This is the best method we have for choosing the correct font, i.e. the one that the user actually set on the text previously. CSS properties are a fallback; if we can't find the exact match for -inkscape-face, we'll try to find the best approximate match from these properties (and so will do all non-Inkscape renderers). Conflicts can only happen if someone has tweaked Inkscape SVG outside of Inkscape changing the CSS properties but not -inkscape-face. In that case I think we should issue a warning but still use -inkscape-face for matching.
This is not much of an issue yet, but we will at least be forced to think about it more when we have better CSS support (for example, what if -inkscape-face is inherited, but different CSS properties are set locally?)
It should not be inherited I think. It's an unnecessary complication in a visual editor. If you want to apply it to many objects, just apply it to each one.
On a separate note, I think it would be worthwhile to preserve Pango font substitution in cases where none of the user-specified alternatives contain the desired codepoints, if we can, as well as how to deal with alternative fonts in the UI in the first place.
Codepoints are taken care of automatically now. The font we finally select (no matter by which method) and store in SVG is just the "default font" given to Pango which does layout and uses substitute fonts if the Unicode text needs them. For example right now you can create a text object with the default font, which is Vera Sans, and then switch your keyboard to Cyrillic or Arabic and type - everything will be displayed properly using substitute fonts because Vera Sans has neither Cyrillic nor Arabic in it. And in SVG, the text object is still marked up with a single font. It's really cool. Even Adobe SVG can't do that (although Batik can).
_________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee� Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
On Sat, 2004-06-19 at 03:00, bulia byak wrote:
Something to think about is how to cope with a conflict between -inkscape-face and the normal CSS font properties.
Conflicts can only happen if someone has tweaked Inkscape SVG outside of Inkscape changing the CSS properties but not -inkscape-face. In that case I think we should issue a warning but still use -inkscape-face for matching.
This is not much of an issue yet, but we will at least be forced to think about it more when we have better CSS support (for example, what if -inkscape-face is inherited, but different CSS properties are set locally?)
It should not be inherited I think. It's an unnecessary complication in a visual editor. If you want to apply it to many objects, just apply it to each one.
Having thought about this for a while, I strongly disagree.
Remember that Inkscape isn't only a visual editor, it's a structural editor too.
For example, someday our CSS support will be complete enough for people to want to edit it directly (as they do now for XML using the XML editor), and at that point they will be able to set the font properties directly and individually. Same effect as someone editing outside of Inkscape.
I think the correct approach is to let -inkscape-face be inherited, and treat it as a "hint" for picking the best installed font on the system.
IOW, -inkscape-face should take precedence if it matches the normal CSS-specified font closely enough; otherwise it is ignored.
I think that should avoid unpleasant surprises for structurally-oriented users, and won't disturb visually-oriented ones.
-mental
participants (2)
-
bulia byak
-
MenTaLguY