- Inkscape Devel - Inkscape Mailman

Announce: Scribus 1.3.3.8 Release
by Plinnell 26 Feb '07

26 Feb '07

The Scribus Team is pleased to announce the release of Scribus 1.3.3.8 This release is purely a further bug fix release to the recently released 1.3.3.7. This release adds more translation updates, some bugs were found and fixed, many improvements to the SVG importer, Open Document Draw importer and improvements to PDF forms. With 1.3.3.7 we announced the availability of a new OpenSuse rpm download repository for all Suse versions 9.3+, including SLED 10. To download add: http://software.opensuse.org/download/home:/mrdocs/ to your yast/apt/smart source list for the corresponding Suse version. We have now added Fedora 5/6 rpms as well. We hope have this for Mandriva in the next release. Downloads: Source and some rpms: http://sourceforge.net/project/showfiles.php?group_id=125235 Upstream Debian/Ubuntu repo: http://debian.scribus.net Ubuntu users are advised to see: http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_… Fedora 5/6 RPMS: http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_6/repodata/ http://software.opensuse.org/download/home:/mrdocs/Fedora_Extras_5/repodata/ MacOSX: http://aqua.acribus.net The Scribus Team would also like to thank - Anduin.net/Øverby Consulting and Cardia AS for their continued hosting of all of the Scribus websites. The Scribus Team would also like to thank the many end users, translators, testers and contributors who helped us with this release. About Scribus Scribus is a cross-platform open source page layout application with a focus on high quality commercial grade PDF and postscript export. Originally developed on Linux, Scribus now runs natively on MacOSX, OS/2, many forms of Unix and Windows 2000/XP. Underneath the modern and user friendly interface, Scribus supports professional publishing features, such as CMYK color, spot colors, separations, ICC color management and versatile PDF creation. Scribus was the first page layout application on the planet to directly support PDF/X-3 output, a rigorous ISO standard. Scribus did so by almost a year. The Scribus Team is made up of a diverse group of developers with significant experience in pre-press and newspaper publishing. Commercial support for Scribus is available for companies and institutions for implementation, training and migration.

1 0

Two different Inkscape SVN freezes
by Joshua A. Andler 26 Feb '07

26 Feb '07

Ok, there are two recent freezes that I've witnessed (one pointed out by Johan). Both occur with current SVN. First, I've got a file (our icons) that with a particular object selected, if you switch tools inkscape freezes up. I will file a bug report and attach file shortly so others can check it out. Johan's is also easy to reproduce. Run Inkscape in GDB on win32 (both of us tested on XP specifically) and select a file from the "open recent" list. It doesn't freeze outside of gdb and doesn't freeze in gdb on linux. So it seems a little strange. Anyone have any thoughts? (other than filing both bugs formally) -Josh

1 0

NEW: smoother panning and scrolling
by bulia byak 26 Feb '07

26 Feb '07

Several improvements make canvas panning and scrolling smoother and more interactive in complex slow-rendering documents: * When panning by the middle mouse button, Inkscape no longer attempts to redraw the canvas while your mouse button is pressed. Any redrawing only happens after you release the mouse. As a result, the newly revealed parts of the canvas are somewhat more "dirty" but the panning is smoother than before, with few if any "hiccups". * Previously, if you start panning with middle button while Inkscape is still redrawing screen in a complex drawing, panning sometimes completely failed or moved canvas just a little step. Now it is guaranteed to pan the canvas all the way from mouse-press point to mouse-release point in any case, even if sometimes it fails to show the intermediate positions. * When pressing and holding Ctrl+arrows to scroll canvas, Inkscape normally accelerates scrolling so that each next scrolling step is bigger than the previous. Previously, in complex drawings this acceleration sometimes got interrupted, which made scrolling annoyingly bumpy and slow. Now this is fixed so that scrolling is smoothly accelerated even in a slow-rendering document. * The default starting speed and acceleration of Ctrl+arrows scrolling are slightly increased. (They are both settable in Preferences.) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

