Hi Gail,
On 2008-March-27 , at 15:14 , Gail Carmichael wrote:
I was hoping to get some feedback on the kind of things I would like to work on for GSoC this year. The first portion of the summer should be spent on legalizing flowed text, as we established earlier.
[...] Next, because it is not expected to have the flowed text problem take the whole summer, I would like to know what the best second issue to tackle would be. There were a lot of great ideas like bulleted lists and so on, but these would take at least a whole summer, so I don't think they are appropriate to do now. I have been in contact with the Pango devs regarding the fact that the structure we use to store our fonts is rather limiting in what variants it can describe
[...]
So, a possibility for the second part of the summer is to research our best move in this matter. It is certainly not something that can be determined in a few days IMO - it will involve some pretty heft changes in terms of how fonts are stored in Inkscape, and could benefit from some refactoring of that code. The best result of this portion of work would probably be a detailed document outlining what is to be done. This would also ensure that the "work" doesn't conflict with the major refactoring project.
What do you guys think? Would this be a reasonable plan or should I instead try to tackle another smaller problem after the flowed text issue?
Given how important type is in our lives and in the design process, I also think that stellar font support (no less) is what people would expect from a design app. And that's what Inkscape is, to me. Such support is probably outside of SVG however, which can only represent fonts in CSS terms, so other may feel differently about it, if they consider Inkscape as an SVG editor rather than as a design app that uses SVG as its native format.
If you have time to cook up support for some exotic font variants, that would be great (especially if it is as good as what you did last year. The situation already improved a lot). I can provide some fonts with such variants (they're commercial but for testing purpose it would be all right I guess). Another important issue is that some variants that are supported now are still flaky in some fonts (for example, in the version of Helvetica I have, the bold version is mistaken for the normal one which means that I can't have normal Helvetica unless I remove the bold one. and Helvetica is a pretty common font ;) ).
If that is too much for a portion of a SoC, here as some other ideas from the top of my head: - debug the Text & Font (T&F) toolbar. there are plenty of reports on Launchpad about changes not being applied etc. - supplement the T&F toolbar so that it can replace the T&F palette: . add a variant drop down instead of just bold and italics buttons . add line spacing - improve the T&F toolbar by: . either improving the speed of or adding a way to disable the font preview in the font drop down (it is quite slow on my system, slow enough that combined with the bugs, it makes me want to use the T&F palette all the time) . use a spinbutton with a slider instead of a dropdown for font size . add some simple goodies such as exponent/indice buttons (which would just mean adding some kerning and making the size smaller, something that can possibly be done via extensions, provided they can hook up anywhere in the UI) - improve the T&F palette . redesign it so that it takes much less horizontal space and can be docked (ideally it should be at least as small as the align palette). that would probably be tricky but it would be a good way to explore some new UI concepts. . at least redesign current version so that it takes less space horizontally and gives more room to variants (move the size drop down to the right? move each portion out of the frames?) . resize the preview area vertically so that it shows the full height of the font even for large sizes (with a maximum so that it does not end up eating all your screen) - add on-canvas spell checking - improve font support in import/export operations . Cairo PDF export frequently mangles the kerning of fonts and has overall less support than Inkscape for text. It may be a problem with fontconfig/pango/cairo and not with Inkscape but it would be something to investigate . PDF import via poppler puts all the text attributes in the tspan element, rather than in the text one. Inkscape, when selecting such a text element, sees it as having no style, until the text element is entered, with the text tool, in which case Inkscape sees the tspan info. having a kind of import filter in Inkscape which would extract the info from the tspan, copy it to the text element and only keep in the tspan the differences from what's in <text> would make these imported documents much more enjoyable to work with. Other import formats would benefit from that I am sure (and overall, having an import filter to repare broken/imperfect SVG before opening it with Inkscape would be something nice. see this wiki page started from a dev list discussion a while ago: http://www.inkscape.org/wiki/index.php/XML_Repair)
OK, that's all for now ;)
JiHO --- http://jo.irisson.free.fr/