- Inkscape Devel - Inkscape Mailman

Ohloh Widgets
by Joel Holdsworth 20 Mar '08

20 Mar '08

Hi All, I don't know if any of you have played around with ohloh.net at all - I have; it's kinda cool. Anyway, for those that don't know, it indexes source control repositories of open source projects, so as to produce interesting metrics of the total work done on whole projects, and the contributions made by individual developers. So inkscape has 45 developers, 793034 lines of code, which would have cost an estimated 220 person years to produce at cost $12,112,544. Cool huh? Ohloh has a cool feature where you can put a little badge on the project home page that tells people this info: http://www.ohloh.net/projects/69/widgets Some projects have used this just for the hell of it, others have used it as a way of encouraging people to donate e.g. wine-door.org! What do you think? All the best Joel

3 4

GSoC requirements / expectations
by Daniel Kraft 19 Mar '08

19 Mar '08

Hi, I'm interested in applying to GSoC for Inkscape this year. While I don't have much experience with graphics on the implementor's side so far, I'm interested in learning about this; thus Inkscape is an interesting project. Mostly the lib2geom-task sounds nice; do you have some more specific information, what would you expect from a student to take it on? Does programming experience suffice (well, I probably also have some basic understanding of linear algebra and/or other mathematical concepts which might be used there) to get one started, or should I already know something about Inkscape (more than as user) or computer graphics / 2d vector graphics? Thanks for your help and greetings from Austria, Daniel -- Done: Bar-Sam-Val-Wiz, Dwa-Elf-Hum-Orc, Cha-Law, Fem-Mal Underway: Ran-Gno-Neu-Fem To go: Arc-Cav-Hea-Kni-Mon-Pri-Rog-Tou

3 2

Fwd: sorting out PS/EPS/PDF export mess
by jiho 19 Mar '08

19 Mar '08

I guess Joshua's message was meant to be sent to the list. Begin forwarded message: > From: Joshua Facemyer / Impressus Art <faceman@...1574...> > jiho wrote: >> On 2008-March-17 , at 18:12 , J.B.C.Engelen@...1578... wrote: >>>> Subject: Re: [Inkscape-devel] sorting out PS/EPS/PDF export mess >>>> >>>> I agree completely with this. It makes sense to "save"/"save >>>> as" in svg format, and export anything else, since that's the >>>> only format Inkscape actually edits. >>>> >>>> BTW, is there a difference between "export" and "save a copy"? >>>> >>> I don't understand the difficulties with the current system. >>> Save = understood >>> Save as = save as different filename. Whatever filetype you want. >>> >> >> To me that's the issue: being able to save current drawing as >> whatever file type => be annoyed by the nag screen telling you to >> save it back as svg, and risk data loss if the nag screen is >> discarded. Why allow the user to shoot him/herself in the foot >> when there's an easy alternative? >> > I agree completely. It makes much more sense to have an export > function for all filetypes except those one would normally be able > to edit directly in Inkscape. This is how most apps implement the > save function, from my experience. Any other file format is usually > covered under the export function. > > I am always saving as pdf, trying to resave my document as an svg, > then wondering why in the world pdf isn't an export option - it's a > pain in the rear every time I save as pdf. >>> Save a copy = save as different filename but afterwards stay >>> working on current filename. Again, whatever the type. >>> >> >> This is OK. Just redundant with export. Since there's an export >> panel, that can stay open all the time, with lots of options >> already there, I was thinking that integrating all export under it >> would be the best UI. >> > I don't think it's redundant after Terry's explanation: >> Noooo. :-) "save a copy" is a common option in a lot of apps. for >> saving backups without changing file names. I.e. your file might be >> massive_project.svg, and you can use "save a copy" to save >> massive_project_a.svg, massive_project_b.svg, massive_project_c.svg >> etc. while you're working in case something goes wrong or you come to >> regret a design decision. So it's not necessarily related to >> export at >> all. I'd say leave it in. > That makes sense, and it's not confusing if it just does a one-time > save of the current file in it's current format (which, ideally, > would be Inkscape SVG by default, with plain SVG and compressed SVG > as alternates). Well, assuming SVG is also available as export (which it probably should if it can give you the possibility, as with other formats, to export only a part of current drawing) you could just export your work regularly and the result would be the same. One could even imagine having things such as special expressions in the export dialog name which would transform into unique characters e.g. massive_project_%n.svg which would give massive_project_1.svg then massive_project_2.svg and so on. (or you could take advantage of the text-based nature of svg and use a version control system but that's a whole other story ;) ) Bulia, are you already working on this or should we open a blueprint to summarize the ideas and opinions? JiHO --- http://jo.irisson.free.fr/

5 11

Re: [Inkscape-devel] Fwd: sorting out PS/EPS/PDF export mess
by Joshua Facemyer / Impressus Art 19 Mar '08

19 Mar '08

jiho wrote: > part of the point in having it into the export dialog is that: > 1/ it can be invoked with a keyboard shortcut already (and if the > export button can be focused by default it would make it possible to > create a backup by Shift-Control-E + Return) > 2/ the dialog can stay open at all time, so you can be just one click > away from a backup. Now it just needs to be gtkmmified and thinned a > little to fit with the docked ones. I'm going to argue for the shortcut, in part because the one for "Save a copy" is already there, and in part because the incremental copy one will save a lot of trouble (clicking or entering, switching focus - adds up if you do it a lot). And besides, the point of these was also to have preset options inputted to the export dialog so that they work painlessly, instead of changing all kinds of stuff for each type of copy-save or export you want to do. JF

7 8

LGM 3 inkscapers coordination
by Cédric GEMY 19 Mar '08

19 Mar '08

After Louis's Mail on Create List, i've been assigned to make a list of the people coming to LGM3, in Poland. People interested may send me a mail. If some people need help for paying travels, say also - where you come from - the average price of the travel please, do quick so that we can enter the last step ;) cheers pygmee

