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/
On Sat, Mar 29, 2008 at 12:07 PM, jiho <jo.irisson@...400...> wrote:
[..]
- 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
This is so because the printing-subsystem based PDF exporter recalculates kerning information. Currently, only the Cairo renderer based PDF exporter can export text properly (ie. it lays out text the same way as Inkscape does because it uses the same information from libnrtype as the internal renderer). In order to provide an easily implementable interface, the printing subsystem gives much less information to the printer driver than actually what is available.
. PDF import via poppler puts all the text attributes in the tspanelement, 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.
I'm planning to add this tspan/text "feature" to the PDF import extension along with the stylesheet optimizer. These'll be included in my GSoC proposal for PDF export/import enhancements.
Regards, miklos
On 2008-March-29 , at 18:43 , Miklós Erdélyi wrote:
On Sat, Mar 29, 2008 at 12:07 PM, jiho <jo.irisson@...400...> wrote:
[..]
- 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
This is so because the printing-subsystem based PDF exporter recalculates kerning information. Currently, only the Cairo renderer based PDF exporter can export text properly (ie. it lays out text the same way as Inkscape does because it uses the same information from libnrtype as the internal renderer). In order to provide an easily implementable interface, the printing subsystem gives much less information to the printer driver than actually what is available.
Actually, the issues I had were with the Cairo PDF exporter. not with printing. so I guess that even this one has trouble sometimes. The issue really seamed to be with font support. I have some test files around but I guess that, if the problem is font based, it will be difficult to investigate outside of my particular setup.
. PDF import via poppler puts all the text attributes in thetspan 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.
I'm planning to add this tspan/text "feature" to the PDF import extension along with the stylesheet optimizer. These'll be included in my GSoC proposal for PDF export/import enhancements.
That would be very nice. If it can be made somehow independent from the pdf import, just like a filter hooked up at the end of the import process, it would be even nicer because other importer would benefit from it.
JiHO --- http://jo.irisson.free.fr/
On Thu, Mar 27, 2008 at 10:14 AM, Gail Carmichael < gail.banaszkiewicz@...400...> wrote:
Hi everyone,
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.
[...]
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.
I just submitted an application covering the above two issues (with mention of a bug with bold faces of some fonts). It's not too late to change it as the applications are due tomorrow, so if anyone has any comments on it, feel free to make 'em :)
I have been trying to get onto IRC but my program for it keeps crashing, so I am sticking to email for now. Sorry about that.
Gail
On Mar 30, 2008, at 10:45 AM, Gail Carmichael wrote:
I have been trying to get onto IRC but my program for it keeps crashing, so I am sticking to email for now. Sorry about that.
Jabber is working fine. :-)
http://www.inkscape.org/discussion.php?lang=en
Pidgin and Psi might be good clients to try in addition to others.
Hi Gail,
I spent some time this afternoon with Felipe trying to flesh out with him exactly what his project is going to entail, and I've come to the conclusion that your two proposals are going to conflict with each other quite badly.
It will come as no surprise to you Gail that the bottleneck is Pango. Specifically, you are trying to push through a system font which Pango refuses to accept because it can't be expressed using CSS, while Felipe is trying to push through a user font which, even if it had a CSS expression, would not be available for Pango's lookup.
I can think of a couple of technical solutions to this problem and no doubt there are several more which could be done, but that's not the purpose of this e-mail. My major point is that, as they stand, your projects have sufficient overlap that I personally don't feel that it would be a good idea for them both to be accepted for SoC.
I know the deadline is almost upon us and I'm really sorry I didn't figure this out sooner. From a purely pragmatic (and cold-hearted) perspective I suspect that Gail's proposal is the easiest to change at this late stage, however given that you are both in competition with each other anyway for whatever few places that Google offers the project, it may be simpler just to accept that you are in competition and each try to make your own proposal the most compelling.
Of course if there's any way to disentangle the two that I haven't thought of I really want to hear it.
My apologies again,
Richard.
Richard Hughes wrote:
I know the deadline is almost upon us and I'm really sorry I didn't figure this out sooner. From a purely pragmatic (and cold-hearted) perspective I suspect that Gail's proposal is the easiest to change at this late stage, however given that you are both in competition with each other anyway for whatever few places that Google offers the project, it may be simpler just to accept that you are in competition and each try to make your own proposal the most compelling.
No worries at all, Richard! I didn't realize there would be so much overlap. There are a couple of possible solutions to this problem.
Of course I am perfectly willing to change my proposal if that's what makes more sense (though I wouldn't mind taking part in some conversations with you guys about the technical solutions to Pango's limitations, since I have had my fingers into some parts of that anyway). I can always finish off my side of things later on, after SoC (if Felipe doesn't end up taking care of that as it is). Thesis time begins in May, so I should, in theory, be able to devote some time to Inkscape in the fall (I'm aiming for once a week at the minimum).
I have also applied to another project, which I could have a chance of getting in on. Now, I don't want you to simply not accept me because of that, because nothing is for certain over there, either. But it is something to consider once I get solid, 'for-sure' info about it.
So, having said all that, it's not too late to officially change my proposal in Google. Any die-hard requests for what to do for the second half of the summer? Working on some of the issues suggested by jiho is certainly an option (and if nobody has any strong desires, this is what I will draw my ideas from). As a reminder, his list included some UI improvements to the text toolbar for example (which would certainly be worthwhile).
Gail
Of course I am perfectly willing to change my proposal if that's what makes more sense (though I wouldn't mind taking part in some conversations with you guys about the technical solutions to Pango's limitations, since I have had my fingers into some parts of that anyway). I can always finish off my side of things later on, after SoC (if Felipe doesn't end up taking care of that as it is). Thesis time begins in May, so I should, in theory, be able to devote some time to Inkscape in the fall (I'm aiming for once a week at the minimum).
Yes, we need to have a long discussion about the technical issues in due course - I just wanted to get the administrivia out of the way first. Of course the best possible outcome for the project is if you choose to do your proposal anyway, even if you don't get accepted.
So, having said all that, it's not too late to officially change my proposal in Google. Any die-hard requests for what to do for the second half of the summer? Working on some of the issues suggested by jiho is certainly an option (and if nobody has any strong desires, this is what I will draw my ideas from). As a reminder, his list included some UI improvements to the text toolbar for example (which would certainly be worthwhile).
I have no major preferences, but one suggestion which I haven't seen elsewhere (and which is in keeping with the first half of your proposal) is to fix the other major standards-deficiency in text layout: vertical text. Specifically, the glyph-orientation-horizontal/vertical, dominant-baseline and alignment-baseline properties are not supported at all.
Richard.
On Sun, Mar 30, 2008 at 6:58 PM, Richard Hughes <cyreve@...400...> wrote:
I have no major preferences, but one suggestion which I haven't seen elsewhere (and which is in keeping with the first half of your proposal) is to fix the other major standards-deficiency in text layout: vertical text. Specifically, the glyph-orientation-horizontal/vertical, dominant-baseline and alignment-baseline properties are not supported at all.
Hmm, that's quite interesting actually. I worked on a lot of LTR and vertical text bugs on my second work term at Corel. Maybe that will somehow help me out :)
In the end, as Max said, it's ok to rework the projects after acceptance anyway, so I will do that if needed. For now I will just at least change the second part so as to not conflict with Felipe.
Gail
On Mon, Mar 31, 2008 at 3:52 AM, Gail Carmichael wrote:
In the end, as Max said, it's ok to rework the projects after acceptance anyway, so I will do that if needed. For now I will just at least change the second part so as to not conflict with Felipe.
There might be a week long deadline extension. Organizations seem to have a significantly lower amount of applications this year.
Alexandre
Alexandre Prokoudine wrote:
There might be a week long deadline extension. Organizations seem to have a significantly lower amount of applications this year.
Really? Is that true of Inkscape, too? Because it seems like there are many high quality people interested this time, dare I say maybe more than before?
Gail
On Mon, Mar 31, 2008 at 6:15 PM, Gail Carmichael wrote:
Alexandre Prokoudine wrote:
There might be a week long deadline extension. Organizations seem to have a significantly lower amount of applications this year.
Really? Is that true of Inkscape, too? Because it seems like there are many high quality people interested this time, dare I say maybe more than before?
It's true for everyone. Amount of applications is at least two times lower than last year. This is partly because of vacations at universities.
Alexandre
On Mon, Mar 31, 2008 at 06:20:49PM +0300, Alexandre Prokoudine wrote:
On Mon, Mar 31, 2008 at 6:15 PM, Gail Carmichael wrote:
Alexandre Prokoudine wrote:
There might be a week long deadline extension. Organizations seem to have a significantly lower amount of applications this year.
Really? Is that true of Inkscape, too? Because it seems like there are many high quality people interested this time, dare I say maybe more than before?
It's true for everyone. Amount of applications is at least two times lower than last year. This is partly because of vacations at universities.
13 apps for Inkscape so far; I recall we had a lot more last year, although about half were invalid (spam, incomplete, so on). So maybe while we have fewer, they're of higher quality? (I haven't looked at the applications so can't say one way or the other.) Maybe with the extra week we'll pick up a few more, but we're likely to get only about 6-8 slots, so I think we have an adequate number of apps in any case.
Bryce
Richard Hughes wrote:
Of course if there's any way to disentangle the two that I haven't thought of I really want to hear it.
See this thread on the GSoC mailing list:
Basically, it says that if a student gets selected and the mentoring organization agrees, he/she can work on a totally different project if that is desired. Of course, this requires that both Gail and Felipe are accepted, but in this case it could be a way to gain one of them some time for working out a new proposal.
HTH, Max
participants (8)
-
Alexandre Prokoudine -
Bryce Harrington -
Gail Carmichael -
jiho -
Jon A. Cruz -
Maximilian Albert -
Miklós Erdélyi -
Richard Hughes