- Inkscape Devel - Inkscape Mailman

Rotation center handle
by Tavmjong Bah 28 Apr '06

28 Apr '06

Hi, The Rotation center handle is currently only visible and movable when the Selection tool is active and in Skewing/Rotating mode. This made perfect sense when only rotating and skewing via dragging the rotating and skewing handles utilized the Rotation center handle. Now that the rotating and skewing via the Transform dialog and via the keyboard also utilize the handle it seems to me that the handle should be visible and movable anytime an object or group of objects is selected. BTW, there seems to be bug in updating the handle when shift-clicking on it to restore it to the center of an object. The XML editor shows the change but the old position is still displayed and used for rotations until the object is unselected and reselected. (Checked with today's SVN.) Tav

2 1

bless
by MISS BLESSING PAUL 28 Apr '06

28 Apr '06

J'ai une nouvelle adresse mailVous pouvez maintenant m'écrire à : b_102005@...48... Dear It is my pleasure to acquaint you with this proposal for The purpose of investment in your company.I am Miss Blessing Paul the only daughter of late George Paul from Sierra Leone. My late father was a Gold and Diamond merchant based in Freetown Sierra-Leone. As a result of the political instability of Sierra-Leone, my late father came to Cotonou Benin republic with the sum of USD12,500,000.000 (US$12.5m) which he deposited in a Financial and Security Institution here in Cotonou Benin Republic West Africa for security reasons I am here seeking for an avenue to transfer this money to a reliable and trustworthy individual for investment programmes. I am here as a refugee because of the political crisis in my Country Sierra Leone. Please I would offer you 20% of the total sum of USD12.5m for your assistance. Please I need to transfer this money urgently because delay would not help at all and I need to relocate based on the political instability in this sub-region, to enable me continue my education because i was medical student before the sudden death of my father.Please Your immediate response would be appreciated. Best regards Miss blessing Paul. - MISS BLESSING PAUL

1 0

Translation impacted by file rename?
by Jon A. Cruz 28 Apr '06

28 Apr '06

I was wondering if the translations are going to be negatively impacted by file renaming. Anyone know? Here's the outstanding change I have to POTFILES.in to get 'make check' happy again: Index: po/POTFILES.in =================================================================== --- po/POTFILES.in (revision 11430) +++ po/POTFILES.in (working copy) @@ -172,7 +172,6 @@ src/node-context.cpp src/nodepath.cpp src/object-edit.cpp -src/object-ui.cpp src/path-chemistry.cpp src/pen-context.cpp src/pencil-context.cpp @@ -252,6 +251,7 @@ src/tools-switch.cpp src/trace/potrace/inkscape-potrace.cpp src/trace/trace.cpp +src/ui/context-menu.cpp src/ui/dialog/aboutbox.cpp src/ui/dialog/align-and-distribute.cpp src/ui/dialog/document-metadata.cpp

1 0

translation lost in save
by Aaron Spike 28 Apr '06

28 Apr '06

It seems that the translation portion of my Fit Page to Selection function doesn't properly weather a save and open cycle. Can anyone offer suggestions as to how I might fix that? I suppose I need to translate each child of the document instead of translating the doc root. Yes? Aaron Spike

1 0

ok, sorry that's only a idea
by Jairo Gonzalez 27 Apr '06

27 Apr '06

I know that the way to do shadows is using blur filter (in my graphics I do shadows exporting a png of the figure and I use gimp to make the blur effect) I only try to do a shadow using the tools available in inkscape today, for this reason I thing in the degrade attribute, it's a bad idea, sorry about that. the next time that I will write something here will be a good idea. I thing in use the border too, because y don't know how to do inside shadow. its all thanks

2 2

RE: [Inkscape-devel] Re: vectorsection vs native PDF?
by Charles Moir 27 Apr '06

27 Apr '06

These are a few reasons why, from the outside, I think it makes sense for Inkscape to adopt UberConverter (UC) and not to 'hard-wire' each new filter, such as PDF export, directly into Inkscape. * If you write ONE filter to talk to uber-converter then you get ALL file types it supports. * Each new filter type that's added to UberConverter, Inkscape will be able to use with NO additional work * Each new filter type that UC supports benefits at least two open source projects, and possibly more. So immediately it avoids re-inventing the wheel and duplicating effort (surely one of the core principles of FOSS) * Developers can write new import / export filters without having to know anything about the internal code of Inkscape or Xara. It's thus, hopefully, considerably easier to write new filters for Inkscape and Xara. In a nutshell UC works by having one master 'uber-format' that's a superset, as much as possible, of all common vector standards. This is the hub-format. You write one filter to convert to and from that format. UC then has lots of separate independent plug-in filters to convert to and from this hub format. So now if you add say, a DXF converter into the hub, all others types can be converted to and from DXF. The goal is to have, as much as possible, a lossless conversion between types and to retain important meta information such as group structure. No other platform has an agreed open standard for vector conversion (commercial considerations make it difficult to imagine), but the benefit to the FOSS platform of having one solution for all products wanting vector conversion seems to be very considerable. And finally, we (Xara and Inkscape) have spoken about ways to cooperate, to avoid competing, and it seems this is a classic example where with a little planning we can do just that: cooperate, not compete. We all have limited developer resources and so immediately the benefits of our two projects pooling to solve the same problem once strikes me as a huge gain. And if a third project, say Scribus, started to use UC, then for each filter, or even each little minor improvement, three major projects get the immediate benefit. A 300% return on your developer investment. We both require PDF export. Recently there's been discussion about ODG support and EMF/WMF. These are important vector standard file formats. It would obviously benefit both our projects to have EPS support, CorelDRAW CDR and CMX support, Adobe Illustrator - I could go on. Let's solve the problem once. Now having said that it's early days for UC. It's a mostly a plan, not a fully functioning reality. But right now we're putting a lot of effort into integrating UC into XaraLX, and we hope within a few weeks to have this working and demonstrating the first UC filter (Xar <-> SVG). And yes this means if you guys integrate this you get the ability to read and write our .xar files. So I think Eric's project deserves Inkscape's support. It even seems a good candidate for SoC support since it's an independent project that directly benefits multiple other projects. Charles > -----Original Message----- > From: inkscape-devel-admin(a)lists.sourceforge.net > [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf > Of Eric Wilhelm > Sent: 26 April 2006 22:59 > To: inkscape-devel(a)lists.sourceforge.net > Cc: bulia byak > Subject: [Inkscape-devel] Re: vectorsection vs native PDF? > > # from bulia byak > # on Friday 14 April 2006 05:53 pm: > > >- Implement > > > http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know > >of UberConverter, but PDF is the most important interchange > format so > >we should better support it natively) > > bulia, can you explain why this needs to be native? Short of > animation and the exact placement of things like transforms > in the DOM (if pdf would even allow that) the Chromista hub > should express enough of the SVG structure to round-trip PDF > conversions as well as anything native. > > If it gets implemented natively in inkscape, I would just use > that as a hub attached to chromista to get things like xar -> > pdf, but going through svg is going to be lossy from that perspective. > > Thanks, > Eric > -- > Peer's Law: The solution to the problem changes the problem. > --------------------------------------------------- > http://scratchcomputing.com > --------------------------------------------------- > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web > services, security? > Get stuff done quickly with pre-integrated technology to make > your job easier > Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& > dat=121642 > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >

6 8

s/UberConverter/VectorSection/
by Eric Wilhelm 27 Apr '06

27 Apr '06

Hi all, "The UberConverter" is finally moving out of the "working title" stage. The new name is VectorSection, which may or may not be referred to as VectorX, VeX, or vx. http://scratchcomputing.com/projects/vectorsection/ Also a few updates to the page and a link to the install instructions. More to come. --Eric -- So malloc calls a timeout and starts rummaging around the free chain, sorting things out, and merging adjacent small free blocks into larger blocks. This takes 3 1/2 days. --Joel Spolsky --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------

3 3

Re: [Inkscape-devel] path effect grammar
by Martin Owens 27 Apr '06

27 Apr '06

attributes are a folly for data, they confuise too much. I'm glad my xml in programming never has them outside ids. On Thu, 27 Apr 2006 11:05:42 -0400 , MenTaLguY <mental@...3...> wrote: >On Wed, 2006-04-26 at 22:40 -0300, bulia byak wrote: >> SVG paths use attribute grammar and work just fine. >> >> Why? Because they are flat. >> >> XML is good for hierarchical structures. I do not foresee any >> hierarchy in a chain of sequentially applied effects, each with its >> own parameters. > >That was just one example; XML nodes have other desirable properties >like being addressable via URIs (I'm thinking mostly local references at >the moment, like #id). > >I need to check, but if I remember correctly some of the original SVG >filter and vector effect proposals used flat attributes as you propose, >but obviously they decided not to do that. Our path effects have >similar design considerations, so I'd rather not repeat old mistakes. > >Among other things, non-sequential composition of filters/effects of >seem to be frequently desired for these sorts of things once they come >into widespread use (e.g. many interesting uses of SVG filters involve >trees rather than linear chains). I'd rather not close that door early >by making the filter stuff non-addressable in the document. > >> So, I remain opposed to the approach involving non-SVG child elements. > >I'm not fond of adding children to <svg:path> either, actually. > >I'd almost like to see something like: > ><svg:svg> > ... > <defs> > ... > <inkscape:path-effect xlink:href="x-inkscape-plugin:org.inkscape.effect.foo" id="path-effect2"> > <inkscape:param name="blah" value="foo" /> > </inkscape:path-effect> > ... > </defs> > ... > <svg:path ... inkscape:path-effects="#path-effect2 ..." /> > ... ></svg:svg> > >This is just a rough idea, though. I'm going to have a look at how SVG >vector effects are done; the architecture is very similar in some >respects; I think we basically want to mirror that approach. > >> IMO it's a case of overengineering, and given the general fragility of >> our XML tree, it's much more trouble than it's worth. > >Fragility? Howso? > >-mental -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

inkscape history/timeline
by Eric Wilhelm 27 Apr '06

27 Apr '06

Hi all, Cornelius asked on IRC how long the feature freeze had been prior to 0.43, which got me thinking that it would be really useful to have a page on the wiki with a year-by-year history. I think this could be useful both as an internal reference and for other open-source projects to see how inkscape has progressed. I've bootstrapped this page with what I can deduce from the sourceforge release listings. http://wiki.inkscape.org/wiki/index.php/InkscapeHistory If you have memories of particular milestones, it would be great to see a year-by-year timeline, maybe even links to progressive screenshots. Thanks, Eric -- Atavism n: The recurrence of any peculiarity or disease of an ancestor in a subsequent generation, usually due to genetic recombination. --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------

4 4

Re: [Inkscape-user] saving palette settings and random tree positining
by bulia byak 27 Apr '06

27 Apr '06

On 4/26/06, Gijsbert Stoet <stoet@...1250...> wrote: > I really like the new palette at the bottom of my screen. But..., I > noticed that Inkscape does not remember my Palette settings after I > have quit Inkscape. Is that intentional? Jon, is it too difficult to store this in prefs? Another question from me: What if we reduce the height of the palette a bit? Since it's not yet resizeable, we need to choose a good default, and right now IMHO it's too high. > Another question: Why does the random tree (as in effects) always > appear (at least in my latest CVS inkscape version) at the top left > corner *above* the page boundaries, instead of the center of the > page. The latter would IMO be more user friendly. To _really_ fix this, it should be ideally inserted into your current view, appropriately zoomed. Ted: can you tell me how difficult it will be to add several new command line parameters passed to the effects: - the bbox of the selection - the bbox of the visible part of the canvas - the current layer Even if currently effects don't use this, it will be very useful for effect authors, and can potentially make all effects much more usable. > Finally: When I select to fill an object with a radial gradient, > Inkscape always selects to have the full transparency at the borders > of the object and the none-transparency at the center of the object. > That is fine, but often I just need to have it the other way around. > What I do it manually edit the radial gradient to get it my way. It > there a 'one-click' way to quickly reverse the gradient? Yes, Shift+R in Gradient tool. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 3