1 0

Inkscape stopped working one day
by Alexander Kane 19 Mar '08

19 Mar '08

I only got inkscape a month or so ago, I followed the simple instructions for compiling inkscape 0.45 for OSX. It worked fine (or as well as any program using X11, all flickery etc.) I didn't use it that much though. then a few weeks later I decided to boot up inkscape only to find that the icon appears on my dock, but it doesn't do anything. X11 doesn't launch, nothing happens. It doesn't seem to be working either, as it doesn't slow down the computer at all. Even if I open up x11 first inkscape still doesn't run. I've tried the irc channel but nobody there seems interested at all. If someone here could make a suggestion I'd be greatful. Alexander P.S. I did try reinstalling it, using Macports this time, with the same result. P.P.S It might have being during that period that I upgraded from 10.5.1 to 10.5.2 ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

2 1

Re: [Inkscape-devel] Anouncing New Extension: Alphabet Soup
by Joel Holdsworth 19 Mar '08

19 Mar '08

Hey... you responded - that's a very pleasant surprise. I thought that website was long dead! - still very impressive work! > Wow! This is super awesome! I've been meaning to implement something > like this for years! Thanks so much! It's especially awesome that > you've implemented it as an Inkscape plugin since that's my vector > editor of choice. That's always good to hear! > How do I get and use the extension? Did you mean to attach it to the > email? Yeah sorry, that e-mail was really directed at the rest of the inkscape devel people, so you'll find the extension in our SVN trunk. You can check out just the share/extensions/ subdir with a command like this: svn checkout https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/… extensions You just need to grab these files: share/extensions/render_alphabetsoup.inx share/extensions/render_alphabetsoup.py share/extensions/render_alphabetsoup_config.py and share/extensions/alphabet_soup/*.svg The extension will probably be released officially in v0.47 - the next release after the upcoming 0.46 and 0.46.1 builds. So it could be a little while before it becomes public. > The original alphabetsoup script *does* allow for totally random > generation, just use -g instead of -r: > > ./alphabetsoup.py -g "Hello World" Yes I saw that in the original code. I just havn't exposed that functionality to the user in this first attempt. Anyway, do feel free to give any comments, suggestions, code-mods etc. after all this is still your baby! Thanks again, Joel On Tue, 2008-03-18 at 16:49 -0700, Matt Chisholm wrote: > Wow! This is super awesome! I've been meaning to implement something > like this for years! Thanks so much! It's especially awesome that > you've implemented it as an Inkscape plugin since that's my vector > editor of choice. > > How do I get and use the extension? Did you mean to attach it to the > email? > > The original alphabetsoup script *does* allow for totally random > generation, just use -g instead of -r: > > ./alphabetsoup.py -g "Hello World" > > So you should be able to hook the plugin into that part of the > original code. > > -matt > > > On Mar 18 2008, 22:37, Joel Holdsworth wrote: > >Hi All, > > > >Thought you might all be interested to know that I've just submitted a > >new python extension: Alphabet Soup. Alphabet Soup is a vector/SVG > >derivative of Matt Chrisholm's orignal GPLed raster script (from here > >http://www.theory.org/artprojects/alphabetsoup/main.html ). > > > >In simple terms Alphabet Soup makes a soup out of your alphabet. Type a > >string into it, and it will render the characters of that string, but > >with the strokes and serifs etc all mixed up. This is all achieved by a > >set of rules which control how the algorithm combines together the > >pieces of the Computer Postmodern Font (<-- that's one of Matt jokes, > >get it??). Try it out - or see the attached SVG. Obviously this script's > >usefulness is quite limited, but it is sorta fun and creative - might > >help new users fall in love with inkscape. > > > >In a while I might roll out an extra function carried over from the > >Matt's original script, which allows unreadable characters to be > >generated completely randomly - rather than as variations of normal > >latin characters. This extra function when it comes will allow the > >script to make totally alien writing. > > > >All the best > >Joel > >

1 0

Pattern licenses
by Tavmjong Bah 18 Mar '08

18 Mar '08

Hi, I am very surprised to discover that three of the patterns Inkscape has included in the Fill and Stroke dialog are not public domain. The only way a user can see this is to look directly at the SVG content, either through a text editor or the XML Editor dialog. I think that this is going to create large scale violations of the licenses as the average user will have no idea that they are using licensed images. Here are the effected patterns: sand_bitmap: creative commons attribution old paint: creative commons attribution cloth bitmap: GFDL or CC Attribution ShareAlike Tav

2 2

Recent /src/bind check-ins
by Bob Jamison 18 Mar '08

18 Mar '08

Hi all, again. Sorry about the large check-ins in the bind/java directory recently. But a large portion of them are the "official" svg-dom Java interfaces from w3c.org. These are necessary for us to provide a compliant DOM interface for scripting and other things. But as soon as we discover what all interface files we need, they will be compiled and placed into a jar file and removed from the source tree. I'll probably be done stubbing out the org.inkscape.dom.svg.*Impl.java files by the end of the week. There are -hundreds- of files, but most are quite small. Those who know Java know that each public class needs its own file, regardless of how small it is. But some of the recent posters might be happy to know that the interfaces also include SMIL and DOM Events, which should simplify animations quite a bit. And collaboration, too. Anyone doing automake stuff for javac might want to comment it out for a few days, until bind/java/org/inkscape/dom/svg can compile cleanly. And note that although the binding will be done with Java, we don't expect anyone to actually write any Java code. Rather, this is just the glue so that we can run VM-hosted interpreters such as Jython, JRuby, and Rhino(JS). So... "Pardon our dust", but I promise that it will be cleaned up in a few days. Scripting will be fun, I promise. :-) bob

