Continuing the font system cleanup, today I checked in a fairly large chunk of code:
1. All CSS font properties (style, weight, stretch, variant) are now fully supported. This support is somewhat flakey in that when you change a font of a text object, the properties get their values from parsing the style name of the font, assuming the name uses more or less standard terms (and is in English). This is currently unavoidable, because the Xft back-end provides no information about the font style except italic and bold bits, which is clearly insufficient for our purposes. When we switch to Pango, we'll be able to get from it an exact match for the CSS properties, but it needs to be tested how reliable is this information from Pango (it may well be that parsing the name, although ugly, is still more reliable). Similarly, when Inkscape reads a CSS font specification from SVG, it finds the most appropriate font based on the name only.
So, now Inkscape can see, apply, and read from SVG a lot more fonts and styles than before. It still cannot handle _all_ fonts, but the limit of the CSS syntax is reached, and further improvement is only possible if we introduce an inkscape:font-style extension attribute. Perhaps I will do this next.
2. The matching algorithm that finds the most appropriate family and style is much improved. If there's no exact family match, Inkscape now uses partial matches (e.g. "Times New Roman" if SVG specifies "times", or "Adobe Garamond" if the file requires "Garamond", or vice versa), of which it selects the family with the shortest name. Inkscape now knows more standard families (most importantly Bitstream Vera, but also Luxi and Windows standard fonts) and uses one of them when all else fails. It also attempts to avoid using fancy fonts (such as monospace, outline, etc) when not asked, so as to prevent funny font substitutions. Finally, it now understands and tries to obey generic font families (serif, sans-serif, monospace) and can parse multiple families in one specification (e.g. "font-family:garamond,times,serif") finding the best match for all listed families. With matching style, it will match "italic" when you specify "oblique" but no oblique is available, and vice versa, and will find the closes stretch and weight match among the available styles.
3. Whenever an inexact family/style match is chosen, Inkscape will now display a g_warning showing what font was required and what is being used instead. You will probably get a lot of such warnings for your old files, because older versions of inkscape/sodipodi often included bogus and unnecessary font references. Newly created files should be OK (at least when viewed on the same system). In particular, there were warnings in icons.svg, tutorial.svg and about.svg; I cleaned them all up so please do "make install" again.
If you get some suspicious font substitution or any other font problem, contact me at once.
_________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...
bulia byak wrote:
warnings in icons.svg, tutorial.svg and about.svg; I cleaned them all up so please do "make install" again.
Speaking of icons.svg, I have noticed something that maybe one of the users could help with, if this is OK with Bryce.
Currently, icons.svg is rather unorganized. It would be really great if someone could organize and arrange the icons according to their use. And annotated, too. Like if the file were arranged like this, visually:
Toolbox icons, 20x20 [icon] [icon] [icon] text-tool curve-tool freehand-tool
Menu icons, 24x24 [icon] [icon] [icon] import-into file_export print-direct
....etc....
The only restrictions are that the icons should not be resized, that they must remain top-level <g> members of the svg tree, and that they retain their proper names.
Does that sound OK?
Bob
On Tue, 2 Mar 2004, Bob Jamison wrote:
Speaking of icons.svg, I have noticed something that maybe one of the users could help with, if this is OK with Bryce.
Currently, icons.svg is rather unorganized. It would be really great if someone could organize and arrange the icons according to their use. And annotated, too.
Sounds good, and shouldn't be too hard of a task - can you add it to the roadmap for 0.39, and make a page in wiki with a copy of your directions? Then just keep an eye out for someone looking for a task like this.
It might also be worthwhile to make sure we have SVG representations of all of the .xpm's in use, in case we want to shift entirely over to SVG for all program bitmaps.
Bryce
Two things:
1.) What is the speed differences between using SVGs compared to XPMs for icons in the interface?
2.) Currently, our interface doesn't use SVGs for icons, right?
Jon
On Tue, 2004-03-02 at 09:19, Bryce Harrington wrote:
On Tue, 2 Mar 2004, Bob Jamison wrote:
Speaking of icons.svg, I have noticed something that maybe one of the users could help with, if this is OK with Bryce.
Currently, icons.svg is rather unorganized. It would be really great if someone could organize and arrange the icons according to their use. And annotated, too.
Sounds good, and shouldn't be too hard of a task - can you add it to the roadmap for 0.39, and make a page in wiki with a copy of your directions? Then just keep an eye out for someone looking for a task like this.
It might also be worthwhile to make sure we have SVG representations of all of the .xpm's in use, in case we want to shift entirely over to SVG for all program bitmaps.
Bryce
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2 Mar 2004, Jonathan Phillips wrote:
Two things:
1.) What is the speed differences between using SVGs compared to XPMs for icons in the interface?
I don't think anyone's quantified it, but I traced through the code that gets called to render them, and it's quite extensive. My guess is that it's quite a bit slower, but couldn't say how much. I suspect that could be mitigated via caching the rendered bitmaps at compile or installation time.
2.) Currently, our interface doesn't use SVGs for icons, right?
I think it uses a mix of both SVG and XPM.
Bryce
It would be quite *cool* to keep our icons in icons.svg and would allow folks to develop themes easier IMO. The caching of rendered icons at compile time sounds like a brilliant solution, but don't know what that would entail.
Jon
On Tue, 2004-03-02 at 11:16, Bryce Harrington wrote:
On Tue, 2 Mar 2004, Jonathan Phillips wrote:
Two things:
1.) What is the speed differences between using SVGs compared to XPMs for icons in the interface?
I don't think anyone's quantified it, but I traced through the code that gets called to render them, and it's quite extensive. My guess is that it's quite a bit slower, but couldn't say how much. I suspect that could be mitigated via caching the rendered bitmaps at compile or installation time.
2.) Currently, our interface doesn't use SVGs for icons, right?
I think it uses a mix of both SVG and XPM.
Bryce
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2 Mar 2004, Jonathan Phillips wrote:
It would be quite *cool* to keep our icons in icons.svg and would allow folks to develop themes easier IMO. The caching of rendered icons at compile time sounds like a brilliant solution, but don't know what that would entail.
Jon
Yeah I don't know either. Of course inkscape can be run from the commandline and used to create png's of given dimensions, so if you wanted to brute force it, that might be an option.
Bryce
What would be very cool is if we could abstract the icon to the point where all icons are in icons.svg (default) and then could have the system look for icons_XXXXX.svg and match the system theme. Then that would solve the icon themability RFE. Also, that would allow ppl like defendguin and others to see all the icons for their theme in one file.
Jon
On Tue, 2004-03-02 at 12:42, Bryce Harrington wrote:
On Tue, 2 Mar 2004, Jonathan Phillips wrote:
It would be quite *cool* to keep our icons in icons.svg and would allow folks to develop themes easier IMO. The caching of rendered icons at compile time sounds like a brilliant solution, but don't know what that would entail.
Jon
Yeah I don't know either. Of course inkscape can be run from the commandline and used to create png's of given dimensions, so if you wanted to brute force it, that might be an option.
Bryce
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2004-03-02 at 14:16, Bryce Harrington wrote:
I don't think anyone's quantified it, but I traced through the code that gets called to render them, and it's quite extensive. My guess is that it's quite a bit slower, but couldn't say how much. I suspect that could be mitigated via caching the rendered bitmaps at compile or installation time.
The SVG icons are generally only rendered once into GdkPixbufs and then painted from those, so it's not like we take a hit for every expose event.
I honestly don't think it's worthwhile trying to optimize the SVG icon display too agressively, since it's mostly limited to our startup time, and really doesn't appear to cost _too_ much there.
What we probably should be doing is setting up a GtkIconFactory which does the rendering, and is in a position to better cache the rendered icons in a centralized place, and do things more on-demand.
SPIcon doesn't really have any advantages over GtkImage, anyway, now that I've rewritten it to use standard gdk calls for painting (which means the compositing can be hardware accelerated on servers with XRender, and it shouldn't look hideous on pixmap themes anymore).
-mental
On Tue, 2 Mar 2004, Bob Jamison wrote:
Date: Tue, 02 Mar 2004 08:28:59 -0600 From: Bob Jamison <rjamison@...73...> To: inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] more font work
bulia byak wrote:
warnings in icons.svg, tutorial.svg and about.svg; I cleaned them all up so please do "make install" again.
Speaking of icons.svg, I have noticed something that maybe one of the users could help with, if this is OK with Bryce.
Currently, icons.svg is rather unorganized. It would be really great if someone could organize and arrange the icons according to their use. And annotated, too. Like if the file were arranged like this, visually:
Toolbox icons, 20x20 [icon] [icon] [icon] text-tool curve-tool freehand-tool
Menu icons, 24x24 [icon] [icon] [icon] import-into file_export print-direct
....etc....
The only restrictions are that the icons should not be resized, that they must remain top-level <g> members of the svg tree, and that they retain their proper names.
Would be possible (or even a good idea) to have some way of simply allowing the group id to be shown directly in the document?
This would save adding lots of text descriptions as the icons are all already nicely labelled.
- Alan H.
participants (6)
-
Alan Horkan -
Bob Jamison -
Bryce Harrington -
bulia byak -
Jonathan Phillips -
MenTaLguY