- Inkscape Devel - Inkscape Mailman

configure.ac for automake 1.10
by Pierre-Luc Auclair 03 Mar '07

03 Mar '07

Here's the file. Pierre-Luc

4 3

Fwd: git on win32
by David Douard 03 Mar '07

03 Mar '07

Sorry, I forgot to CC to mailing list ---------- Forwarded message ---------- From: David Douard <david.douard@...400...> Date: 27 févr. 2007 09:06 Subject: Re: [Inkscape-devel] git on win32 To: "Jon A. Cruz" <jon@...18...> Another solution might me to use Mercurial. It is very similar (in goals and day to day use) to git. It is written in Python. This is the tool we now use at Logilab for all of our projects (for a year now; we used to use CVS). Mercurial is incredibly fast (git also I guess). And once you have tasted disctributed SCM, well, you just can't imaging how you could have do without it for years... Seriously, give it a try. Note that the first impression might me disappointing, but once this step is done, what a pleasure... I used to be a big SVN fan (I still find SVN a noce tool, but...), but mercurial (ang git which really is very similar) is an incredible tool for every day work. This big drawback (for git and mercurial) is the lack of "tortoise" tool on win32 platform. http://www.selenic.com/mercurial/wiki/ Note also that there is "all-in-one" mercurial package for win32 . http://mercurial.berkwood.com/ David 2007/2/27, Jon A. Cruz <jon@...18...>: > > On Feb 26, 2007, at 1:58 PM, MenTaLguY wrote: > > > ...and however much of cygwin is necessary to make them all work. > > > -mental > > > Unfortunately I've found that cygwin makes many things significantly > slower. > > My other reservation would just be that git was made to solve certain > problems that we're not hitting on Inkscape. That point, though, is just > something I've not looked into. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > >

6 8

Last call for LGM brochure
by cedric GEMY 02 Mar '07

02 Mar '07

Hi guys We are soon ready to finish the brochure made for LGM. People who are interested can send me the nice artworks and design (in svg if possible) they have made, with credits+licence (use metadata for example). I can't promise it can be put within the brochure but there is a chance. Don't worry if you're not a professional : if you like your work may be others will like it too. For info : the brochure will be ditributed in 4000 ex with graphika which is a high level magazin for graphic designer in canada. The purpose of the brochure is to introduce and promote Inkscape (and others) to this public. Cedric (pygmee)

1 0

Re: [Inkscape-devel] [cairo] PS/PDF Gradients
by Carl Worth 02 Mar '07

02 Mar '07

On Mon, 29 Jan 2007 00:27:27 +1030, Adrian Johnson wrote: > I have been testing Miklós' PDF gradient patch from > http://lists.freedesktop.org/archives/cairo/2006-August/007648.html Thanks for keeping this alive, Adrian! I know that the inkscape developers, (among others), are very anxious to see cairo generate PDF files with native gradients rather than falling back to rasterization---since other than this issue, cairo is providing very good PDF export capability. > Looking at the patch the only obvious deficiency I could see is lack of > support for the different cairo_extend_t options. The patch has the PDF > /Extend value set to [true true] which is equivalent CAIRO_EXTEND_PAD. > > Testing linear gradients with rgb stops appears to be ok. Changing the > PDF /Extend value set to [false false] which is equivalent > CAIRO_EXTEND_NONE also works. OK, well one thing we definitely need is a test case for linear gradients with all of the extend modes, (could be much like the recent radial case I added). > The results of testing linear gradients with CAIRO_EXTEND_PAD and rgba > stops are: > acroread - ok but the colors seem to be too dark. > evince - broken, The padded region is opaque when it should have > some transparency. > ghostscript - broken. all opaque colors. no transparency. All I looked at was the output from poppler which the test suite uses. I'm also seeing the colors as too dark, but otherwise the results look quite promising, (again without testing extend modes yet). Here's the reference image (sorry it's so tiny): http://cairographics.org/~cworth/images/linear-gradient-ref.png and here's the rendering of the PDF output: http://cairographics.org/~cworth/images/linear-gradient-pdf-argb32-out.png So that just looks like one simple color scaling issue somewhere. And once we test the extend modes, it would at least be very easy to only turn on native gradients for known-good extend modes. > I have not tested radial gradients. I did now, and it's not too pretty. Here's our reference image: http://cairographics.org/~cworth/images/radial-gradient-ref.png and here's the rendering of the PDF output: http://cairographics.org/~cworth/images/radial-gradient-pdf-argb32-out.png So it looks like there's still a fair amount of work to be done there. Anyway, if anyone wants to help out with this, it would be *greatly* appreciated. I took this quick look to see if there was anything here in a state ready to make it into 1.4, but it looks like there's not. -Carl

2 2

NEW: Command line options
by Ted Gould 02 Mar '07

02 Mar '07