1 0

Re v 17915 fails VPATH build - patch
by Krzysztof Kosiński 18 Mar '08

18 Mar '08

Rev 17915 fails VPATH build, because the build instructions for the Java binding assume that srcdir = builddir. Here is a patch (just 1 line changed). Index: Makefile_insert =================================================================== --- Makefile_insert (revision 17915) +++ Makefile_insert (working copy) @@ -6,7 +6,7 @@ rm -f bind/libbind.a rm -f $(bind_libbind_a_OBJECTS) -bind_libbind_a_CPPFLAGS = -Ibind/javainc -Ibind/javainc/linux $(AM_CPPFLAGS) +bind_libbind_a_CPPFLAGS = -I$(srcdir)/bind/javainc -I$(srcdir)/bind/javainc/linux $(AM_CPPFLAGS) bind_libbind_a_SOURCES = \ bind/javabind.h \ Regards, Krzysztof Kosiński -- View this message in context: http://www.nabble.com/Rev-17915-fails-VPATH-build---patch-tp16092887p160928… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

5 9

Inkscape accepted for GSoC 2008
by Bryce Harrington 17 Mar '08

17 Mar '08

http://code.google.com/soc/2008/ Bryce

2 1

Inkscape 0.47 Development Plans
by Bryce Harrington 17 Mar '08

