I've put in the application for Inkscape to participate in GSoC 2008.
Thank you everyone who submitted blueprints for feature idea suggestions (https://blueprints.launchpad.net/inkscape/). As promised, I've mined that to put together our ideas list, which you can see here:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code_2008
Bryce
Bryce Harrington wrote:
As promised, I've mined that to put together our ideas list, which you can see here:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code_2008
I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
Gail
On Wed, Mar 12, 2008 at 10:10 PM, Gail Carmichael wrote:
I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
https://bugs.launchpad.net/inkscape/+bug/171141 + comments :)
While this is marked as wishlist, this is a very popular feature request.
Alexandre
On Wed, Mar 12, 2008 at 03:26:24PM -0400, Gail Carmichael wrote:
Alexandre Prokoudine wrote: On Wed, Mar 12, 2008 at 10:10 PM, Gail Carmichael wrote: I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
[1]https://bugs.launchpad.net/inkscape/+bug/171141 + comments :)
While this is marked as wishlist, this is a very popular feature request.
Oh yeah, that would be cool to work on. I did some small work on bullets in DRAW, adding that might be doable as a summer of code project without too much or any core change. What do you guys think about this time-wise?
I also would *love* to see these, although since these are outside the SVG spec, they might be more involved to do than is appropriate.
An idea, rather than have bullet "elements" that get attached to a text object, it might work more intuitively to have a new kind of text layout combo object which alters itself graphically based on its text contents.
This could allow creating a text area, and then each time you hit <enter>, a new bullet automatically gets added at the appropriate location on the left. Or, you could have a text area with borders around each line, so hitting return generates a new box (useful for making forms). For UML diagrams and other technical drawing capabilities, these are extremely useful for making tables and such. Of course, that's not specifically font issues.
Bryce
I intend to apply for SoC this year. My intention is to work on SVGFonts implementation. Gail, does it conflict with your intended work on SoC? How does SVGFonts implementation relate to the current text handling code?
JucaBlues
Hey, I'm not sure exactly whether there is overlap or not - can you elaborate on what you want to do?
Gail
Felipe Sanches wrote:
I intend to apply for SoC this year. My intention is to work on SVGFonts implementation. Gail, does it conflict with your intended work on SoC? How does SVGFonts implementation relate to the current text handling code?
JucaBlues
I would like to start work on implementation of section 20 of the SVG1.1spec. That is "SVG Fonts", a feature that enables glyphs to be specified as arbitrary pieces of SVG and associated to a unicode char (or a unicode string, which enables ligadures). SVG Fonts are useful because they help enhance document acessibility (it keeps text stored as string even when your text has peculiar style, which usually is the case in company logos) making it nice for screen reader software. They also keep the semantics of the document, allowing better localization of artwork. I.e., it could be used on our about screens or other drawings which require versions in multiple languages. It also guarantees that text will be rendered identically on any software that implements it, not depending on specific fonts being installed on the user system.
I still need to learn more about pango, but I have already coded some things related to fonts in the past. I once wrote a truetype renderer in Z80 assembly for the MSX computer (I had only 64kbytes available on RAM in a system running at 3.7MHz clock) It was exciting to work on that :-D
I guess that one would need to invoke rendering of other svg objects and link these svg pieces to text handled by pango. But I am still not sure how that would be done.
JucaBlues
On Fri, Mar 14, 2008 at 12:11 AM, Gail Carmichael < gail.banaszkiewicz@...400...> wrote:
Hey, I'm not sure exactly whether there is overlap or not - can you elaborate on what you want to do?
Gail
Felipe Sanches wrote:
I intend to apply for SoC this year. My intention is to work on SVGFonts implementation. Gail, does it conflict with your intended work on SoC? How does SVGFonts implementation relate to the current text handling code?
JucaBlues
Felipe,
+1 for SVG font support! Of course the big win is in embedding fonts for file portability but there are lots of other neat use cases.
My personal favorite one would be creating legends for scientific figures: You could grab any data marker, and then include it in text spans when you are describing what the markers mean. One way to implement this would be a 'text symbols pallette' -- you could think of it as a document-specific wingdings glyph picker. I'd be happy to work on this once SVG font support is in place.
-Tom
PS. Since I didn't see it mentioned in the thread yet, the RFE for SVG font support is at https://bugs.launchpad.net/inkscape/+bug/170963
On Thu, Mar 13, 2008 at 9:19 PM, Gail Carmichael <gail.banaszkiewicz@...400...> wrote:
Oh, right! Yeah, I don't think that has any overlap, so... enjoy!! :)
Gail
Felipe Sanches wrote: I would like to start work on implementation of section 20 of the SVG1.1 spec. That is "SVG Fonts", a feature that enables glyphs to be specified as arbitrary pieces of SVG and associated to a unicode char (or a unicode string, which enables ligadures). SVG Fonts are useful because they help enhance document acessibility (it keeps text stored as string even when your text has peculiar style, which usually is the case in company logos) making it nice for screen reader software. They also keep the semantics of the document, allowing better localization of artwork. I.e., it could be used on our about screens or other drawings which require versions in multiple languages. It also guarantees that text will be rendered identically on any software that implements it, not depending on specific fonts being installed on the user system.
I still need to learn more about pango, but I have already coded some things related to fonts in the past. I once wrote a truetype renderer in Z80 assembly for the MSX computer (I had only 64kbytes available on RAM in a system running at 3.7MHz clock) It was exciting to work on that :-D
I guess that one would need to invoke rendering of other svg objects and link these svg pieces to text handled by pango. But I am still not sure how that would be done.
JucaBlues
On Fri, Mar 14, 2008 at 12:11 AM, Gail Carmichael <gail.banaszkiewicz@...400...> wrote:
Hey, I'm not sure exactly whether there is overlap or not - can you elaborate on what you want to do?
Gail
Felipe Sanches wrote:
I intend to apply for SoC this year. My intention is to work on SVGFonts implementation. Gail, does it conflict with your intended work on SoC? How does SVGFonts implementation relate to the current text handling code?
JucaBlues
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, 2008-03-12 at 13:50 -0700, Bryce Harrington wrote:
On Wed, Mar 12, 2008 at 03:26:24PM -0400, Gail Carmichael wrote:
Alexandre Prokoudine wrote: On Wed, Mar 12, 2008 at 10:10 PM, Gail Carmichael wrote: I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
[1]https://bugs.launchpad.net/inkscape/+bug/171141 + comments :)
While this is marked as wishlist, this is a very popular feature request.
Oh yeah, that would be cool to work on. I did some small work on bullets in DRAW, adding that might be doable as a summer of code project without too much or any core change. What do you guys think about this time-wise?
I also would *love* to see these, although since these are outside the SVG spec, they might be more involved to do than is appropriate.
An idea, rather than have bullet "elements" that get attached to a text object, it might work more intuitively to have a new kind of text layout combo object which alters itself graphically based on its text contents.
This could allow creating a text area, and then each time you hit <enter>, a new bullet automatically gets added at the appropriate location on the left. Or, you could have a text area with borders around each line, so hitting return generates a new box (useful for making forms). For UML diagrams and other technical drawing capabilities, these are extremely useful for making tables and such. Of course, that's not specifically font issues.
I think that it'd be interesting to work on something similar to LPE: LTE or Live Text Effects. So basically you'd be creating text that looks like: "My first point\nMy second point\nMy third point" which would appear in the SVG as:
* My first point * My second point * My third point
If something similar to LPEs were developed, then there could be more and more text based plugins (perhaps the resize one discussed earlier) that could work with text.
--Ted
On Wed, Mar 12, 2008 at 10:26 PM, Gail Carmichael wrote:
https://bugs.launchpad.net/inkscape/+bug/171141 + comments :)
While this is marked as wishlist, this is a very popular feature request.
Oh yeah, that would be cool to work on. I did some small work on bullets in DRAW, adding that might be doable as a summer of code project without too much or any core change.
In terms of project description I'd probably put it as "text styles support", where part of mentioned in the request features would be subprojects :) But sure I agree with bulia that resolving existing bugs has more priority (at least providing sane UI in the Text tool options toolbar).
Alexandre
On Wed, Mar 12, 2008 at 4:22 PM, Alexandre Prokoudine
https://bugs.launchpad.net/inkscape/+bug/171141 + comments :)
Even though in general, I support the "everyone works on whichever he/she wants" idea, with text I take an exception. I think we must not spend any resources on richer text features until we resolve the most basic problem: flowed text is invalid SVG. Frankly, it's a shame, and I won't welcome any feature work involving flowed text so long as it's all built on sand.
On Wed, Mar 12, 2008 at 5:29 PM, Gail Carmichael <gail.banaszkiewicz@...400...> wrote:
Oh yeah, I forgot about that. I can definitely start with that. If I remember correctly though, that was a fairly quick job right?
It's hard to say, but it seems to me the amount of work here should be comparable to adding tref support.
On Wed, Mar 12, 2008 at 03:10:31PM -0400, Gail Carmichael wrote:
Bryce Harrington wrote:
As promised, I've mined that to put together our ideas list, which you can see here:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code_2008
I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
Perhaps not specific to fonts, but the font selector has a LOT of bugs reported against it - some due to Pango, some due to our font support, and some perhaps more Gtk oriented. I'd love to see improvements made to that to get these bugs taken care of.
Bryce
Bryce Harrington wrote:
On Wed, Mar 12, 2008 at 03:10:31PM -0400, Gail Carmichael wrote:
Bryce Harrington wrote:
As promised, I've mined that to put together our ideas list, which you can see here:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code_2008
I'm still hoping to continue with the font support, but it will depend on Pango. I wouldn't mind hearing what other text improvements are top of the list for you guys. Would give me a good idea what to focus on.
Perhaps not specific to fonts, but the font selector has a LOT of bugs reported against it - some due to Pango, some due to our font support, and some perhaps more Gtk oriented. I'd love to see improvements made to that to get these bugs taken care of.
I think the text toolbar in general needs to be overhauled. It's not good that some options are missing from the toolbar, as well as it's not good that you can get different results/behavior from the toolbar and the text and font dialog. Note that I haven't used the text features in a couple months, but when I last did, I almost exclusively was forced to use the text dialog instead of the toolbar, which was frustrating.
-Josh
Josh Andler wrote:
I think the text toolbar in general needs to be overhauled. It's not good that some options are missing from the toolbar, as well as it's not good that you can get different results/behavior from the toolbar and the text and font dialog. Note that I haven't used the text features in a couple months, but when I last did, I almost exclusively was forced to use the text dialog instead of the toolbar, which was frustrating.
I remember last year that I was urged to try and tackle non-UI issues since a broader selection of people would probably be willing and able to do that. Maybe a text UI overhaul could be added to the ideas list and another student would pick it up? That way I can try to tackle the more fundamental issues.
Gail
On Mar 12, 2008, at 1:46 PM, Josh Andler wrote:
I think the text toolbar in general needs to be overhauled. It's not good that some options are missing from the toolbar, as well as it's not good that you can get different results/behavior from the toolbar and the text and font dialog. Note that I haven't used the text features in a couple months, but when I last did, I almost exclusively was forced to use the text dialog instead of the toolbar, which was frustrating.
Yes, it very much needs an overhaul.
I was looking at it as part of converting all the toolbars to stock. Much of what is going on there is the code stealing events and trying to manually do everything, instead of fitting into existing GTK/GTKmm widgets and behavior.
If anyone wants to look into this before I get time to address it, please drop me a line and we can coordinate info and timing.
Hi all,
just a quick note to let you know that I'm considering applying for GSoC 2008. The reason why this doesn't read "I'm going to apply" is that I will graduate in May and don't really know what comes afterwards so there is a small chance that something not yet foreseeable will keep me from participating. But I'd say that the odds are quite good for SoC.
There are 2 projects that I'd be very interested to do.
1) Polishing and improving the 3D box tool and its functionality (obvious, isn't it? :=))
2) Working on improved guide handling as proposed in the blueprint at
http://wiki.inkscape.org/wiki/index.php/SpecGuidesImprovement
Although these two look like rather different kettles of fish, I believe that it would actually be very fruitful to consider them together. To wit, one of the most obvious next steps for 1) would be draggable perspective lines. But if you read the specification for 2) and have a look at the pictures in section "On-canvas editing" there is a striking analogy in functionality (guides can be dragged or rotated about a predefined center, much as perspective lines should be draggable and rotateable around the vanishing point). So what I'd like to propose is to treat these issues together in order to obtain a cleaned-up (--> perfectly in the spirit of 0.47) version of the guideline code which can be reused for draggable perspective lines and probably many more things we're not even thinking of yet. This is of course just a first thought and I will have to make this more precise and boil it down to a good application draft. In particular, I need to think about what kinds of UI improvements would make most sense (and are feasible) with this approach.
On second thought (and on re-reading the guide improvements spec) it may also make sense to unify and improve the handling of guides and layers by allowing, e.g., nested grouping and other things that can be found in the many layers-related RFEs in LaunchPad.
Hmm, obviously I haven't really deliberated on any of this in detail but it seems that there is quite some room for refactoring and unification work in these areas. Any further suggestions from other developers are very welcome, especially if you have concrete suggestions how the refactoring could be done (and also if it applies to different areas).
Finally, here are two further ideas for 3D box-related improvements (other than what you can find in the original proposal[1]):
- More intuitive handling of perspectives using a kind of "trackball" approach (I know there is a RFE in LaunchPad for this but can't find it right now). However, it's not obvious to me how to implement this with the wide variety of seemingly "strange" or degenerated perspectives that are possible in the 3D box tool. I'm certain that it's doable and the mathematics can be figured out but this will require further thoughts.
- Implement a kind of LPE which takes as input an arbitrary path and draws it in some perspective (which may for example be specified by a 3D box). This is a long-standing request and sounds very exciting. I did some experiments with 2geom after last year's SoC and it turned out that this is actually quite easy to do (at least in principle :) although I expect a considerable amount of tweaking to be needed in order to make it really stable and robust). Nonetheless, I feel that we should first put some more work into the overall UI and polishing of the 3D box tool before tackling something like this. For example, the previously mentioned "trackball interface" would provide a very intuitive basis to modify paths which have such a LPE applied to them.
Well, this email has gotton rather lengthy and as I said most of this is not yet very thoroughly thought through (and certainly not yet more than a random collection - sorry, my time is quite limited in these days of examinations). Just wanted to let you participate in my ideas. Any input/comments/suggestions are welcome.
Cheers, Max
[1] It can be found at http://www.rzuser.uni-heidelberg.de/~malbert/
On Wed, 2008-03-12 at 23:26 +0100, Maximilian Albert wrote:
just a quick note to let you know that I'm considering applying for GSoC 2008. The reason why this doesn't read "I'm going to apply" is that I will graduate in May and don't really know what comes afterwards so there is a small chance that something not yet foreseeable will keep me from participating. But I'd say that the odds are quite good for SoC.
I don't know about your specific situation, but my understanding for GSoC is that you have to be admitted to attend school in the Fall. So if you're graduating, you need to be accepted to grad school for the Fall.
--Ted
Ted Gould schrieb:
On Wed, 2008-03-12 at 23:26 +0100, Maximilian Albert wrote:
just a quick note to let you know that I'm considering applying for GSoC 2008. The reason why this doesn't read "I'm going to apply" is that I will graduate in May and don't really know what comes afterwards so there is a small chance that something not yet foreseeable will keep me from participating. But I'd say that the odds are quite good for SoC.
I don't know about your specific situation, but my understanding for GSoC is that you have to be admitted to attend school in the Fall. So if you're graduating, you need to be accepted to grad school for the Fall.
Thanks for pointing this out, but in the program FAQ [1] they say
"As long as you are enrolled in a college or university program as of April 14, 2008, you are eligible to participate in the program."
Since this is the case for I guess it's alright. Max
[1] See question 7 at
http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_student_eligibilit...
participants (10)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Felipe Sanches -
Gail Carmichael -
Jon A. Cruz -
Josh Andler -
Maximilian Albert -
Ted Gould -
Tom Davidson