Hey, So I added in some new command line options that are fun. * --verb-list will list all the Verb IDs and their names in Inkscape. This makes writing your own menus and hotkeys much easier as you can easily find out what the choices are. * --verb followed by a verb ID allows you to specify a verb to be called on every document opened by Inkscape initially from the command line. * --select followed by a node ID will allow you to add a node to the list of selected objects. Now, initially I thought these would be really good for performance testing, and that was my driver. You could do something like this: $ time inkscape --verb=FileClose my_complex_file.svg And get a reasonable number. But, now, with the selection, I think it can be much more useful than that. You can call effects, or any other verb, then FileSave and FileClose to automate all kinds of things on your diagrams. Have fun, Ted

3 5

Re: [Inkscape-devel] Inkscape's user manual
by Cédric GEMY 02 Mar '07

02 Mar '07

To answer Bryce, i would be glad to merge efforts with other people. If those people who wants to contribute are mainly for a wiki solution, i'm ready to take if there is a possibility to transform it in more standard format. So my proposal/question would be : 1. make test on transforming wiki to docbook as mentionned 2. clear our mind on the subject 3. open a real space on inkscape.org for this 4. should work from scratch or on basis of mine or kevin's work ? 5. make some ToC to show where we should go 6. have our own release note in purpose to match as soon as possible inkscape releases (was until 0.44 for me in frech) 7. define internationalisation strategy and process My vision of the manual is not giving tutorials (inkscape has already that) but more something like a help file that give precise infos on functionnalities. Core Developers would be first interested in helping the manual or keep close to manual writers (with a reciprocity, of course ;) ) These functionnalities can be illustrate with examples or step by step description if needed. About tav's manual, it is evidently very good and i encourage it as any articles on inkscape (i write myslef some in magazins, soon one in Linux+DVD). But as discussed with Colin Marquee, it would be nice to have an inner help browserthat could be distributed in a different package (see gimp). Some words in the wiki about it. Hope it helps Cedric

1 0

Inkscape Project Status
by Bryce Harrington 02 Mar '07

02 Mar '07

Just to give some visibility into some of the work bubbling away these days: Cairo renderer: Bulia has taken point on investigation of conversion to Cairo. Some tough problems have been uncovered but we're gaining a clearer picture of what needs done. Presently this looks like it will require an all at once brute force approach, rather than incremental refactoring. If so, we'll need to reach a decision on how to undertake that while minimizing disruption to SVN HEAD users. Build system: There is definitely a concensus that our current build system sucks. Options include CMAKE, Bob's buildtool, or just a cleaned up automake. We really need to have interested parties mind meld and find a single solution. Version control system: Mental has been experimenting with git and trying to get it to operate with svn. This study is still very early on, but if it works out well, one day we may begin encouraging developers to use git. Bug tracking: I have been experimenting with use of Mantis with the goal of replacing our SF bug tracker. It looks good, but the principle issue is how to migrate the bugs and their history from SF to Mantis. I'm also interested in seeing if it can be combined well with Drupal, maybe along with Pootle. Any drupalheads out there? Manual: We've got a good unofficial non-free manual/book and several [semi-]official incomplete free manuals. There is discussion about if efforts can be combined to produce a good official free manual. Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up. Bryce

11 15

Re: [Inkscape-devel] Inkscape Project Status
by Colin Marquardt 01 Mar '07

01 Mar '07

"Leandro Regueiro" <leandro.regueiro@...400...> writes: > If you make a good manual I would translate it. I don't like the idea > of use SVG for docs. Please use another format. SVG can be converted to po with xml2po, so translators would have it as easy as with docbook. (I still like docbook for a task like a manual more.) Cheers Colin

1 0

Re : Docbook usage (was : official inkscape user docs)
by Cédric GEMY 01 Mar '07

01 Mar '07

Yep, i know that Ryan. Docbook is sometimes quite heavy to use. But this is the standard way to do this. All the documentation project use Docbook (see inkscape tutorials for example) because it is precise, XML base, and that we have many commands to transform it in HTML, PDF and many other format. Wouldn't you really like to try again, even if i have to proofread ? I'm also testing some possibilities via OpenOffice since there is a tool to convert ODT to docbook. Atthis time, some tag are missing, but i'm sure we good succeed in this way. Cedric >Im prepared to help work on an _official_ version of the user docs... >IMO, using the SVN and docbook format for developing something like an >entire user manual may be a bit daunting for an artist or a non-dev >type person that may want to contribute to user docs for inkscape - >that is why i suggested maybe using the wiki for a development space >of the docs, (with a strict template structure that would allow for >easy conversion into the docbook format.)

3 2

Solaris 2.8 / gcc-3.2.3 patches commited
by Markus Schwarzenberg 01 Mar '07

01 Mar '07

Hi, the Solaris 2.8 / gcc-3.2.3 fixes (derived from inkscape-Patches-1370904) are now in svn revision 14251. For details see ChangeLog. The specific platform is detected in configure.ac, and all possibly non-portable changes are guarded by #if defined (SOLARIS_2_8) && __GNUC__ == 3 && __GNUC_MINOR__== 2 Markus

2 4