Fwd: [cairo] Re: NEW: cairo rendering in outline mode
by bulia byak 25 Feb '07

25 Feb '07

Here's a message from a cairo developer - not sure if it reached our list, so I'm forwarding it. It confirms that my initial description was indeed incorrect: Inkscape uses fixed order, while Cairo's order depends on platform. Sorry for the confusion (though it amounts to the same thing from compatibility viewpoint). ---------- Forwarded message ---------- From: Jeff Muizelaar <jeff@...1669...> Date: Feb 25, 2007 5:15 PM Subject: Re: [cairo] Re: [Inkscape-devel] NEW: cairo rendering in outline mode To: bulia byak <buliabyak@...400...> Cc: jiho <jo.irisson@...400...>, cairo@...278..., inkscape List Devel <inkscape-devel(a)lists.sourceforge.net> On Sun, Feb 25, 2007 at 11:10:16AM -0500, bulia byak wrote: > Last night, with the help of Carl Worth, the issue of cairo/inkscape > not working on mac was more or less clarified. Here's how I understand > it. > > When drawing into a memory buffer, cairo uses a fixed byte order of > the R, G, B, A bytes regardless of the platform. This is incorrect. Cairo's byte order depends on the platform. See, for example, pixman/src/fbpict.c:fbOver(): static CARD32 fbOver (CARD32 x, CARD32 y) { CARD16 a = ~x >> 24; CARD16 t; CARD32 m,n,o,p; m = FbOverU(x,y,0,a,t); n = FbOverU(x,y,8,a,t); o = FbOverU(x,y,16,a,t); p = FbOverU(x,y,24,a,t); return m|n|o|p; } As is shown, the alpha component is always in the most significant byte. So byte 0 on big endian and byte 3 on little endian. However, Inkscape's code assumes a fixed byte order (see below). i.e R is byte 0, G is byte 1 etc. void nr_R8G8B8A8_N_EMPTY_A8_RGBA32 (unsigned char *px, int w, int h, int rs, const unsigned char *mpx, int mrs, unsigned long rgba) { unsigned int r, g, b, a; unsigned int x, y; r = NR_RGBA32_R (rgba); g = NR_RGBA32_G (rgba); b = NR_RGBA32_B (rgba); a = NR_RGBA32_A (rgba); for (y = h; y > 0; y--) { if (a == 0) { memset(px, 0, w*4); } else { unsigned char *d = px; const unsigned char *m = mpx; for (x = w; x > 0; x--) { d[0] = r; d[1] = g; d[2] = b; d[3] = NR_PREMUL_111 (m[0], a); d += 4; m += 1; } } px += rs; mpx += mrs; } } > > Inkscape and GDK (which is used by Inkscape for drawing to screen), > however, both use system-dependent byte order, i.e. the order of R, G, > B, A is determined by the hardware and is different on PC and Mac > platforms. > > And it so happens that the fixed order of cairo coincides with the > hardware order on PC but not on Mac. Hence, painting by cairo directly > into Inkscape/GDK buffers worked on PC but on Mac, all colors are > wrong and (in case of outline) black color gets zero opacity, i.e. > becomes invisible. > > Essentially, this means that Inkscape and cairo are not compatible as > is, and that a gradual switching of parts of our display engine to > cairo is not possible. (Unless we ditch Macs, of course.) > > Even if we switch our screen output from using GDK to cairo (which is > relatively easy), this won't help - it will just break rendering on > PCs too. Inkscape has a lot (and I do mean A LOT) of code that assumes > system-dependent byte order. Composers, decomposers, premultipliers, > unpremultipliers, blitters and blotters of all sizes and colors > permeate the codebase. Most of them come all the way from Sodipodi. Fortunately, cairo has a lot of equivalent code that matches cairo's byte order. It also looks like alot of inkscape's compositing code, like cairo's, isn't particularily fast either. > > Now, of course, it's possible to create "adapters" for cairo bits. > That is, every time we use cairo, instead of drawing directly into > Inkscape buffer, we can draw into a temporary buffer instead, > rearrange the bytes in that buffer, and then compose that into the > main buffer. But that is certain to more than negate the feeble speed > gains we're seeing from cairo's image backend rendering. > > Or, we can attempt a much more drastic rearchitecturing, by changing > our functions so they pass around cairo contexts instead of Inkscape > buffers. With this approach, byte reordering will be needed less > frequently, and eventually eliminated completely. But this is not only > much more work, it will also mean a lot more bugs and regressions and > quite some time before Inkscape is usable again. > > So, it looks like due to this stupid byte-order issue, cairo for us is > practically an all-or-nothing proposition - and much more hassle than > I expected. I'm not saying it's impossible but it is quite a major > project that cannot be done gradually. > > Unless, of course, cairo gets so in love with Inkscape as to provide > us with a new image surface with system-dependent byte order... This is painful as well. All of cairo's software compositing routines use the cairo byte order, and likewise X assumes this byte order as well. -Jeff -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Fwd: [cairo] Re: NEW: cairo rendering in outline mode
by jiho 25 Feb '07