17 Mar '08

Hi all, With Inkscape 0.46 wrapping up, it's time to look forward to our next release, 0.47, and our plans for its development. When we started Inkscape, we began with a codebase with lots of potential but with some architectural limitations that we've never quite resolved. Inkscape has grown rapidly, especially thanks to Google's Summer of Code program. Unfortunately, while we've gained a lot of new features, it hasn't addressed the underlying issues - and in some cases has exposed new problems. Inkscape's also been extremely successful at gaining a lot of contributors, yet this comes with a price: Stylistic differences, accidental code duplication, unfinished code, obsoleted code, etc. What will the codebase cleanup work entail? The work will range from straightforward "grunt" work like making some simple code changes to all files in the codebase, to meatier work like abstracting widely used code into a more concise and powerful algorithm, to advanced work such as extracting distinct code into independent code packages. To boil this down into five high level objectives: 0. Complete some of the big architectural refactoring efforts 1. Reduce source code line count 2. Break useful code out into stand-alone libraries 3. Increase code stylistic consistency 4. Make the codebase more convenient to code in Now, architectural reworkings can often risk incur massive breakages since fundamental pieces of the code are being changed. In order to minimize this, I'd like to suggest the following principles: * Always keep the tree buildable * Do major refactorings in small steps * Hold code review parties with 2-3 others to brainstorm * Drop copied-in codebases in favor of external dependencies * Make sure every function you touch has some doxygen comments Further, this kind of work can go on indefinitely without a clear stopping point, so I think for this release we should use a schedule with a date-based stopping point. This will help everyone know how they should time their work. Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins Apr May Jun Jul 1 Completion of refactoring. Focus on Bug Fixing begins. Open 0.48 development tree early, for GSoC work. Aug Put out 0.47-pre releases. Sep Release 0.47. For reference, here are some key GSoC dates: May 26 GSoC work begins. Jul 14 GSoC midterm. First delivery of GSoC code Aug 18 GSoC work ends. This schedule permits us to focus exclusively on refactoring for several months, with a due date of July 1st to complete it. It uses a very early branch point, where we'll split into a stable branch for doing bug fix and release work, and a development branch for the GSoC students to use and for folks to continue right on with refactoring projects if they wish. Bryce

17 69

Matrix multiplication reversed?
by Jasper van de Gronde 17 Mar '08

17 Mar '08

I am attempting to eliminate some redundant types, at the moment I have just tried eliminating NRPoint and NRMatrix in favour of NR::Point and NR::Matrix (patch available soon, I'm currently double-checking it). While looking at the matrix multiplication as defined in nr-matrix.cpp it looks like the definition is reversed (compared to the usualy mathematical definition). That is: A*B=BA ... The reason I think it is reversed is simply that if C=A*B (with C, A and B NR::Matrix's), then C[0] is the dot product between the first column of A and the first row of B (and similarly for the other elements). Am I missing something or is it indeed reversed? And if it is, is there a reason for this?

3 6

IO extensions should accept Writers
by Krzysztof Kosiński 17 Mar '08

17 Mar '08

Hello I strongly believe Inkscape input and output extensions should accept Writers, not URIs. Currently much of Gnome-VFS boilerplate is duplicated between the extensions. If we used Writers instead of URIs: 1. The GnomeVFS code would be contained to a particular OutputStream, and could be easily replaced with GVFS once it's around. 2. Adding KIO support would be easy, just create a new OutputStream and use it. There could be a function that automatically creates the best OutputStream for a given platform. 3. Memory output ability - this is what I need for the clipboard work. 4. Windows-specific filename hacking could be contained to a particular OutputStream. Regards, Krzysztof (Chris) Kosiński -- View this message in context: http://www.nabble.com/IO-extensions-should-accept-Writers-tp16046549p160465… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 1

Re: [Inkscape-devel] DVCS again
by jiho 17 Mar '08

17 Mar '08

