- Inkscape Devel - Inkscape Mailman

constructor initializing problem
by unknown＠example.com 09 Apr '08

09 Apr '08

Hi all, I have a strange problem with initializing the bool called "concatenate_before_pwd2" in my Effect class. I want to set it to 'false' per default, so in the constructor of Effect. A derived class LPEBendPath needs it to be true so does that in the constructor. I think this bool should now evaluate to true for the rest of LPEBendPath's life. But for some reason... it doesn't! Thanks for enlightening me. Johan Relevant excerpts from the code follow below. Attached the complete files. Effect::Effect(LivePathEffectObject *lpeobject) : concatenate_before_pwd2(false) { lpeobj = lpeobject; oncanvasedit_it = 0; } class LPEBendPath : public Effect, LivePathEffect_group_bbox { LPEBendPath::LPEBendPath(LivePathEffectObject *lpeobject) : Effect(lpeobject), ... { ... concatenate_before_pwd2 = true; } Effect* Effect::New(EffectType lpenr, LivePathEffectObject *lpeobj) { Effect* neweffect = NULL; ... case BEND_PATH: neweffect = static_cast<Effect*> ( new LPEBendPath(lpeobj) ); break; ... return neweffect; } std::vector<Geom::Path> Effect::doEffect_path (std::vector<Geom::Path> & path_in) { std::vector<Geom::Path> path_out; if ( !concatenate_before_pwd2 ) { // this expression for some reason is true for LPEBendPath ! ... }

2 3

LPE internals - conversions
by unknown＠example.com 09 Apr '08

09 Apr '08

Hello all, Currently, LPEs have a 'doEffect' chain: basically a stack of functions that are called sequentially that convert from Inkscape's path type, to several 2geom types in steps. An LPE defines a doEffect within this chain to override the default behavior (pass on to next down the stack). The problem is this: Inkscape's paths can be discontinuous, meaning for the user that visually they are 2 separate paths. The LPE doeffect chain now converts it to one path. This means that for example lpe-PatternAlongPath will see discontinuous paths as a single path (thanks JFB!), so when applying a pattern (copy modus: single stretched) the pattern is applied along the whole path, ignoring the discontinuity. 1. Take two separate paths and combine them into one (ctrl+k) 2. draw a circle, convert to path, copy it 3. apply lpe-Pattern Along Path to (1) and paste the circle as pattern 4. the result will be two circle halves. where actually I would have expected to see two circles, since it looks like the original path is 2 paths. This is undesired behavior I think. Note that e.g. lpe-Gear also suffers from this: it just seems to ignore the second path. Do people consider this as a bug, or as a feature? The solution is to break the path into separate parts, group it, and apply an LPE on the group... but... especially with the lpe stacking, this is no longer possible and we do need to consider what lpe should do with discontinuous paths. I have made a fix, which I will probably apply to the whole doEffect chain. But perhaps people do not see this as a bug in PatternAlongPath, which means I will have to add a checkbox for the new behavior.... Basically, instead of concatinating all paths, run the effect multiple times on the differnt paths: Technical, instead of: std::vector<Path> doEffect_path (std::vector<Path> & path_in) { Piecewise<D2<SBasis> > pwd2_in; for (unsigned int i=0; i < path_in.size(); i++) { pwd2_in.concat( path_in[i].toPwSb() ); } Piecewise<Geom::D2<Geom::SBasis> > pwd2_out = doEffect_pwd2(pwd2_in); std::vector<Path> path_out = path_from_piecewise( pwd2_out, LPE_CONVERSION_TOLERANCE); return path_out; } I want to change it to: std::vector<Path> doEffect_path (std::vector<Path> & path_in) { std::vector<Path> path_out; for (unsigned int i=0; i < path_in.size(); i++) { Piecewise<Geom::D2<Geom::SBasis> > pwd2_in = path_in[i].toPwSb(); Piecewise<Geom::D2<Geom::SBasis> > pwd2_out = doEffect_pwd2(pwd2_in); std::vector<Path> path = path_from_piecewise( pwd2_out, LPE_CONVERSION_TOLERANCE); for (unsigned int j=0; j < path.size(); j++) { path_out.push_back(path[j]); } } return path_out; } Note that: Piecewise<D2<SBasis> > doEffect_pwd2 (Piecewise<D2<SBasis> > & pwd2_in) ==> this one does the actual effect Thanks for your consideration. I'll make sure this will not break the other effects. Regards, Johan

2 3

Re: [Inkscape-devel] [Bug 174720] Re: currentColor in style= is misinterpreted
by Jasper van de Gronde 09 Apr '08

09 Apr '08

bulia byak wrote: > On Tue, Apr 8, 2008 at 7:56 AM, Martin von Gagern > <martin.vgagern@...240...> wrote: > ... >> Another interesting way to avoid these issues might be some more >> extensive verification. An invalid style attribute like the one above >> certainly should never have been generated by inkscape itself. If you >> were to implement appropriate error checking code in sp_style_read_*, >> you could enable it while processing internally generated attributes. >> You might wish to disable it for file reading or attributes entered in >> the XML editor, or even better, you might wish to handle errors there >> differently. So perhaps you want a format error listener interface, and >> pass instance of that along. Quite a bit of work, but maybe worthwhile, >> as it would also help identify SVG documents in the wild that aren't >> fully understood by inkscape. > > I don't think we want to overburden Inkscape itself with checks over > and above those prescribed by the SVG/CSS standard. But an external > consistency checker for Inkscape-produced files might be a great > addition to the testing project. Instead of making sure that Inkscape knows how to parse/serialize CSS properly, wouldn't it be better to simply use libcroco for all of this? At first glance it seems to provide plenty of functionality.

2 1

BZR EOL
by Aaron Spike 09 Apr '08

09 Apr '08

There is some activity in the bzr community right now about EOL handling. If you are interested, see the thread at: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/39636… Couldn't hurt to voice our concerns there. Aaron Spike

1 0

uniconv conversion from .cdr on Windows XP
by Alvin Penner 07 Apr '08

07 Apr '08

has anyone been able to successfully use the python utility uniconv to do a conversion on a win32 machine from .cdr to .svg, preferably from a DOS prompt, since that is easier? I can do a successful conversion from .svg to .svg in DOS, but that is not very interesting. When I try either a .cdr to .svg, or .wmf to .svg, I get the following errors http://www.nabble.com/file/p16517282/uniconv.txt uniconv.txt -- View this message in context: http://www.nabble.com/uniconv-conversion-from-.cdr-on-Windows-XP-tp16517282… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 1

GSoC Tech Drawing proposal (and a question/further suggestion)
by Maximilian Albert 07 Apr '08

07 Apr '08

Hi all, here is finally my application for this year's GSoC (still up to minor modifications and slight abridgement; please also note that the website for the proposal is not updated yet, I will do this tomorrow or on Monday). If you have any comments, suggestions or criticism, I'd love to hear them. Apart from many of the suggestions mentioned on this list (thanks again to everyone, the resonance was overwhelming!), I also included a new idea which struck me tonight but could turn out quite involved (or else rather easy if I'm lucky) so I thought I'd ask whether it is appropriate for inclusion. Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for integrating LPE parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool anyway, I was wondering whether I could set up a general framework that allows LPE parameter controls to be automatically added to certain toolbars and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs (but with some extended functionality). I haven't thought this through yet but at first sight it doesn't seem _too_ difficult to do (since much of Johan's code could probably be reused), yet very convenient and highly desirable, at least from my biased point of view :). Or is it complete nonsense? What do you think? Max === GSoC Proposal: Tech Drawing Abilities for Inkscape === == Abstract == While Inkscape is very powerful as vector graphics editor, it is mainly suited for artists. Technical drawings and geometric constructions are possible, but they are cumbersome to do and difficult to edit later on, especially if mutual relations like "is parallel to", "passes through", etc., are to be retained. Already a limitation for artistic work, this is a showstopper for people like architects or scientific researchers who wish to use Inkscape for precise drawings in construction plans or academic posters. I propose a new Tech Drawing tool, combined with a number of related enhancements, that will establish Inkscape as a mature tool for these purposes and further strenghten its status as the leading open source vector graphics editor. == Deliverables and goals == (1) New "Tech Drawing" tool for geometric constructions (2) UI framework for on-canvas and toolbar adaption of LPE parameters (see below) (3) Refactoring of code obsoleted by this work (4) Documentation for the new frameworks (5) As time permits, implementation of more advanced tech drawing features === Details === Graphical illustrations, more details and further ideas are provided at the accompanying web page for this proposal. [1] 1) The new tool will comprise a number of "modules" for the most commonly needed geometric constructions, including: - parallel/perpendicular to a line (at a given distance or through a given point) - angle/segment bisector - circle with given center and radius / circle through 3 points - interactive path mirroring/rotation (for symmetric drawings) - measurements (distances, angles, possibly path lengths and areas) All parameters involved in a construction (angles, distances, coordinates, etc.) will be settable both by mouse and via exact numeric keyboard input through toolbar controls. Internally, the tool will be implemented as a collection of "Live Path Effects" (LPEs) [2]; the algorithms for non-trivial path manipulations are provided by the 2geom library [3]. LPEs are designed as a general framework for new tools in Inkscape and provide excellent low-level support for a unified treatment of these seemingly quite disparate geometric construction modules. 2) Notwithstanding, LPEs lack a good *interactive* user interface for easy on-canvas adaption of their parameters. Moreover, the existing controls are only accessible in a cumbersome way through the LPE dialogs. In view of these limitations and the intended use of LPEs for future tools in Inkscape, I will - expand the current rudimentary support for on-canvas interaction to a flexible UI - implement a general framework that allows automatic integration of LPE controls into the toolbars of existing tools (similar to how they are now added to the LPE dialogs) as well as toggling their visibility depending on the LPE being used The latter will essentially also implement the toolbar of the new Tech Drawing tool and greatly simplify the creation of future tools through LPEs. 3) Some old and heavily buggy cold will become obsolete by my work. This is certainly true for "linked/dynamic offsets" (which 2geom's algorithms and the new UI supersede) but likely applies to other code, too (possibly guidelines). I will look for code that falls into this category and plan my work accordingly, in agreement with the internal refactoring goals of Inkscape's upcoming version 0.47. 4) As a matter of course, the new frameworks will be extensively documented during their implementation (following the excellent example of existing LPE structure [2]). 5) Inkscape's bug tracker lists a huge number of feature requests related to geometric/CAD drawing. If time permits (which I expect), I will implement a suitable number of these. Here is an incomplete collection (visually illustrated and continued at [1]), in rough order of expected difficulty/desirability. - "Preserve angles" mode for node editing of polygons - Marker improvements (correct color, direction/point of alignment) - Improved snapping (in particular, "tangent snapping" of lines/paths to other paths) - User-defined coordinate origin/axis directions (up vs. down); this should be combined with removing Inkscape's internal usage of two different coordinate systems (an endless source of confusion and bugs) - Document units scaling (e.g., 1cm = 200m); particularly useful for map creation - "Real time helpers" such as "dynamic/smart guides" or "interactive rulers"; since the recent addition of temporary canvas items to Inkscape this has become within closer reach == Timeline == Throughout the project I will gather user feedback regarding feature desirability and UI design. The resonance from the community has already been overwhelming during the write-up of this proposal (which also attests the great need for the proposed features). Coding will start by implementing the above-mentioned geometric construction modules as LPEs. Telling from two proof-of-concept implementations (a "circle construction"-LPE and a "perspective path"-LPE) [4][5] this should be accomplishable within the first week. The next 2-3 weeks will be spent on the UI for on-canvas parameter adaption. Allowing for some time to deal with unexpected problems, this should leave us with a basic but functional tool after about one month. The second part of my work will focus on implementing the automatic toolbar integration framework as described under item (2) above. I anticipate this phase to take also roughly 4 weeks. Depending on the remaining time and based on discussion with my mentor and the user community, I will then implement a suitable number of more advanced features such as the ones collected under item (4). Together with whatever work on the documentation still remains at that point, this will easily fill the time until the end of SoC. == Experience with Inkscape and qualification == I started coding for Inkscape during GSoC '07 when I implemented the new 3D box tool which is included in the just released version 0.46. After SoC I considerably refactored the tool to lay the foundation for further 3D features. This has led to a "perspective path LPE" [5] as first payoff with many more things planned. I also worked on numerous bug fixes (code-wise or by providing feedback) and am an active member of the devel mailing list. My acquaintance with Inkscape's code will allow me to dive into the real work right from the start (unlike last year when getting used to unknown parts consumed a considerable amount of time even at later stages of the program). For a description of other former coding projects and general open source experience see [1]. == About me == I'm a 27-year-old student of mathematics from Heidelberg, Germany. I'm currently in the phase of my final exams which will lead to my graduation in May. Having neither classes nor other obligations in summer, I can devote my full time to the SoC project. I'm a passionate a-capella singer, performing in various choirs and vocal groups. My resulting experience with organizing concerts and communicating with people will stand me in good stead for this project, too (after all, open source is all about community). I also enjoy sports (running, volleyball), reading, and hanging out with friends. See [1] for my detailed CV. == Other GSoC applications == I have not applied for any other GSoC projects. [1] http://www.rzuser.uni-heidelberg.de/~malbert/ [2] http://wiki.inkscape.org/wiki/index.php/MakingLivePathEffects [3] http://lib2geom.sourceforge.net/ [4] SVN commit #18177, viewable online at http://tinyurl.com/yvyftz [5] SVN commit #18093, viewable online at http://tinyurl.com/6pkw76

3 3

GSoC 2008 Extensions Proposal
by Karlisson 07 Apr '08

07 Apr '08

Hi! I'm Karlisson Bezerra, from Brazil. I'm a system analisys student, web developer and work with Inkscape ilustrating websites and comics. Here is my blog, where I post comics drawn in Inkscape: http://nerdson.com I like programming and I've studying Python for a while, and got interested in extensions for Inkscape, so decided to propose a simple Application to GSoC 2008, to start colaborating with this excelent project. Unfortunately, I have submitted the proposal before reading the SOC Application Template (I'm sorry :-), but I'll respond the questions: I have first hear of Inkscape in a local free software meeting, and fell in love with it =). I'm working with it since this meeting, and wish to learn to program in C++ to collaborate more. I still have a short participation, with some questions and e-mails. My plan to GSoC is just to start coding for Inkscape, in a language which I have some knowledge. My past collaborations were just html code, illustrations and layouts for free software meetings and projects. I'm just starting to help coding =). I'm updating and reviewing the subversion trunk a fews months ago, since the great modifications to 0.46. My application (as described in the proposal) is a set of Python extensions for Inkscape that gets text objects and "break apart" it in lines, words or letters, and creates different text objects for each fragment of the text. The set can have also a extension to "join" every piece of text in one unique text object. Original request is here: https://bugs.launchpad.net/inkscape/+bug/171748 I've already started coding and have a functional extension. The splitted words get all aligned below the original text. :) The others extensions will be based on it. Hope you like the proposal, thanks! -- Karlisson de Macêdo Bezerra http://nerdson.com/ - "Don´t panic!"

1 0

GSoC: Customizable toolbars
by Krzysztof Kosiński 06 Apr '08

06 Apr '08

Seeing that the deadline has been extended, I'm considering applying for the Google Summer of Code. My idea is to implement customizable toolbars (preferably via a drag-and-drop interface similar to that in Firefox). This would apply to both the tools bar and the toolbar that sits below the menus, but wouldn't need to apply to the toolbox (the tool-specific toolbar). The steps involved: 1. (required) Create the required prefs infrastructure (proposed: eq. "tools.selector.order", -1 means not in the toolbar, sorting by this pref determines order) 2. (required) Move the relevant portions of code to gtkmm, probably refactoring along the way. 3. (required) Implement a drag-and-drop customization interface ("Customize Interface" item in Edit), using the Gtk::Toolbar class. 4. (bonus) Work on a preliminary architecture to allow extensions to define custom toolbar buttons. 5. (bonus) Allow grouping toolbar buttons into a compound button like the New button in OpenOffice or Back/Forward in Firefox I would like to know: a) Whether it is doable in the GSoC timeframe, b) Where is the code that creates & manages the tool buttons? I need a further look at it before I decide. Obviously it's not in tools-switch.cpp. Is it dispersed among the event context GObjects? Regards, Krzysztof (Chris) Kosiński -- View this message in context: http://www.nabble.com/GSoC%3A-Customizable-toolbars-tp16429222p16429222.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

1 1

Vote Count
by Aaron Spike 06 Apr '08

06 Apr '08

I'd like to thank all of our candidates for their willingness to serve on the committee. And I would like to thank everyone who voted. The results of our recent vote: 7 - Bulia Byak 6 - Peter Moulder 3 - Johan Engelen -- Aaron Spike

5 4

Re: [Inkscape-devel] Problem with include files seeking
by Bob Jamison 04 Apr '08

04 Apr '08

(trouble with my mail. sorry if there are duplicates) No problem. We had a problem similar to this a few weeks ago. A file needed to include <dirent.h>, but for some unknown reason, Perl has a file with the same name. Yeah, this probably should be changed eventually. svn move or rename does it nicely. You don't need to delete and add again with the new name like on CVS. But no hurry! :-) I did make buildtool a bit smarter, and added an Ant-like <filelist> tag similar to <fileset>. So for now, we can just use the new <excludeinc> subtag of <cc> to hide that directory from the includes. So people should svn up and g++ buildtool.cpp -o btool.exe again. bob > >A simple fix would be to rename all files again to paramfloat.h etc. I don't know what the cause is, because the Inkscape src tree is added after the libraries include dirs. >In any case, I tried looking into buildtool.cpp to make a quick fix but I do not yet understand how everything works; it is more intricate than I thought. Don't want to force you into changing buildtool, because we might be moving to cmake soon (it seems to be working for 80% on windows now). > >I don't have time now to do the renaming though, and probably won't have internet on my own computer during the weekend..., so I hope somebody else can do the fix. > >Johan

4 3

Re: [Inkscape-devel] Inkscape Font Sizes
by Guillermo Espertino 04 Apr '08

04 Apr '08

Quick and dirty workaround: multiply the desired size by 1.25 For instance: 10 pt type = 12.5 px The explaination of this is that svg uses a resolution of 90 dpi for its pixel size as default. Postscript type units are 72 dpi. 90/72=1.25 Anyway, as I expressed before, inkscape is being used by designers who work for print as well as for screen. Typographic point size of 1/72" is sort of "industry standard" for print, and most of the applications using type for that output use that unit. So Inkscape needs, at least, a unit selector in the type dialog asap. Gez.

3 3

SVG Fonts
by Felipe Sanches 04 Apr '08

04 Apr '08

I will apply for SoC on SVG Fonts implementation. My task will be basic SVG Fonts support (i.e. reading of xml attributes, proper rendering and editing). I imagine that there are some extra stuff that could be done but would not necesarily be part of my task on SoC. I could work on those after completing the basic SVG Fonts support. I am starting this thread to discuss SVG Fonts related wished features. I will choose among these, which ones I think make sense to add to my SoC application and which I consider extra work to be done after SoC. one idea (probably to be implemented after SoC): Since SVG Fonts actually work as an alternative kind of font file (a font can be saved as .svg and then used by other SVG drawings) inkscape could have a font editing UI. It could have import scripts to load TrueType fonts and export them as SVG Fonts and vice-versa. I could also do it for other font types. One issue is in the exporters because obviously not everything SVG is capable of doing is supported by TrueType, or other font formats. So, we would commonly have to deal with glyph degradation when exporting fonts. Felipe Sanches ("JucaBlues" on irc)

9 13

Fwd: Launchpad 1.2.3 - mailing lists and more!]
by Bryce Harrington 04 Apr '08

04 Apr '08

----- Forwarded message from Matthew Revell <matthew.revell@...1798...> ----- Date: Fri, 28 Mar 2008 12:03:54 +0000 From: Matthew Revell <matthew.revell@...1798...> To: warthogs <warthogs@...1799...> Subject: Launchpad 1.2.3 - mailing lists, up to six plural forms for translations and more! X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,EMPTY_MESSAGE autolearn=no version=3.2.4 We're proud to announce a much requested new feature as part of Launchpad 1.2.3: mailing lists in Launchpad! If you run a team in Launchpad, you can request a mailing list straight away on your team's overview page. Once the list is active, each team member will have the option to subscribe. If you don't yet run a team but you'd like to create a mailing list that wouldn't be covered by an existing team, create a new team at https://launchpad.net/people/+newteam and then request a list. There's more in our guide: https://help.launchpad.net/ListHelp And there's plenty more going on in this release, including: * Translations can now have up to six plural forms. * Each project's files are now available to download from its overview page. * You can search for PPAs by name and keywords. * We've revamped branch listing pages to give you quicker access to commit messages and author information. As with all new software, there may still be some bugs in this new release. If you come across something that looks like a bug, please report it at: https://bugs.launchpad.net/launchpad/+filebug Read on for the full release report. General Launchpad =============== * Mailing lists are now available through Launchpad! Each Launchpad team can have its own mailing list that's open to team members and has a public archive. See our guide for more on creating a list for your team: https://help.launchpad.net/ListHelp * When you register a release of your project, you can publish files for download from Launchpad, such as code tarballs and installers. The files for your latest release are now shown on your project's home page. Downloadable files are also now available via http, as well https. This is useful if you're using wget or other download tools but don't have SSL libraries installed. (Bugs 174186 and 139052) * The CSV export of meeting attendees now includes an IRC nick for each person, provided they have at least one nick registered in their Launchpad profile. (Bug 156759) * Launchpad page footers now show you which Launchpad release you're using. https://help.launchpad.net/LaunchpadReleases Package Management and PPAs (Soyuz) =============================== * PPA searches now allow you to find a package by its name or words in its description. (Bug 126870) * Launchpad automatically deletes source files and binaries from your PPA when they are superseded by a new version of the package. In some circumstances, a superseded file may not be deleted automatically. You can now manually delete them. (Bug 191892) * Some binaries with a large number of files were failing to upload, despite the packages building successfully. We traced this to a bug in python-apt, which has now been fixed. (Bug 192713) * You can now list PPAs according to their Ubuntu release. (Bug 186106) * Distribution source package publication overview pages now show the package's component. For example: https://launchpad.net/ubuntu/+source/abiword (Bug 141540) Code Hosting =========== * We've given branch listing pages a major overhaul! The "Last commit" column now shows revision number, time since commit, the revision author (hyperlinked to the Launchpad person, if known) and the start of the commit message. Hover your mouse over the commit message fragment to see the full message. See https://code.launchpad.net/~bzr/+branches for an example. * The option to delete a branch is now always shown. If you try to delete a branch that isn't deletable, Launchpad will tell you why you can't. (Bug 133988) * You can now mark your project as officially using Launchpad Code Hosting. This is particularly useful to show that your project hosts its trunk and stable branches on Launchpad and also that you'll act on branches that are marked for merging into one of your official lines of development. (Bug #78418) * When you register a branch in Launchpad, you can write a summary of the branch's purpose etc. Previously, you could also register a home page URL for the branch. We've now removed the home page URL from branches, as all URLs in the summary are automatically hyperlinked and are more useful as you can put the URL in context. If you've recorded a home page URL for a branch, this will be automatically moved to your branch's text summary. * Launchpad now uses Bazaar 1.3. You can find out more about Bazaar 1.3 at https://launchpad.net/bzr/1.3/1.3/ Bug Tracker ========== * When you mark a bug as affecting a project that uses a bug tracker other than Launchpad, you can now record an email address to which you've sent the bug report. (Bug 201782) * As of last month's release, you can attach files to a bug report by email. This month, we've improved the way it works, based on your feedback: inline attachments are now accepted (bug 194601), bug notifications now tell you when someone has attached a file to a bug you're interested in (bug 195664) and the contents of attachments are no longer quoted in a comment (bug 196425). * Bug notification emails now state the bug's tags in a new X-Launchpad-Bug-Tags header. Each tag is separated by a space. For example: X-Launchpad-Bug-Tags: tag1 tag2 tag3. (Bug 138696) * The latest-bugs.atom feed is now served in the correct order. (Bug 182822) Translations ========== * Translations can now use up to six plural forms. This is particularly useful for translators working in Arabic but it's also good news for translators in other languages that use more than four plural forms. (Bug 189890) * We now have a "project cloud" on Launchpad Translations' home page, showing a selection of the projects that use Translations. Each project's level of activity is represented by text size and weight. (Bug 103186) * Making a request for a large translations export is now faster! (Bug 160308) * Launchpad sometimes failed to update the "Packaged" versions of translations when new upstream or distribution files were imported. The effect was that some of the "Packaged" translations shown in the UI were outdated. We've fixed this and from now on new uploads will update the "Packaged" translations correctly. (Bug 200499) More about Launchpad releases ======================== You can now find this and previous Launchpad release announcements at the new home for all information about Launchpad releases: https://help.launchpad.net/LaunchpadReleases -- Matthew Revell - Launchpad and Bazaar rock! Join us in #launchpad and #bzr on irc.freenode.net -- warthogs mailing list warthogs@...1799... https://lists.ubuntu.com/mailman/listinfo/warthogs ----- End forwarded message -----

4 4

Problem with include files seeking
by unknown＠example.com 04 Apr '08

04 Apr '08

SVN rev 19182 broke building on windows. Because it adds 'src/extension/param/float.h' which is apparently found first by the compiler instead of the correct <float.h>. On windows, the whole inkscape src tree is added to the include path (which is why sometimes windows edits break linux build). I think this is wrong and not necessary either. Ishmal, can you change the buildtool such that it only adds "." and "src" to the include path instead of the whole src tree? See attached file for details about what goes wrong. Thanks, Johan

2 2

Win32 libs
by Bob Jamison 04 Apr '08

04 Apr '08

I uploaded another lib bundle. This should have all of the fixes from the last two uploads (with Adrian & Rygles's fixes), and mine, together finally (I had some time). So I suggest that people download this one. http://inkscape.modevia.com/win32libs/devlibs-2.12-080403.7z bob

2 1

Last call for LugRadio live in San Francisco
by Jon A. Cruz 04 Apr '08

04 Apr '08

Hi, This is a final call to see if anyone else would like to be on the list to get into LugRadio live with Inkscape and hang out some at our booth there. They need the final list of names, so speak up if you might be interested. Thanks.

1 0

Alert of missing X11 on OS X?
by Jonatan Liljedahl 04 Apr '08

04 Apr '08

Hi all, this is actually not directly related to Inkscape but to the Mac OS X .app launcher, which I have borrowed for use in my own project (http://kymatica.com/algoscore). But this might be a bug that affects Inkscape users too: I see in ScriptExec/main.c that it is supposed to show an error dialog if X11 was not found. This doesn't seem to be working, it just says "unexpected termination" or similar and crashes. I wonder about these lines: // custom carbon events #define kEventClassRedFatalAlert 911 #define kEventKindX11Failed 911 #define kEventKindFCCacheFailed 912 I know nothing about Carbon or other OS X stuff, but should the first two really be the same numbers? Unfortunately I don't have access to a Mac myself to investigate this. -- /Jonatan [ http://kymatica.com ]

3 2

CIip Path ID collision
by Jason Merrill 03 Apr '08

03 Apr '08

I've got two different graphs, created in matlab and exported to svg using plot2svg[1]. When I try to import both of them into a single document, some sets of points in the second graphic don't show up. I've tracked the problem down to a clip path id collision. Both files define clip paths with the same ids, so when the second file is imported, its clip path url's point to clip paths from the first file. Is there any kind of workaround for this sort of thing? Is this a bug? Shouldn't inkscape check IDs to make sure there aren't any collisions when importing files? 1 http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=74…

2 1

Re: [Inkscape-devel] GSOC 2008 / Technical Drawing in Inkscape
by Jed Frechette 03 Apr '08

03 Apr '08

On Mon, 31 Mar 2008 J.B.C.Engelen@...1578... wrote > On Monday 31 March 2008 Diederik van Lierop wrote: > > Indeed, it should be indicated somewhere which snap mode is > > active. I'd prefer to go the status bar route though, because > > I don't think it's important enough to display it near the > > cursor. > > But it would be nice to temporary show next to the cursor what type of snap > happened! ;) +1 Even on a medium size monitor I may be drawing 30 cm away from the status bar. Looking back and forth almost inevitably means moving the mouse slightly which in congested areas, where this would be most useful, is likely to change the snap target. Best, -- Jed Frechette http://jdfrechette.alturl.com 4011 Dead, 29314 Wounded

3 3

svg elliptic toy improvement
by Marco 03 Apr '08

03 Apr '08

A new release of the svg elliptic toy is available on the lib2geom svn repository (svg-elliptic-arc-toy.cpp). I put the SVGEllipticalArc class in a separate file (src/svg-elliptical-arc.h). Now you can control interactively through 3 sliders the x-ray length, the y-ray length and the x-axis rotation angle. Moreover there are 2 toggle buttons for swithing on/off the the large-arc and the sweep flags. Finally instead of the two circles, now the two valid ellipse supports for the arc are drawn. Btw I've some issue with cmake because it doesn't find any ragel or rlcodegen command (they are specified in the CMakeList.txt file under the src folder ). Usually I solve the problem commenting out the related lines but this is becoming a bit annoying to manage everytime I need to commit my changes. Another issue regards the svg-path-parser.cpp file, because I need to change the line: #include <glib.h> with: #include <glib-2.0/glib.h> but problably this is due to the fact that we're using different linux distro. (I use mandriva 2008) Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

2 1

Any other Inkscapers going to OSCON 2008?
by unknown＠example.com 03 Apr '08

03 Apr '08

I'll be going to the conference this year, and if any other Inkscape folks who are going want to split a room at one of the conference hotels, let me know so that we can start making plans. Also, any interest in an Inkscape BoF there? Thanks, John

1 0

GPLv3 or later
by Felipe Sanches 03 Apr '08

03 Apr '08

I know that software licensing is an eternal issue (at least until property of ideas is (eventually) abolished). I have been studying copyright law and related stuff for some time. I know that changing the license used depends on tracking people that contributed to the codebase and that is a very hard task on large projects. Especially when people come and go and then get impossible to be contacted. That is why I would like to make a public statement here making it clear that I allow the use of later versions of the GPL on any code licensed under GPLv2 that I have ever contributed to Inkscape in the past. On new code I plan to say it explicitly on the headers of sourcecode files. Of course, the effective switch to "GPLv3 or later" versions of the license will depend on others also making this public statement. So I encourage other developers to make it in the hope that we could eventually switch the project to "GPLv3 or later". I know it is difficult to achieve, but I am trying to make the first step. Those who agree, please say so. Felipe C. da S. Sanches (JucaBlues)

2 2

Moving towards 0.46.1
by rygle 03 Apr '08

03 Apr '08

Hi, I know that 0.46 is only recently out the door, and many of us need a rest, and Bryce is getting married (congrats!) but I'm wondering whether we should start thinking about a 0.46.1 release somewhere around 1-3 months? I'm also thinking about a list of new features, and whether we should get them out for 0.46.1 or 0.47? Many new features are there in trunk, or ready to be put in and tested. Other things really need to be fixed, but didn't get priority for 0.46 because they weren't showstoppers. If we come up with some plan, and a rough date, we can hopefully just chip away at it. Anyway, this may be a bit win32 centric, since that's what I've been working with most, but here's some thoughts. Please balance this out for Mac and Linux... 0.46.1 definites: All Platforms: * Make sure all PDF import/export problems are sorted, mainly text orientation - LP 211065, 189432 * Other PDF/PS/EPS export issues - see http://www.nabble.com/sorting-out-PS-EPS-PDF-export-mess-td16060378.html * PDF import - spaces removed in font names - LP 179589 Linux: * - ?? Mac: * Halley said "under OSX at least, but likely any platform; if you're using -z on the command line, Gtk still complains loudly about not finding the display. Just clutters up the output when scripting things outside the gui." Win32: * Native Dialogues - already in trunk and seem stable * Printing enhancements - fix blurs - LP#205732, fix masks * JH's command line wrapper - http://kaioa.com/node/63 * Installer issues - uninstall (LP 211070), language fixes (see http://www.nabble.com/Inkscape-0.46-Win32-Released-td16415387.html) * Use pythonw.exe not python.exe - get rid of DOS popups - http://www.nabble.com/python.exe-or-pythonw.exe-td15954073.html * Win32? - Use clipboard patch to intergrate with O/S clipboard - already working across GTK+ apps (Gimp). * Win32 - Include uniconverter in libs for CDR and other import 0.46.1 possibles: All: * Calligraphic presets - LP 71255 and http://www.nabble.com/Calligraphic-presets-td16034028.html * Mentalguy's No filters view mode - http://www.nabble.com/NEW%3A-%22No-Filters%22-view-mode-td16391857.html * Crash when creating grid after duplicate window close - LP 183621 - pretty rare scenario * Export to OpenClipart - if not already fixed - Includes LP 179452 Linux: * ?? Mac: * ?? * Win32 - Cairo - use upcoming stable cairo 1.6 (currently Cairo RC - 1.5.15) * Win32 - Colour management - http://www.nabble.com/cms-on-windows-td16011013.html * Win32 - Import from OpenClipart -- View this message in context: http://www.nabble.com/Moving-towards-0.46.1-tp16460360p16460360.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

4 5

Vote while you still can!
by Aaron Spike 03 Apr '08

03 Apr '08

Attention individuals listed in AUTHORS, your time to vote is running out. Voting closes on Friday, April 4th. You may vote on this list or by email to aaron@...1928... A list of AUTHORS can be found at: http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/AUTHORS?… Non-AUTHORS if you see any AUTHORS please remind them to vote. :-) The nominees for committee member are: Peter Moulder Bulia Byak Johan Engelen Thanks for your vote! Aaron Spine

1 0

Svn problem
by Bob Jamison 03 Apr '08

03 Apr '08

This morning, when doing an svn up, almost every source file was updated, and was converted to DOS. What gives? And how do I revert this? Source files' formats should remain untouched by the SCM.

5 6