25 Feb '07

Forward of a message by Jeff Muizelaar who is probably someone at Cairo and could not post this to the list because he is not subscribed. Begin forwarded message: > From: Jeff Muizelaar <jeff@...1669...> > Date: 2007 February 25 22:15:09 CEST > To: bulia byak <buliabyak@...400...> > Cc: jiho <jo.irisson@...400...>, cairo@...278..., inkscape > List Devel <inkscape-devel(a)lists.sourceforge.net> > Subject: Re: [cairo] Re: [Inkscape-devel] NEW: cairo rendering in > outline mode > > On Sun, Feb 25, 2007 at 11:10:16AM -0500, bulia byak wrote: >> Last night, with the help of Carl Worth, the issue of cairo/inkscape >> not working on mac was more or less clarified. Here's how I >> understand >> it. >> >> When drawing into a memory buffer, cairo uses a fixed byte order of >> the R, G, B, A bytes regardless of the platform. > > This is incorrect. Cairo's byte order depends on the platform. See, > for > example, pixman/src/fbpict.c:fbOver(): > > static CARD32 > fbOver (CARD32 x, CARD32 y) > { > CARD16 a = ~x >> 24; > CARD16 t; > CARD32 m,n,o,p; > > m = FbOverU(x,y,0,a,t); > n = FbOverU(x,y,8,a,t); > o = FbOverU(x,y,16,a,t); > p = FbOverU(x,y,24,a,t); > return m|n|o|p; > } > > As is shown, the alpha component is always in the most significant > byte. So > byte 0 on big endian and byte 3 on little endian. > > However, Inkscape's code assumes a fixed byte order (see below). > i.e R is byte > 0, G is byte 1 etc. > > void > nr_R8G8B8A8_N_EMPTY_A8_RGBA32 (unsigned char *px, int w, int h, int > rs, const unsigned char *mpx, int mrs, unsigned long rgba) > { > unsigned int r, g, b, a; > unsigned int x, y; > > r = NR_RGBA32_R (rgba); > g = NR_RGBA32_G (rgba); > b = NR_RGBA32_B (rgba); > a = NR_RGBA32_A (rgba); > > for (y = h; y > 0; y--) { > if (a == 0) { > memset(px, 0, w*4); > } else { > unsigned char *d = px; > const unsigned char *m = mpx; > for (x = w; x > 0; x--) { > d[0] = r; > d[1] = g; > d[2] = b; > d[3] = NR_PREMUL_111 (m[0], a); > d += 4; > m += 1; > } > } > px += rs; > mpx += mrs; > } > } > >> >> Inkscape and GDK (which is used by Inkscape for drawing to screen), >> however, both use system-dependent byte order, i.e. the order of >> R, G, >> B, A is determined by the hardware and is different on PC and Mac >> platforms. >> >> And it so happens that the fixed order of cairo coincides with the >> hardware order on PC but not on Mac. Hence, painting by cairo >> directly >> into Inkscape/GDK buffers worked on PC but on Mac, all colors are >> wrong and (in case of outline) black color gets zero opacity, i.e. >> becomes invisible. >> >> Essentially, this means that Inkscape and cairo are not compatible as >> is, and that a gradual switching of parts of our display engine to >> cairo is not possible. (Unless we ditch Macs, of course.) >> >> Even if we switch our screen output from using GDK to cairo (which is >> relatively easy), this won't help - it will just break rendering on >> PCs too. Inkscape has a lot (and I do mean A LOT) of code that >> assumes >> system-dependent byte order. Composers, decomposers, premultipliers, >> unpremultipliers, blitters and blotters of all sizes and colors >> permeate the codebase. Most of them come all the way from Sodipodi. > > Fortunately, cairo has a lot of equivalent code that matches > cairo's byte > order. It also looks like alot of inkscape's compositing code, like > cairo's, > isn't particularily fast either. > >> >> Now, of course, it's possible to create "adapters" for cairo bits. >> That is, every time we use cairo, instead of drawing directly into >> Inkscape buffer, we can draw into a temporary buffer instead, >> rearrange the bytes in that buffer, and then compose that into the >> main buffer. But that is certain to more than negate the feeble speed >> gains we're seeing from cairo's image backend rendering. >> >> Or, we can attempt a much more drastic rearchitecturing, by changing >> our functions so they pass around cairo contexts instead of Inkscape >> buffers. With this approach, byte reordering will be needed less >> frequently, and eventually eliminated completely. But this is not >> only >> much more work, it will also mean a lot more bugs and regressions and >> quite some time before Inkscape is usable again. >> >> So, it looks like due to this stupid byte-order issue, cairo for >> us is >> practically an all-or-nothing proposition - and much more hassle than >> I expected. I'm not saying it's impossible but it is quite a major >> project that cannot be done gradually. >> >> Unless, of course, cairo gets so in love with Inkscape as to provide >> us with a new image surface with system-dependent byte order... > > This is painful as well. All of cairo's software compositing > routines use the > cairo byte order, and likewise X assumes this byte order as well. JiHO --- http://jo.irisson.free.fr/

