Hi, Is anyone actually working on fixing the font problems (ie, no styles except the very basic ones)? This is a total show-stopper for professional use. If no one is working on it, is there a guide to how to start on working with the Inkscape code, submitting patches etcetera?
I'm not sure that I'll have much time to work on it but I am a programmer and I have worked with Linux fonts quite a lot over the years. I really like Inkscape and use it for design work (real, paid design work) quite a lot but it always hits a wall when a client is already using use a font which Inkscape can't handle but has to be incorporated, like Helvetica Black, which happened yesterday.
There is almost nothing else which causes me to have to revert to Illustrator now other than font handling and I'm starting to really resent Illustrator because of it.
Thomas Worthington
Thomas Worthington wrote:
Is anyone actually working on fixing the font problems (ie, no styles except the very basic ones)? This is a total show-stopper for professional use. If no one is working on it, is there a guide to how to start on working with the Inkscape code, submitting patches etcetera?
Hi Thomas,
AFAIK nobody is working on it. I hope you can improve things! It is really appreciated a lot :-) I assume you are working on windows. Although badly out of date, you can find some hints here: http://inkscape.modevia.com/win32_inkscape_org/win32buildnotes.html I cannot access the wiki at the moment, I think there is a page there that has more up to date information. Here is a brief list of how to get inkscape built: 1. Get the code from SVN, using for example TortoiseSVN. Checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk 2. At http://inkscape.modevia.com/win32libs/?C=M;O=D you can download the latest library packages. You need gtk210-070527.7z and mingw-4.2.0-070518.7z or anything newer. Unpack them (for ease you can unpack them to c:\gtk210 and c:\mingw but it should not matter) 3. Check the contents of mingwenv.bat (inkscape root dir) to see whether the directories are correct. 4. Go to cmdline and to the inkscape dir and enter mingwenv.bat g++ buildtool.cpp -o btool.exe btool 5. An inkscape dir is now created there and you have built your own inscape! (note that if you change a lot of includes (i.e. dependencies), you should delete build.dep before running btool again; if that doesn't work you must do 'btool clean' and then run btool again.)
TortoiseSVN can easily create patches that you can submit. Note that you get SVN commit access when 2 of your patches are accepted :-) If you have more questions, you can mail me any time; although these weeks I will probably not be able to respond.
Cheers, Johan
On Sat, 16 Jun 2007 11:49:47 +0100, <J.B.C.Engelen@...1578...> wrote:
Thomas Worthington wrote:
Is anyone actually working on fixing the font problems (ie, no styles except the very basic ones)? This is a total show-stopper for professional use. If no one is working on it, is there a guide to how to start on working with the Inkscape code, submitting patches etcetera?
Hi Thomas,
AFAIK nobody is working on it. I hope you can improve things! It is really appreciated a lot :-) I assume you are working on windows.
Actually, I'm in Linux. Sorry, I should have been clearer.
Thomas
Thomas Worthington wrote:
On Sat, 16 Jun 2007 11:49:47 +0100, <J.B.C.Engelen@...1578...> wrote:
Thomas Worthington wrote:
Is anyone actually working on fixing the font problems (ie, no styles except the very basic ones)? This is a total show-stopper for professional use. If no one is working on it, is there a guide to how to start on working with the Inkscape code, submitting patches etcetera?
Hi Thomas,
AFAIK nobody is working on it. I hope you can improve things! It is really appreciated a lot :-) I assume you are working on windows.
Actually, I'm in Linux. Sorry, I should have been clearer.
We won't hold that against you. ;-)
You might also want to stop by the irc channel/jabber room sometime. At almost any time of the day there is usually someone knowldegable around, and even if we can't help you we can very often point you to the person who can.
As far as how to contribute. There should be some information on the wiki and website (I've emailed osuosl about the outage). But as Johan said we require two accepted patches before we grant commit access. Patches should be submitted to the sf.net patch tracker. It helps to send a message to this list as well so that interested devs know to review the patch.
Gail Banaszkiewicz is working in the area of text and font for Google's Summer of Code. I'm not sure where she is focusing but you may want to contact her.
Thanks for your interest.
Aaron Spike
Gail wrote:
I may be doing something that would help. Have a look at my Summer of Code proposal found on this page http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm . The suggested order of attack for the items in my proposal has UI Redesign at the top and Font Family Variants next.
Oh sorry! I thought you only worked on the text tool stuff, not specific font things (I don't know what the problems are...).
Cheers, Johan
Gail Banaszkiewicz wrote:
J.B.C.Engelen@...1578... wrote:
Thomas Worthington wrote:
Is anyone actually working on fixing the font problems (ie, no styles except the very basic ones)? This is a total show-stopper for professional use. If no one is working on it, is there a guide to how to start on working with the Inkscape code, submitting patches etcetera?
AFAIK nobody is working on it.
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. :-)
Aaron Spike
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
Thomas Worthington wrote:
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.
Well Thomas, I will leave it up to you. If you feel like looking around the codebase and trying a few things before I get to that particular task, that would be great. Otherwise, we can connect again once I do get there (which may or not be during the official summer program - I try not to predict these things). Either way, it sounds like you have a wealth of knowledge that will help very much. I have worked with fonts in the past (during my CorelDRAW dev days), but you clearly have a very detailed knowledge of them overall.
Looking forward to working together!
Gail
On 6/16/07, Thomas Worthington <tww@...1737...> wrote:
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.
In 0.45, such fonts with non-ascii names failed, but in SVN they have more chance of working because I added proper quoting around font family names in CSS.
Gail Banaszkiewicz wrote:
I may be doing something that would help. Have a look at my Summer of Code proposal found on this page http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm. The suggested order of attack for the items in my proposal has UI Redesign at the top and Font Family Variants next. I am currently working on a bug (making <tref> work) but will be moving to the UI when that's done. Maybe I will get to the font family stuff before the end of the summer, but maybe not - even if I do not, I intend to work on it during school, too.
I have an undergoing experiment about authoring websites using 100% Inkscape and one of the problems I see is about fonts: you want the layout to remain the same on every viewer, no matter which platform is used, but fonts availability is a big problem. A solution I see is to use fonts that are the metric equivalents of the Microsoft fonts (like the recently released Liberation [2]) and set a fall-back solution for your document to use either Liberation or Microsoft fonts, which is available.
In HTML/CSS one would do either: font-family: "Liberation Sans", Arial, sans-serif ; or font-family: Arial, "Liberation Sans", sans-serif ;
I think it would be incredibly cool and useful to have in Inkscape an easy GUI to manually provide those fall-back fonts.
[1] - http://svg.nicubunu.ro/ [2] - https://www.redhat.com/promo/fonts/ - http://www.press.redhat.com/2007/05/09/liberation-fonts/
Gail,
I may be doing something that would help. Have a look at my Summer of Code proposal found on this page http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm. The suggested order of attack for the items in my proposal has UI Redesign at the top and Font Family Variants next. I am currently working on a bug (making <tref> work) but will be moving to the UI when that's done. Maybe I will get to the font family stuff before the end of the summer, but maybe not - even if I do not, I intend to work on it during school, too.
If you are flexible on this, is there any chance you could work on the CSS extension for font variants next, after the tref work? After all, UI will eventually be fixed by someone sooner or later anyway, but the CSS stuff needs more than casual understanding and determination... so I think it's better to focus on that while you are being paid for your work :)
bulia byak wrote:
If you are flexible on this, is there any chance you could work on the CSS extension for font variants next, after the tref work? After all, UI will eventually be fixed by someone sooner or later anyway, but the CSS stuff needs more than casual understanding and determination... so I think it's better to focus on that while you are being paid for your work :)
I'm perfectly flexible ;) Although I have been embarrassingly slow with tref, one of the reasons is that I'm working really hard to understand how text works overall in Inkscape on a deeper level. So this should help me dive into the CSS stuff much more quickly.
(I have tref mostly working, just ironing out a few wrinkles...)
Gail
On Saturday, June 16, 2007, 3:57:13 PM, Gail wrote:
GB> I may be doing something that would help. Have a look at my GB> Summer of Code proposal found on this page GB> http://www.scs.carleton.ca/~gbanaszk/code/soc07/index.htm. The GB> suggested order of attack for the items in my proposal has UI GB> Redesign at the top and Font Family Variants next. I am currently GB> working on a bug (making <tref> work) but will be moving to the UI GB> when that's done. Maybe I will get to the font family stuff GB> before the end of the summer, but maybe not - even if I do not, I GB> intend to work on it during school, too. GB> GB> Let me know if that's the kind of work you're looking for.
Gail, I hope you don't mind my commenting on some aspects of your proposal here. You write
http://www.scs.carleton.ca/~gbanaszk/code/soc07/TextImprovements.pdf
Implementation issues to consider include the limitations of CSS itself. The CSS fontstyle property only takes values of normal, italic, and oblique. The weight property allows for bold fonts. The only values available for the font-variant property are normal and small-caps. Therefore, to support variants like outline and swash, a workaround is required.
To clarify, the weight property allows for up to nine weights, 100 to 900, as well as the convenience keywords normal and bold: http://www.w3.org/TR/CSS21/fonts.html#font-boldness and these are the same numbers as you will find in a truetype or opentype font to denote the weight. So light and black weights are already covered.
You are right that there is no support for swash and outline variants; a new attribute in an inkscape namespace that is like font-variant but also allows for swash and outline is exactly the right way to do this.
Note though that if a font provides multiple swash variants for a given character, that needs to be handled in the actual text element, using altGlyph.
On 7/23/07, Chris Lilley <chris@...157...> wrote:
You are right that there is no support for swash and outline variants; a new attribute in an inkscape namespace that is like font-variant but also allows for swash and outline is exactly the right way to do this.
Yes, except that we rather want to store not just variant within a family, but the entire font name including font family and variant - because in some fonts, even separating the name into "family" and "variant" parts is not trivial.
On Mon, 2007-07-23 at 18:58 +0200, Chris Lilley wrote:
You are right that there is no support for swash and outline variants; a new attribute in an inkscape namespace that is like font-variant but also allows for swash and outline is exactly the right way to do this.
Chris,
A couple of questions:
- Do you know if the SVG working group is going to pick this up at some point? Or is it a little too pedantic for web stuff?
- Do you know if anyone at Adobe is still working on SVG? It'd be nice if they could be keyed into this conversation -- interchange would be ideal even if we implement it slightly differently internally.
Corel and others too. I don't think we can entirely pull the data out of the font name if everyone else is putting it in. We can just be "more clear" in our own files.
--Ted
On Tuesday, July 24, 2007, 12:34:49 AM, Ted wrote:
TG> On Mon, 2007-07-23 at 18:58 +0200, Chris Lilley wrote:
You are right that there is no support for swash and outline variants; a new attribute in an inkscape namespace that is like font-variant but also allows for swash and outline is exactly the right way to do this.
TG> Chris,
TG> A couple of questions:
TG> - Do you know if the SVG working group is going to pick this up at some TG> point? Or is it a little too pedantic for web stuff?
It might, but it would need to coordinate with the CSS and the XSL WGs. CSS WG in particular is already over burdened with specs that are not finished; I doubt they want to take more work on.
I think there could be interest for XSL to look at it, though.
TG> - Do you know if anyone at Adobe is still working on SVG?
They have gone quiet; this seemed to coincide with their takeover by/of Macromedia and focussing on Flash.
Their authoring products continue to export and import SVG; I don't have access to CS3 so don't know if this has continued to improve.
TG> It'd be nice TG> if they could be keyed into this conversation -- interchange would be TG> ideal even if we implement it slightly differently internally.
TG> Corel and others too.
The latest release of Corel Draw (the X3 suite) *did* have improvements in SVG export, so seems to be under active development.
TG> I don't think we can entirely pull the data out TG> of the font name
Its a hard problem in general to get reliable metadata out of the font name. You need to read the individual bits of data from the font files.
TG> if everyone else is putting it in. We can just be TG> "more clear" in our own files.
TG> --Ted
participants (8)
-
unknown＠example.com -
Aaron Spike -
bulia byak -
Chris Lilley -
Gail Banaszkiewicz -
Nicu Buculei (OCAL) -
Ted Gould -
Thomas Worthington