what should fuzzy font matching do? (i admit i haven't really looked into what it was doing)
It has almost nothing to do with actual fonts, it only does a lot of string parsing - breaking CSS family specification into tokens, comparing them to the names of all available fonts, and selecting the best match based on various priorities and weights. I'll look at how Pango does its matching but I think we'll need to keep most of, if not all, of this fuzzy matching code (which even does some cashing to speed up matching - this turned out necessary for documents such as keys.svg). Likely we'll ask for a list of font names (families and styles) from Pango, do our fuzzy matching, and request the font with the best name we found.
- Symbol fonts still don't work. When I select
Symbol font in the list, I get
argh. some error checking is needed. tho it's strange that the symbol font doesn't have a charmap. how is the unicode<->glyph conversion done?
PfaEdit (a highly recommended font editor btw) reports that symbol.ttf (from a Windows installation) uses "Symbol" encoding, and it correctly shows all its characters. So perhaps it's just a special encoding that we need to support.
pango layout should do the trick, with one caveat: since you can only specify one font for the layout, for the dominant direction, all the text in the opposite direction gets a default font from pango. if you have idea on how to tell pango to choose one specific font...
Well, in this case one can put the opposite-direction fragments to be in <tspan>s in SVG, and set a font for them. Anyway, this is much better than not having RTL before.
Unfortunately I can't compile the Windows build today - errors during linking:
libinkscape.a(inkscape.o)(.text+0x1a6):inkscape.cpp: undefined reference to `sp_marshal_VOID__POINTER_UINT' libinkscape.a(document.o)(.text+0x194):document.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' libinkscape.a(view.o)(.text+0x136):view.cpp: undefined reference to `sp_marshal_BOOLEAN__VOID' libinkscape.a(view.o)(.text+0x1e7):view.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE'
etc. I used to get such errors before from time to time and I don't really know how to fix them. Any help is appreciated.
_________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI...
bulia byak wrote:
Unfortunately I can't compile the Windows build today - errors during linking:
libinkscape.a(inkscape.o)(.text+0x1a6):inkscape.cpp: undefined reference to `sp_marshal_VOID__POINTER_UINT' libinkscape.a(document.o)(.text+0x194):document.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE' libinkscape.a(view.o)(.text+0x136):view.cpp: undefined reference to `sp_marshal_BOOLEAN__VOID' libinkscape.a(view.o)(.text+0x1e7):view.cpp: undefined reference to `sp_marshal_VOID__DOUBLE_DOUBLE'
etc. I used to get such errors before from time to time and I don't really know how to fix them. Any help is appreciated.
Those missing function are marshaller for signals in GObject, generated automatically from descriptions in sp-marshal.list (src/helper/sp-marshal.list).
Maybe glib-genmarshal has not been run during the build process?
On Fri, 2004-06-11 at 03:17, bulia byak wrote:
argh. some error checking is needed. tho it's strange that the symbol font doesn't have a charmap. how is the unicode<->glyph conversion done?
PfaEdit (a highly recommended font editor btw) reports that symbol.ttf (from a Windows installation) uses "Symbol" encoding, and it correctly shows all its characters. So perhaps it's just a special encoding that we need to support.
Assuming I'm guessing correctly what problem fred was describing (I wasn't privy to the original email) we may also need to tweak the mapping between the symbol encoding's codepoints and unicode ourselves.
Symbol might be getting mapped directly into the first Unicode private use area, but I think user expectations are that it will also map into the bottom 256 unicode codepoints also.
pango layout should do the trick, with one caveat: since you can only specify one font for the layout, for the dominant direction, all the text in the opposite direction gets a default font from pango. if you have idea on how to tell pango to choose one specific font...
Well, in this case one can put the opposite-direction fragments to be in <tspan>s in SVG, and set a font for them.
Alternatively, maybe we could inject pango markup to control the font when doing the layout.
Anyway, this is much better than not having RTL before.
Yes, I think it is not necessarily something we need to worry about fixing for this release. Best to save our strength for fixing things that used to work and now don't. ^_-
(... yeah, like the statusbar... I'll get back to that soon, I promise ^^;;...)
-mental
participants (3)
-
bulia byak -
Emanuele Aina -
MenTaLguY