1 0

tutorials license
by Alexandre Prokoudine 25 Feb '07

25 Feb '07

Hi, I fail to figure out what license is used for our tutorials. - there is no COPYING file in doc-docbook branch - no license is mentioned in XML files themselves The reason I'm asking is that we can have a tutorial on text tool pretty soon, but I don't know what to tell the original author about license used. Could someone make it clear please? Alexandre

2 3

Re: [Inkscape-devel] Idea for shape generation and morphing
by Jemima Bond 25 Feb '07

25 Feb '07

Hello Bryce, I have posted 12 screen shots of increasing complexity here: http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphappletcaptures.html Sliders modify control point lengths and angles (Mirror, Twist, CP1 and CP2). These are calculated from the turning angle of the turtle. Control point length default is 0.33333 * last distance travelled. My other 2D version is a HyperCard stack written back in the early 1992. This outputs PostScript (Adobe Illustrator 3 file). It generates a host of other shapes (cogs, spirals, shells etc) and uses the same principle of "live" shapes, generated procedurally. I have a 3D Nurbs version in C++ that works around spherical polyhedra but it's about seven years since I wrote the code and I'm still trying to untangle what I actually did :) JB Bryce Harrington wrote: > On Fri, Feb 23, 2007 at 04:47:13PM +0000, Jemima Bond wrote: > >> Hello. I have an idea for generating and morphing vector shapes using >> bezier curves and a turtle drawing routines. You can view this as an >> applet here: >> >> http://myweb.tiscali.co.uk/oaktree/jcb/applets/polymorphapplet.html >> >> You will have to play around with the various sliders, combo boxes etc >> to get a feel of how the thing works. Un-check the "Skeleton" and >> "Control Point" boxes to see the bezier curve only. >> >> Just thought I'd throw it into the inkscape pot. Thanks for your time. >> > > Hi Jemima, > > Would you mind posting some screenshots of this, for those of us that > don't have Java installed? > > THanks, > Bryce > > -- ***************************************************************** This email and its attachments are confidential and intended for the exclusive use of the addressee(s). It must not be edited or reposted. This email and its attachments may also be privileged or protected by legal rules. If you have received this email by mistake please let me know by reply immediately and destroy this email and its attachments. You should not disclose, edit, copy or forward any of its contents. *****************************************************************

