February 2007 - Inkscape Devel

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

inkscape git mirror?
by MenTaLguY 18 Jun '08

18 Jun '08

I'm interested in setting up a git mirror of Inkscape SVN; who's the person in charge of our server currently? We'll need to have a fairly current version of git, libsvn, and the libsvn perl bindings installed to do this. -mental

6 11

Odd size of imported bitmaps
by Dan H. 31 Aug '07

31 Aug '07

Hello, I've imported a 400x400 pixel TIFF image into an inkscape drawing, and it comes out as 112.89 x 112.89 mm, which translates to a resolution of roughly 90 dpi. Where does this number come from? Shouldn't inkscape honour the dpi information that is embedded in the TIFF image? Alternatively, for images that don't have a "built-in" resolution, inkscape should ask for a "native" size of the image or use a changeable default resolution. Also I noticed that some imported images have width and height xml attributes while others don't. All this came to my attention when I worked with a SVG file with 20 imported images of about 10MB each (TIFF uncompressed) which bogged down my computer. I tried substitutung the TIFFs with scaled-down (by .25) working copies, which worked fine for those images that had width and height attributes (the others came out a fourth of the size), I'm just wondering how Inkscape arrives at the "native" size of an image, and I wanted to know if others agreed with my notion that in a vector drawing program the resolution of imported bitmaps was of high importance. It would also be nice if Inkscape could somehow reload image properties if the original bitmap had changed (by scaling or cropping, for instance). Thanks, --Dan

4 5

Latest news on LGM 2007 Montreal
by Louis Desjardins 16 Mar '07

16 Mar '07

Dear Inkscape team! I'd like to post a few info here for the benefits of all travellers to LGM. 1. I know the website of LGM is outdated. I expect things to be straightened up in the coming days. :) 2. Meanwhile, the Create wiki has been updated : http://create.freedesktop.org/wiki/index.php/Conference 3. Visa. Please review the VISA info as it might apply to some of you when travelling to Canada. 4. Rooms. We have dealt a LGM special price on rooms at the Student Residences of the uni hosting the LGM. All info is on the wiki. What has guided me is to allow LGM participants and especially the devel teams to be together most of the time (remember we only have 3 days), have internet access and enough room to organize meetings. All that into a calm environment. The residences are on the site of the LGM at less than 5 minutes from the main auditorium. Arrival date : May 3 (Conference starts on May 4). We may be able to arrange things if you want to arrive earlier. Please let me know. And we also want to avoid getting people lost in the city (Montreal is a North American city, quite extended...) and taking up most of their time getting from their hotel to the LGM site and back. I have made a reservation on 50 Single rooms + 5 Cosy Suites (with large bed) and there are lots more room there if needed. On each other floor of the residence people have access to a Salon that can hold a good 10 to 12 people meeting and we also have access to another 3 large rooms for meetings with more than 20 persons at a time. 5. Sponsorship. I am deeply concerned by sponsorship. We have to be able to help people get to the LGM. So far, I am still waiting on confirmation but sponsors have shown clear interest in helping us again this year. It's a matter of time until we know for sure the exact amount we going to get from the sponsors. Please stay tuned. I will post the info as soon as I have something to say. 6. LGM speakers. I would appreciate that people interested in making a talk at LGM show up on the Create wiki. Some people have contacted me early by e-mail. Please fill the wiki as well. This is the only sure way to help me put the schedule together. Also, if you know someone that would be a good speaker, don't hesitate to propose his/her name. And don't forget the subject suggestions as well. 7. LGM Brochure (see wiki for details) : we'd like to have each project described. Cédric Gemy should be able to take care of Inkscape's description and maybe more. At the same time, if anyone on this list has images created with Inkscape that we could use to show what the program can do, please contact me off list. We don't need that many images but since we're distributed in the graphic designers magazine, the higher the level the better the effect, imo. 8. If anyone has a question or comment or suggestion, please don't hesitate to get back to me. Hope to see you again at LGM2 and of course meet new people! Louis Desjardins LGM 2007 organizer -- Louis Desjardins Mardigrafe inc. T 514 934 1353 F 514 934 3698 http://www.mardigrafe.com

2 1

NEW: flood fill
by John Bintz 11 Mar '07

11 Mar '07

Inkscape now has a very rudimentary flood fill tool. It works by performing a bitmap-based flood fill on a rendered version of the visible canvas, then tracing the resulting fill using potrace and placing the traced path on the canvas. You can access it by the paint bucket icon in the toolbar. It places the rendered path onto the current layer, so you can have a layer on top (in my case, "Inks") and select the layer below ("Colors") and do the fills so that they always appear below the inks. This tool is in a very basic state, and there are issues with rendering accuracy and memory usage. Some improvements that I can see being done are: * If the [Ctrl] key is held down, clicking on an object changes the fill color to the current fill color, and [Shift]-[Ctrl] changes the stroke color to the current stroke color * A way to either manually or dynamically increase the resolution of the rendered version so that the accuracy of the flood fill is better Try it and let me know what you think. Thanks, John

5 31

0.45.1?
by bulia byak 04 Mar '07

04 Mar '07

I think it's time to start working on 0.45.1 - there are lots of patches in the queue. However the most frequently reported problem is still not fixed: it does not work on OSX 10.3.9. Is there anyone on Mac who could look into this and report if this is fixable at all? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

9 19

cairo-1.3.14 build for win32
by Bob Jamison 04 Mar '07

04 Mar '07

People interested in Bulia's work on using Cairo for Outline Mode rendering might want to experiment with cairo-1.3.14's faster rendering. I made a win32 build of it here: http://inkscape.modevia.com/win32libs/cairo-1.3.14-mingw.7z To test it, all you need to do is copy the DLL in /bin into your Inkscape directory. bob

2 5

NEW: cairo rendering in outline mode
by bulia byak 04 Mar '07

04 Mar '07

I was curious if cairo is in fact slower or faster than our current renderer. I didn't feel like converting us totally to cairo yet, but we have outline mode which is much simpler and perfect for tests like this. So in about 3 hours (of which 2 hours were spent figuring out a known bug in cairo) I converted our outline mode rendering to cairo. The result of this experiment, after I adjusted the tolerance of cairo to match our outline mode quality, is near parity. That is, cairo is about as fast as our own renderer, at least for outline mode (i.e. lots of paths but no gradients or transparency). However this claim needs to be qualified: - It is only true for the latest version of cairo (tested with 1.3.14). Versions 1.2.x are noticeably slower. - This uses image backend to render to a memory buffer, and therefore cannot use any hardware acceleration. Using hardware-accelerated backends will require much more drastic changes in Inkscape's architecture. - Even with image backend, currently cairo is used _only_ for path rendering, each path going to its own temp buffer, and these buffers are later composed together just as they were before. I suspect that if this is optimized by allowing a single cairo context draw all of the paths in the drawing into a single buffer, performance will improve noticeably. In any case, since this does not make for any speed regression, and since it fixes at least one bug that our native renderer had in outline mode, I committed this. Please test outline mode thoroughly and report if you find any problems. If everything works fine I'll remove the old outline mode code and will look into doing some further optimizations. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

13 42

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