On 2008-March-14 , at 17:45 , Joel Holdsworth wrote: > I'm still a little uncertain about this. Git seems increasingly > popular, > and very powerful, it just doesn't seem very obvious to use for new > users. SVN is great at the moment, because there's a great GUI client > for windows (TortoiseSVN), and quite a good one for linux (RapidSVN). > Having easy source control clients seems like an easy way to get > people > involved. So I'm wondering: are there any good GUI clients for git, > mercurial or bazaar? you can see the previous message on forked thread about that ("DVCS again"). TortoiseHG and TortoiseBZR exists, TortoiseGIT does not. I don't know the status of the first two compared to TortoiseSVN. On linux there are apparently many clients for all three systems (from the look on the wiki's of each project) but it is difficult to assess their quality from just screenshots. I have not seen any file browser integration (i.e. tortoiseSVN like) for linux, which unfortunately would probably be the most useful thing to have (I read some stuff about nautilus plugins but never saw anything actually working). For OS X there's shell integration and a bunch of clients for SVN, not much for the rest. But most of them are not good enough to avoid the command line altogether, so I personally don't even use one. There is however integration with a nice text editor (textmate) for svn, git, and mercurial. nothing I can see for bazaar. I'm not sure how critical having a good GUI is to get new developers. To compile Inkscape you eventually have to go to the command line and type stuff so... I agree however that TortoiseSVN probably makes the life of existing windows developers easier. So has anyone tested TortoiseHG/BZR ? JiHO --- http://jo.irisson.free.fr/

3 2

Re: [Inkscape-devel] DVCS Again: end-of-line conversion
by jiho 17 Mar '08

17 Mar '08

On 2008-March-15 , at 08:09 , Peter Moulder wrote: > On Sat, Mar 15, 2008 at 12:21:47AM +0100, jiho wrote: >> I'm not sure there's really a need to continue counting points right >> now. It seems bazaar is the clear winner. > > I've been composing the below before the above was posted. > > Looking at > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, > there is one startling difference among git,hg,bzr: it is stated that > bzr cannot do end-of-line conversions, i.e. cannot adapt the end > of line characters for text files such that they match the end of line > style for the operating system under which it is used. > (Status: http://bazaar-vcs.org/LineEndings) > > I wonder how much of an issue this is; could it actually be fatal for > what is otherwise a very promising alternative? Let's look at how we > would address this issue if we were to choose bzr. OK, let's start counting again then. I removed mercurial since no one really stepped up to give advice on it. Right now it seems that both solution have different flaws. However git ones seems to be just a matter of changing habits (e.g. rely more on the command line, learn a few new commands), while on the other hand bazzar would be more enjoyable to use but has some more "deep" flaws (e.g. line endings and slowness). -- GIT ---------------------------- + faster: . local commits: <1s vs 4s . push a new branch: instantaneous vs 35 min + ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view + probably the fastest growing user base => many tools + TextMate bundle - git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit) - we would need to set up and administer this ourselves - revisions are indicated with SHA's rather than numbers - commands dissimilar to what we're used to with svn (e.g., no 'git update') - have to git add all modified files before committing them (or resort to a non specific commit -a) - no decent GUI (for windows?) -- BZR ---------------------------- + already integrated in launchpad http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.… . Associating branches to bugs . Associating branches to blueprints . Changes state of bugs in LP when committing in Bazaar . Web interface for creating branches quickly and easily + supports renames (could be considered a - by git users) + supports bundling changesets + tortoiseBZR + Fewer commands - makes it easier to learn + Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows) + Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help. - no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files) JiHO --- http://jo.irisson.free.fr/

4 4

DVCS (Bazaar clone performance / eol conversions)
by Bryce Harrington 17 Mar '08

17 Mar '08