11 18

Re: [Inkscape-devel] export /resize quality?
by Alexandre Prokoudine 23 Feb '07

23 Feb '07

On 2/23/07, ulugeyik wrote: > It must one of those under-caffeinated days, I can't tell if there is an > option somewhere to adjust the export/resize quality of jpeg compression. Since when does Inkscape export JPEG? :) Alexandre

1 0

Re: [Inkscape-devel] [Inkscape-user] Scripting the fill style
by bulia byak 23 Feb '07

23 Feb '07

On 2/23/07, singlecell <singlecell@...1666...> wrote: > 1 - Inkscape uses the style attribute on each element to set the fill > colour, and I have to manually go through each element changing them for > my script code to work. Manipulating the style attribute in code would > require parsing to preservation all the other style definitions. > > Is there any way to force inkscape to save style attributes of drawing > elements as separate elements (as I have altered in the attached example)? I have a simple XSLT stylesheet which breaks monolithic style= into style attributes. Worked fine for me. So here's a question for developers: I heard we can use XSLT as input/output filters? If so, adding an output format that filters SVG through such a filter would be trivial. > 2 - should Inkscape treat script element as CDATA, as it currently > treats it as a text node and replaces " with " etc. And it also loses script attributes (at least from root svg) when saving as Plain SVG. Could you please file bugs on these problems so they are not forgotten? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

A Survey on Defect Management Practices in Free/Open Source Software
by Anu Gupta DCSA 23 Feb '07

23 Feb '07

Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta@...1665... anugupta98@...400...

1 0

Markers - fix for 'none' bug
by Bryce Harrington 23 Feb '07

23 Feb '07

There was a bug in the recent marker work where markers weren't getting removed from lines if you picked "none". I had disabled the code that makes the 'none' marker work, because doing so prevented an event cascade. So this fixes the event cascade - basically, this temporarily disables the "changed" signal handler when we're updating the marker menus, so the changes don't trigger additional "changed" signals. There is still one bug I know of - if you click on one of the numerical entry boxes on the stroke style page, before clicking the marker dropdown, then when you open the marker dropdown you see two separators rather than 'None' and one separator. But this bug has been around for quite some time. Let me know if you spot any other bugs. Bryce

1 0

Addition of fill to Calligraphy tool
by John Cliff 22 Feb '07

22 Feb '07

Hi guys, I've Modified the calligraphy tool to create a fill shape as well as a stroke shape. The 2 are grouped so they act like one object in selector. Patch is in the tracker, #1666582 still todo: * Need to fix the setting of the styles of the 2 objects, they just get the current style at the minute, want to fill the stroke with the current stroke, fill with the current fill. * Want to put a check box in the toolbar to enable/disable generation of fills, so that people wanting the old way of working can have it still. Its been a long time since i touched the codebase, and I'm very rusty, so would appreciate some code review before this gets commited to svn. comments are welcomed, just cant promise how swift updates will be. Cheers Sim ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail

1 0

Obtaining compiler warnings
by unknown＠example.com 22 Feb '07

22 Feb '07

