April 2006 - Inkscape Devel - Inkscape Mailman

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

Re: [Inkscape-devel] Would a translator mailing list be an appropriate tool ?
by Martin Owens 26 Apr '06

26 Apr '06

I would recommend English British as the default English setting, it is used by Europe, Africa, Middle East, China, India, Australia, South East Asia and Canada vs US English which is used by USA, parts of south America and Japan. It's important to standardise on the variation which most of the world have standardised on, and I do feel that because most developers are in the USA they will favour a us-English default (such is the problem with all software). I also agree that neutral word variations should be used were possible. Best Regards, Martin Owens On Wed, 26 Apr 2006 17:42:32 +0200 , "Josef Vybiral" <newsgroups@...1135...> wrote: >On Tue, 25 Apr 2006 22:32:04 +0200, Alan Horkan <horkana@...44...> >wrote: > >> >> On Tue, 25 Apr 2006, Josef Vybiral wrote: >> >>> I agree that inkscape-translators list would be helpful. It would be >>> good to discuss about meanings of translated strings, >> >> A translators list is probably a good idea but it is important that >> translators tell the developers about difficult to translate strings >> rather than doing things the hard way. >> >> Many people use English as a second language and also use software >> through >> English so it is very important the English be crystal clear. >> (Differences between British and American should be avoided if a suitalbe >> "interenational english" phrase works for both, and so only smaller >> spelling issues like color/colour should ever need to be translated.) >> Feedback from translators can be very important. > >Yes, if the string in English is clear then the translation is perfect and >simple(in the most of cases). This kind of feedback and discussions about >used terms would be good to clarify the UI even for users without any >graphics experience before. > >I've said "in the most of cases" in previous paragraph because there are >exceptions. E.g. "Inset/Outset" terms are examples of clear terms in >english but there were some problems to find suitable translation for(in >Czech). After consultation with czech GIMP translator we finally decided >to use terms which are suitable. This kind of discussion with another >translators could be helpful, at least to see what terms/synonyms they >have used. ("CW" and "CCW" terms are similar example where the discussion >was helpful ;) ) > > cheers > > cornelius > >-- >Josef Vybíral a.k.a. cornelius >-------------------------------- >gimp.cz's second editor in chief >web: http://cornelius.gimp.cz >mail: cornelius@...1135... >jabber: cornelius@...1136... > > >------------------------------------------------------- >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 > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

2 1

Re: [Inkscape-devel] Re: [Inkscape-user] saving palette settings and random tree positining
by Martin Owens 26 Apr '06

26 Apr '06

It's better to have DOM hooks or SVG filter hooks, I'd like SVG DOM hooks for Perl, there is a way to provide a module writen in C++ or C which acts like a perl module, I'm sure there are similar things for Python. On Wed, 26 Apr 2006 17:39:03 -0400 , MenTaLguY <mental@...3...> wrote: >On Wed, 26 Apr 2006 16:36:04 -0400, "bulia byak" <buliabyak@...400...> wrote: >> On 4/26/06, Aaron Spike <aaron@...749...> wrote: >>> I hope we can hookup python extensions with access to inkscape internals >>> before this is necessary. Starting to build to much complexity, IMHO. >> >> Not all extensions need or want to access Inkscape internals. The big >> advantage of the current implementation is exactly this - that any >> developer knowing only Python and SVG can write an extension without >> any Inkscape knowledge. So I don't want the current system to be >> completely replaced by the new "internalized" one; I'd prefer to have >> them both at the same time. > >It's also worth noting that anything tied to the Inkscape internals too directly is going to break as the codebase continues to change and be improved. > >-mental > > > >------------------------------------------------------- >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&kid0709&bid&3057&dat1642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0

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

26 Apr '06

On 4/26/06, Aaron Spike <aaron@...749...> wrote: > I hope we can hookup python extensions with access to inkscape internals > before this is necessary. Starting to build to much complexity, IMHO. Not all extensions need or want to access Inkscape internals. The big advantage of the current implementation is exactly this - that any developer knowing only Python and SVG can write an extension without any Inkscape knowledge. So I don't want the current system to be completely replaced by the new "internalized" one; I'd prefer to have them both at the same time. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1