I asked the bzr developers for feedback on the two issues raised regarding bzr; response is below. Bryce ----- Forwarded message from Martin Pool <mbp@...1798...> ----- Date: Mon, 17 Mar 2008 10:52:07 +1100 From: Martin Pool <mbp@...1798...> To: Bryce Harrington <bryce@...1798...> Cc: Ian Clatworthy <ian.clatworthy@...1211...>, warthogs@...1799..., Canonical Bazaar <bazaar-canonical@...1799...> Subject: Re: Interest in and usage of Bazaar by open source projects On 17/03/2008, Bryce Harrington <bryce@...1798...> wrote: > Hi Ian, > > As I suspected, the topic of changing to a DVCS came up [1] almost as > soon our 0.46 release was finished. This sparked off a lengthy > discussion and comparisons between bzr and git, yet we've still not > reached a firm consensus. > > In general, people are open to bzr due to the ease of use and launchpad > integration benefits, but there were two technical issues that cause > concern. First, we were seeing significant differences in clone times > [2] between git and bzr for our repo. Second, there is concern about > treatment of end-of-line conversion between *nix and dos[3]. I was > hoping you could provide some insight or more authoratative word on it > than we have currently. > > Bryce > > [1]: http://www.nabble.com/Inkscape-0.47-Development-Plans-to16044924.html > [2]: http://www.nabble.com/forum/ViewPost.jtp?post=16064712&framed=y > [3]: http://www.nabble.com/forum/ViewPost.jtp?post=16065313&framed=y Thanks Bryce, The times reported there can be greatly reduced by a few things: * create a shared repository using bzr init-repo, and put all your branch directories under that; then local branching is just a matter of building a new working tree * similarly for pushing to your own server * make sure you're using the packs repository format (which is the default since 1.0) Pushing new branches to Launchpad is currently quite slow, because there is no shared storage between different branches of the same project. For medium-large projects, I can't currently generally recommend hosted branches. What I would suggest is pushing to your own server, then registering the branch to be mirrored to Launchpad. Making hosted branches much faster, through sharing storage between them, is (imo) _the_ major goal for lpcode2.0. Implementation for it is well underway but not live yet. Also, eols are improved by the checkeol plugin, and I think there will be better builtin support soon. I haven't read the whole large thread but please point out important bits. -- Martin ----- End forwarded message -----

1 0

Fit Text
by Edward Flick 16 Mar '08

16 Mar '08

Hello, I'm looking to add (or looking for) a feature which shrinks text to fit inside of a text box (per line preferably or per box). I couldn't find a part of the SVG spec which covers this. Could an addition be made inside of the Inkscape namespace for an attribute that would fit on a <text> or <tspan> element (which applies the same font size to the whole block in which it was declared to fit the widest line, IOW if it is applied to <text> block the whole block would get that new font size or when applied to <tspan> it would be a line by line fit) which would be specified something along the lines of: fitText = none | increaseTextSize | decreaseTextSize What do you guys think? Edward Flick

2 3

New extended input devices dialog
by Jon A. Cruz 15 Mar '08

15 Mar '08

I've got the work-in-progress of the new input devices dialog in, but disabled. If anyone wants to give it a try, verbs.cpp needs USE_NEW_INPUT_DEVICES defined to switch it on. The main thing it will allow is that the test area should show device button and mouse events from devices, and should list all that are configured. Some feedback on what goes on there could be handy.

3 5

Inkscape 0.46 in Ubuntu Hardy
by Bryce Harrington 15 Mar '08

15 Mar '08

Inkscape 0.46 was accepted into Ubuntu Hardy today, just meeting the Beta Freeze deadline. (Anyone know if we made it in Fedora?) Bryce

6 10

Examples with Inkscape: Designs for animation project
by Bernardo González Reinfeld 14 Mar '08

14 Mar '08

Hello, First than all, THANKS! Inkscape is great and we love what you do! We talk about Inkscape with colleagues and partners, and We try to help you spreading the voice. Also we teached (short courses) how to use Inkscape, in our local Fine Arts Faculty (La Laguna University). We're a small studio from Spain that work with open source tools and we like show you what we're doing right now. http://www.cejasbravas.com All the images that you can see in our site was created with Inkscape (we added this point in our FAQ). And also all the scenes of our pilot (CB is a project for a tv series -2D animation- for childs. We're trying to find funds to produce it) has been draw it with your software. (We have a St Patrick's day banner right now :)). You can add our images to your site, if you like show it like examples. Just add a link to our site and write us to see what images you choose... if you do :) We like show that open source tools can be used in studios without problem. And our Creative Director love it! Well, that's all. We add our sites to gallery's wiki. And again, THANKS. We hope that you like what we do. Cheers PS: Please, this isn't spam. We just like show you examples and applications of Inkscape in real world. -- *Bernardo G. Reinfeld* General Manager * http://www.organicadtm.com * Tel. (+ 34) 922 152 660 * Mobile (+ 34) 637 160 308 * Fax (+ 34) 922 299 479 Calle Bethencourt Alfonso, nº 2, Edf. Trianon, piso 5, centro 38001. Santa Cruz de Tenerife. Canary Islands. Spain En cumplimiento con la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI-CE) aprobada por el parlamento español y de la vigente Ley Orgánica 15 13/12/1999 de Protección de Datos española, le comunicamos que su dirección de correo figura en este momento suscrita a nuestro mailing, formando parte de un fichero automatizado de datos. Si no quiere recibir mas información responda a este correo indicando en el asunto "DAR DE BAJA".