Does anybody know a way to neatly catch compiler warnings on windows? I'd like to only see a list of compiler warnings, instead of the complete compiler commandline as it is now. For example: It would be very nice if the buildtool could generate a separate file (say compiler-out.txt) in which all special compiler messages are put such as: gradient-context.cpp:325: warning: 'pointtype' may be used uninitialized in this function Thanks! Johan

6 5

Grip snapping to visible grid lines only
by Daniel Pope 21 Feb '07

21 Feb '07

I was just experiencing an issue with grid snapping: I wanted objects to be pixel-aligned, so I turned on a 1px grid with snap. However, Inkscape only draws lines every 10px or so, and this is the snap I end up with. I have to zoom to 800% to be able to get single-pixel snap, which is too close to be able to see what I want to do. I went to report this as a bug but it's already been reported as 1505815 which is marked WONTFIX on the grounds that this is intentional. What's the rationale behind this behaviour? Without wanting to revisit it too much if this has been discussed before, I can think of only one reason why this is beneficial: 1. What you see is what you get. Whereas under my expected behaviour (specified grid was respected) 1. What you specify is what you get. 2. Zoom-independence. 3. Can work at 1:1 and use grids finer than 8px. 3. Everything else I've tried works this way eg. XaraLX, Flash Put another way, would anyone have any objections to re-opening this? Dan

9 14

Extension parameters
by Romain Thouvenin 21 Feb '07

21 Feb '07

I wanted to slight modify webbrower_* extensions so that they directly bring to the web page in the relevant language when it exists. I thought the good way to do that would have been to give the address as a translatable parameter that is not set by the user, but I didn't find how to do that, it seems impossible. I guess it is impossible, since there are several extensions for visiting a web page. Am I right ? Do you have an idea to work around my problem ? Maybe using a parameter proposing the different languages to the user ? Romain

6 10

Marker menu dynamic updating
by Bryce Harrington 21 Feb '07

21 Feb '07

