
Gail, It's great to see that someone is tackling this. I wrote more in desperation than in hope. Although I've been a programmer for probably a good deal longer than you've been alive(!) I do hate C++ with a passion (I was exposed to Smalltalk at an early age and it spoilt me for other OO languages) and I've also recently started a small design business with a friend which is taking up time and not yet generating a lot of money.
I'm also a bit of a font obsessive and have been frustrated by the complexities of font handling on Linux for the last ten years. I use TrueType fonts under TeX for most of my personal word processing and having delved into the depths of these and later been beaten by the OpenType format I was not feeling enthusiastic about having a hack at Inkscape's formidable code base as my first major outing in C++!
So, in other words, I've very glad and relieved to find that someone is already being paid to have a look at the very thing that's bugging me. I would still like to help, certainly, but I'd guess that you would be more competant than me.
So here's some thoughts:
I did once have most fonts (Type 1, TT, and OT) working with Inkscape under version 1 of fontconfig. In that version the font caches were text files and could be easily edited. I simply wrote a Perl script which went through these cache files and rewrote the names of all fonts that did not use the CSS varient names so that the font name got the unrecognised varient appended. Thus "Helvetica style=Black Oblique" became "Helvetica-Black style=Oblique". This worked really well and exposed pretty well every font to Inkscape.
Sadly, this no longer works as the new cache files are binary and the format is, shall we say, "obscure". I spent a lot of time beating my head against this deadend.
I can't see that there is any way to keep CSS compatibility and not have some sort of translation scheme in the background (probaly wouldn't work anyway, now that I think of it). But I don't know to what extent the CSS compatibility is important to the Inkscape user base. It is certainly of zero interest to me - I want to design logos and letterheads for print and it would be no sacrifice to me to see any and all HTML/CSS support removed. I daresay that this is not the point of view of all Inkscape users.
I think the only reasonable compromise is to have a "CSS-only" button on the font dialogue and simply filter out any non-CSS variants when it is activated. Thus, people desiging for the web can be sure that they have not used a varient that won't work and the rest of us can have the unrestrained joy of our entire font collection.
I don't know how the current system enforces the varients but I guess there's a list somewhere which is applied to the XML and simply prevents any non-canonical varients appearing - I tried editing the XML and it simply reverted any such styles to empty strings. If that could be turned on and off then it might be quite a simple change.
One special, particular note: one of the most heavily used display fonts in the western world (and Japan) is Eurostile Extended #2, where "Extended #2" is the varient name. Any new system really has to be able to handle that name, including the hash mark. I can't stress how often this font is used in the real world enough, I see it literally every day somewhere or other. I even sold a design that used it and which was made in Inkscape back when I could use such fonts with it, so it's particularly galling to now have to break out Illustrator to edit a design which was actually originally done in Inkscape!
Anyway, where there is one font with odd characters there's bound to be others without even worrying about Unicode, so the code needs to be generous in what it allows.
I'd be happy to discuss/test any ideas, or to swap tales of assembler coding if you'd rather, and perhaps have a poke at the coding too as time permits but I think my schedule would be so slow as to be more of a hinderance than a help to someone who's got the time to really crack on.
Thomas
On Sat, 16 Jun 2007 16:58:12 +0100, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
Aaron Spike wrote:
Gail Banaszkiewicz wrote:
The suggested order of attack for the items in my proposal has UI Redesign at the top and Font Family Variants next.
Gail, if Thomas gets to the Font variant problem before you, will you still have enough work to do for SoC? We'd hate to discourage a new contributor. :-) Oh yes, of course - but let's see if what he wants is even what I was proposing there (let us know, Thomas). Even if he gets started I can continue to work on it later. Whatever works best :)
Gail