1 0

Renaming SPObjects proposal
by unknown＠example.com 14 Mar '08

14 Mar '08

Hello all, In spirit of codebase cleanup, I'd like to propose a simple renaming idea, to make things more clear to the developer (to me, at least :) I think, apart from C++-ifying, it would be a lot clearer when the SPObjects are renamed to either "SPObject" (the same :P) or "SVGObject". An example: SPPath represents <svg:path> in the SVG. When <svg:path> is added to SVG, Inkscape immediately generates an SPPath for it. I therefore propose to rename it to something that reflects this aspect of SPPath: that it is directly linked to something in SVG. SPDesktop for example is *not*. SPDesktop => SPDesktop, stays the same SPPath => SVGPath, meaning it represents some element in the SVG. SPShape => SVGShape (since all its derivates are SVG elements) SP_IS_PATH => IS_SVG_PATH (I never understood why it isn't named IS_SP_PATH) SPNamedview => SVGNamedview ? Now this one is a troublemaker. Because it is linked to <sodipodi:namedview> in the XML. I still think we should rename it with SVG up front, because it is linked to something in the SVG, does not matter what its name in XML is. Please, if this above all is non-sense, slanted or incorrect in any way, let me know! I do not know what to do with the filename. I propose to keep them sp-path and such, to avoid losing SVN history, which is absolutely unacceptable to me. (I don't know how to rename files in SVN, is that possible?) Note that we actually already have a file called svg-path... If no (negative) comments have reached me, I'd like to start this in a week or two. I really think it clears up things. It is sort of a first step into grouping things. Thanks, Johan

6 8

NEW: smaller SVG files
by bulia byak 14 Mar '08

14 Mar '08

As a file size optimization, Inkscape does not write into SVG some of the stroke properties if the object has stroke:none and some of the fill properties when it has fill:none. The only situation where this might affect you is if you remove stroke from an object and then turn it back on - the object will get the default stroke instead of the same as it had before. Also, in manually-edited SVG where a parent group has no stroke but sets some stroke properties to be inherited by its descendants, you will need to set stroke property to other than none on the group, and suppress inheritance with stroke:none on those children that don't need it. Specifically, if stroke:none, the following properties do not get written to SVG: stroke-width stroke-linecap stroke-linejoin stroke-miterlimit stroke-opacity stroke-dasharray stroke-dashoffset Note that this does not include marker properties, which means you can still have markers on a path without visible stroke. If fill:none, the following properties do not get written to SVG: fill-opacity fill-rule -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

NEW: single-object and drawing PDF export
by bulia byak 14 Mar '08

14 Mar '08

With PDF export, it is now possible to make the PDF page the size of the entire drawing, instead of the same as SVG page as before by the "Export drawing, not page" checkbox in PDF export options. Also, you can export a single object from a complex document to PDF if you specify the ID of that object in the "Limit export to the object with ID" field; the page of such PDF will be the same size as the bounding box of that object and will show only that object (all others will be hidden). The same capabilities are available from the command line by using --export-area-drawing and --export-id=ID parameters with --export-pdf (previously, they only worked for PNG export). -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

GOption migration patch
by Krzysztof Kosiński 14 Mar '08

14 Mar '08

Hello Can anyone review the patch provided here: https://bugs.launchpad.net/inkscape/+bug/195220 It moves the commandline option parsing from popt to GOption and shortens main.cpp a fair bit, but I'm not sure how does Inkscape open files - does it (1) use UTF-8 filenames or (2) filenames in the system encoding? This patch will be ok if 2 is the case, and I believe 2 is the standard practice with Glib. Regards, Krzysztof (Chris) Kosiński -- View this message in context: http://www.nabble.com/GOption-migration-patch-tp16039864p16039864.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

3 3