I've committed a fix to one of the marker menu bugs. Previously, the marker menu had been split to show markers in the <defs> above the line only if they were non-stock markers. However, the problem happens that if one alters the stock marker in the <defs> section without changing its ID, it doesn't show at all in the menu. Now, the menu shows ALL markers from <defs> above the line, regardless of whether they're stock or not. This obviously has the downside that for people who use a lot of stock markers, the menu will get cluttered, however I suspect that may be a less common use case than we thought initially. Also, a more important underlying change is that in order to do this I've added some svg preview cache code based on code used by the icon renderer. This allows us to render each marker preview once, instead of three times (once for each menu), and avoids performance trouble if the marker menu is dynamically changed. (I needed to dynamically update the marker menus when selecting stock id's to ensure that if you select a stock id, it immediately shows up in the above-the-line markers in all three menus.) This will also eventually help solve a problem where if you have the fill-and-stroke dialog open when switching between two docs with custom markers, it doesn't update properly; I haven't fixed this, but just need to figure out how to hook in with the callback for "document selection changed". (This dynamic marker menu underlying structure is also needed for future anticipated changes to the marker system...) Bryce

4 6

Senior Project: SVG Crush
by Ted Gould 21 Feb '07

21 Feb '07

Hey, So as we're talking about GSoC I also realized it's time to come up with an idea for a senior project. Here's the one I'm thinking about proposing. I'd love it if anyone has any ideas or suggestions about how to improve it. SVG Crunch SVG is a XML vector graphics format standardized by the W3C for use in the Web. It is currently supported by most major browsers and is increasingly being seen on websites. As it continues to grow in popularity economic pressures will start to come into play. Even though bandwidth has become cheaper, it is still not free. This project is to create a utility to remove excess information in an SVG file to reduce its overall size. Phase One -- Basic XML compression -- There are some basic things that can be done to an XML file to make it smaller. Things like removing spaces and carriage returns. Also renaming name spaces from things like "mathml" to "m". The optimizations are simple but important. At the end of this phase the file should be no different to an XML parser. Phase Two -- SVG Compression -- SVG provides several ways that file size can be reduced as part of the format. These some of these include: using a "pointer tag" (use) to refer to objects that are identical; allowing style to inherit down the XML hierarchy; groups to take style for a set of objects; and many more. These optimizations should be applied to the document in order to reduce the size of the file. At the end of this phase the files should render no differently on an SVG renderer. Phase Three -- Display specific compression -- As a vectored format SVG provides elements that can be rendered at any resolution, but rarely does a graphic on the web need to be zoomed in at 1600%. This phase of the compression should focus on removing the precision of numbers and in some cases removing points that are unnecessary based on a target resolution provided by the user. At the end of this phase the files should look no different to a human at the target resolution. This project will be developed and published as an open source project. It can be done in any language that has an XML library available for it. Thanks, Ted

2 1

8080s no more
by Aaron Spike 21 Feb '07

21 Feb '07

I think we've fixed the 8080s in the wiki urls. Try to prove me wrong. Aaron Spike

1 0

Fixed_g_ascii_strtod
by unknown＠example.com 20 Feb '07

20 Feb '07

Due to a recent compile error, I have found the following in fixed.cpp: /* * until 2004-04-22, g_ascii_strtod could not handle having a locale-based * decimal separator immediately following the number ("5,4" would * parse to "5,4" instead of "5.0" in fr_FR) * * This is the corrected function, lifted from 1.107 gstrfuncs.c in glib */ It defines a function fixed_g_ascii_strtod and config.h defines a macro to point g_ascii_strtod to fixed_g_ascii_strtod. Perhaps it is ok now to purge the fixed function from our code and use the normal function? (trying to build now with "#define g_ascii_strtod fixed_g_ascii_strtod" commented out, but since that'll take a while a decided to already mail this) Cheers, Johan

3 4

Google Summer of Code 2007
by Tobias Jakobs 20 Feb '07

20 Feb '07

Hi, Google is doing it again. Here is the link: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Regards, Tobias

12 22

"Implementing UI Changes"
by Bryce Harrington 20 Feb '07

20 Feb '07

There is definite "method to the madness" for making UI changes, but afaik there hasn't been a definitive location for outlining the general guidelines on UI changes. Perhaps the best place would be in the Inkscape Developer's Manual, so I've started a section here: http://wiki.inkscape.org:8080/wiki/index.php/DeveloperManual#Implementing_U… Please review and add. I don't think we need exhausting details, just explain what the general motivations/principles are that Inkscape UI developers should strive to follow. Bryce

1 0

SCaLE Roundup
by Ted Gould 20 Feb '07

20 Feb '07

Hey all, I thought I'd write up a quick summary of SCaLE, hopefully everyone else who was there can add to (and correct) what I've put here. -- The Booth -- I was a bit concerned that this year we'd just run into the same people as last year. That was definitely not the case. On the most basic level, I'd say that 50% of the people we talked to hadn't heard of Inkscape. We definitely got the word out there. But, I think there were some other notable conversations. - Both of the companies doing network monitoring are interested in doing network maps using SVG. I thought that was pretty cool. They were talking about SVG even before we talked to them. - We got visits from two people from studios in LA. I don't really believe that either will turn into anything, but it was interesting, and probably good to get buzz into that community. Interestingly, one asked if Inkscape was in RHEL 4, and I didn't know. I talked to the Redhat guys, and they built the package right there. There is now Inkscape for RHEL 4 :) - We met the editor of Linux Gazette, and his wife. Apparently she was needing vector illustration to make the move off of Windows. She was trilled to find a way to move to Linux. - We talked with a guy who works at RPI and wants to remove the Adobe CS from their curriculum and replacing it with Open Source tools. Apparently they don't really teach the tools, as much as they use them to teach about work flow. So each student has to buy the full suite for a minor amount of functionality overall. He's working to change that. - Linux.com stopped by. Their overview was pretty flattering, and now is on the Inkscape site. He asked if I'd do an interview, and I didn't realize it was going to be video. You can now watch me stumble over my words trying to say something insightful. - I did an interview with the booth next to us (everyone else was scared). They hired a 'booth babe' to make a video asking stupid questions of conference attendees. It was cute. But I have to harass John Tabor for giving me misinformation about the whole thing :) -- The BOF -- We had the bird of a feather which went very well. We were a bit shocked that they didn't leave the projector in the room, so Josh wasn't able to show all the artwork he collected from folks to show off Inkscape. John showed a little bit of mapping stuff as we had a good group of people huddling around his laptop. There were several people who just wanted to know more about Inkscape, but there were some experienced users also. In particular, there was a guy from Ticketmaster that uses Inkscape to prototype websites. Overall, it was a good crowd and discussion, and we could have definitely gone longer than the hour we were allotted. -- The Talk -- I gave a talk about Inkscape Extensions, with the goal of inspiring new developers to jump on board. I was really worried that it was going to go long, but I was actually about 10 minutes short. They said that it was going to be recorded, but it was not. Josh has some video, but the audio isn't good. Hopefully some post processing will help. For those who want to flip through the slides, they are here: http://gould.cx/ted/presentations/scale5x/ Overall, I think we did pretty good. It's always fun to get together with Inkscapers and hang out. Even promoting Inkscape some. Thanks go to everyone who helped out: Jon, John, Josh, Erin and Hillery. --Ted

6 7

I'm back... and whitespace
by Jon A. Cruz 19 Feb '07

19 Feb '07

Whew. After a not-too-fun delay, I'm finally back. I got a dev environment going based on Darwinports too, so I'm finally on GTK+ 2.10.7 instead of the 2.6 that Fink had stalled at. And for my first large commit, I fixed some DOS line-ends that had come around when I wasn't looking. I just wanted to point that out in case someone had been working in one of those files and gets some conflicts.

1 0

Cairo PDF
by Aaron Spike 19 Feb '07

19 Feb '07

I just looked through the last two months of the Cairo Mailing list. I found it encouraging that even though we don't have any Inkscape advocates working explicitly on perfecting Cairo's PDF output, they continue to move along and make advances. When we get around to fixing the gradient rasterization issue, I think it will feel really nice to a continuous (no matter how gradual) stream of PDF enhancements for free. Just a little extra encouragement, if anyone has the desire to look into this. As far as I know Miklós' patches are still waiting for some polish work: http://lists.freedesktop.org/archives/cairo/2007-January/009075.html http://lists.freedesktop.org/archives/cairo/2007-January/009080.html Aaron Spike

2 2

The Script Window
by Aurélio A. Heckert 19 Feb '07

19 Feb '07

Hi, I do not find anything about the "script window" of the Inkscape. I only know that i need to comple with "--with-python" and/or "--with-perl". How can i use this? An script hire can access the inkscape features? An internal API like: Inkscape::pathsUnion( $id1, $id2 ); Inkscape::pathsIntersection( $id1, $id2 ); Something like that? Thank you, Aurium -- -===================================================- . . Aurélio A. Heckert [ GNU/Linux ] / \ http://www.aurium.cjb.net ((__-^^-,-^^-__)) `-_---" "---_-´ Web Colaborativa: `--|o` ´o|--´ http://www.TWiki.org \ ' / Projeto Software Livre - Bahia: ): :( http://psl-ba.softwarelivre.org (o_o) Coop. de Tecnologias Livres: "-" http://www.colibre.com.br ------------------------------------------------- GNU/Linux User #312507 http://counter.li.org - - - - - - - - - - - - - - - - - - - - - - - - - ( ( ( http://www.midiaindependente.org ) ) ) -===================================================- "Se conhecimento é poder, que país governado por industriais dará a verdadeira educação? Cuidado com o feedback da miséria!" Tet Ramon "Eu temo pela minha espécie quando penso que Deus é justo." Thomas Jefferson

5 5