- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] extensions usability
by Jose Hevia 13 Mar '05

13 Mar '05

> Ted Gould wrote: > > Yes, I think the text needs to change -- but I think the dialog needs to > > stay. > > I'd like to recommend disabling the dialog, at least until it's pretty > common people will have most extensions. Let me tell you a story: I'm a inkscape user that eventually learned to use inkscape to make vector drawings. I use debian sid ,so I just made an update to apt-get.If you have used it you know how easy is to upgrade +30 programs at once.I was working hard until night for a deadline project so I just shut down the computer and didn't use this computer for some days when finished. Later ,I needed to open a SVG to work with and so it happened: One or more extensions failed to load!!! The failed extensions have been skipped... What the hell? (#?!(%$·#!!!!!).Something is crashed,but what?,I open inkscape from command line ,no indication.No help.Nada.Nil.Nothing. Simply ,I don't know what an extension here means,I only recently read the mailing list,and don't know.They are optional parts like extras or fundamental part? It says: [...]please refer to the error log located a[...]ooh, so it's an error. (If it wasn't inkscape will start without pushing an (annoying) OK button.) But it's strange ,I could use inkscape like I was used to and nothing breaks (but beware ,don't trust, something is broken and could make lost your important data). I didn't unmarked "Show dialog on startup" because if something is broken I don't want it to hide this fact. No need to tell you that I didn't read /home/xxx/.inkscape/extension-errors.log(or if I did don't remember), and it took me some time to connect the general update with this "crash".I thought it was inkscape having problems,then I notice something different with the program,had a look to about dialog to see that I just installed a new version. Sorry for my behavior, if I had no others things to do I'd do better Jose Hevia

1 0

'using namespace' considered harmful
by MenTaLguY 13 Mar '05

13 Mar '05

Guys, I've been noticing a lot of usage of 'using namespace' starting to creep into the codebase. With few exceptions, that's not a good thing... The reason is that as more classes get added to the imported namespace, a class or function may eventually get added that conflicts with one in your own namespace. Depending on the exact nature of the conflict, it may not result in a compile failure, but instead introduce subtle bugs into the compiled code (e.g. if overload resolution picks the wrong function). So, as a rule, please 'using' the individual classes or functions that you actually need. Do NOT 'using' an entire namespace, and especially DO NOT use any form of 'using' in the global scope of a header file -- that will pollute the namespace of every file that directly or indirectly includes your header. Current offenders: (header files with inappropriate 'using's that MUST be fixed) src/ui/dialog/align-and-distribute.h:using namespace Inkscape::UI::Widget; src/ui/dialog/document-preferences.h:using namespace Inkscape::UI::Widget; src/ui/dialog/export.h:using namespace Inkscape::UI::Widget; src/ui/dialog/fill-and-stroke.h:using namespace Inkscape::UI::Widget; src/ui/dialog/find.h:using namespace Inkscape::UI::Widget; src/ui/dialog/inkscape-preferences.h:using namespace Inkscape::UI::Widget; src/ui/dialog/messages.h:using namespace Inkscape::UI::Widget; src/ui/dialog/text-properties.h:using namespace Inkscape::UI::Widget; src/ui/widget/unit-menu.h:using namespace Inkscape::Util; (modules where individual 'using's would be better) src/ui/dialog/inkscape-preferences.cpp:using namespace Inkscape::UI::Widget; src/ui/stock-items.cpp: using namespace Gtk::Stock; src/application/editor-impl.cpp:using namespace Inkscape::UI; src/application/editor-impl.cpp:using namespace Inkscape::UI::Widget; src/io/ftos.cpp:using namespace std; src/svg/ftos.cpp:using namespace std; src/svg/itos.cpp:using namespace std; Please fix, thanks. -mental

1 0

NEW: more gradient stuff
by bulia byak 13 Mar '05

13 Mar '05

Some improvements since the last announcement: - All tools that were previously able to click to select (namely node, shapes, and gradient tools), can now do Shift+click (add to selection) and Alt+click (select under) exactly as the Selector tool. - Dragging a gradient handle with Ctrl+Shift will scale the entire linear or radial gradient around its center. - Gradient handles for each gradient are connected by blue lines for fill gradient and yellow lines for stroke gradient. - In gradient tool, instead of dragging, you can double-click an object to create a new gradient centered within the object's bounding box. If you have several objects selected, or if your selected object is behind another one, you can double-click with Ctrl to create gradients on selected object(s) without changing selection. - The selected gradient handle will intercept any color/opacity setting commands and apply them to the corresponding stop(s) of its gradient(s). This means that at least two-stop gradients can be completely edited without ever opening the Gradient Editor dialog. In particular, you can use these methods to change the color of the selected handle: + Dropper tool (for example, to blend a radial gradient onto background, select its outer handle and pick the background color with the dropper). + Paste style (if the pasted style contains both fill and stroke style, the stop will take the fill style). + Fill and stroke dialog [this does not quite work yet because the dialog switches to gradient button and won't let you edit the color] - Double-clicking any gradient handle will open the Gradient Editor dialog with that handle's gradient loaded and the corresponding stop selected in the list. - Before, the actual direction of the linear gradient was not always perpendicular to the line connecting it handles if the bounding box of the object was not a square. This is now fixed, though the fix only works for new gradients that you create (i.e. gradients in old files are not affected). In other news, Richard Hughes' text layout rewrite appears to have reduced the memory consumption on a text-heavy document by about 20%, and rendering is faster by the same percentage. Hooray! :)

3 2

Inkscape hangs; create rectangle, lock layer, select (root)
by xscd 13 Mar '05

13 Mar '05

Can someone confirm the following issue? I'm using Inkscape 0.41 (Feb 10 2005), installed via Debian package, in Debian with a dual-CPU Tyan motherboard. I can reliably cause this hang by doing the following steps: * launch Inkscape, and in the default new document, choose the rectangle tool and draw a rectangle * with the rectangle still selected and its handles visible, click the "lock layer" icon on the status bar at the bottom of the window * click the layer menu on the status bar next to the lock icon, and select "(root)" At this point Inkscape hangs and begins to monopolize the CPU(s). Thank you, Steve D, New Mexico, US -- ---------------------------------------------------------------- The difference between a violin and a viola is that a viola burns longer. -Victor Borge ----------------------------------------------------------------

6 7

gradient editing strangeness
by Johan Forsberg 11 Mar '05

11 Mar '05

Hello, I *really* like the new "on canvas" gradient editing mode. However, the gradient editing still has a feature that I find puzzling. Maybe it's part of the svg standard or something and then it can't be changed I suppose. When editing a linear gradient, the line between the handles seems like it should represent the actual direction of the gradient, but it doesn't, exactly, unless the object has a perfectly square bounding box. If the bounding box is rectangular, the only directions in which the line and the direction of the gradient are the same are horizontal and vertical; all other directions the gradient appears "sheared" ('m not sure if this is the correct term); it is not parallel to the line. (This is a bit hard to explain, perhaps I should make a screen shot to demonstrate what I mean?) Even more confusing is the fact that this behaviour does not change even if the object is resized to have a square bounding box. This sometimes makes it difficult, for example to fine-tune a gradient on a very long and thin object, depending on its orientation. I don't know it I should report this as a bug or if there is some rational explanation :) Cheers, Johan Forsberg

2 2

Absolute paths for website
by Jonathan Leighton 11 Mar '05

11 Mar '05

I've been working on a prototype of the Inkscape news using WordPress, but am having trouble as URIs for archives come out like "/archives/2005/01/". Due to the relative paths used on the website, the browser then can't locate the stylesheets, and links point to the wrong place on those pages. So... does it matter if I change to absolute paths? (Which, IMHO, are better anyway) -- Jonathan Leighton aka. Turnip http://turnipspatch.com/ | http://digital-proof.org/

5 10

Please help fixing i18n bug
by Samphan Raruenrom 11 Mar '05

11 Mar '05

Please help fixing the bug 1093864 http://sourceforge.net/tracker/index.php?func=detail&aid=1093864&group_id=9… It renders Inkscape almost useless for Thai (and other CTL languages). I guess any nonspacing combining character, no matter what language it is, shouldn't work too. Please tell me if there're anything I can help (e.g. test cases, I can't attach the file to the issue). Thanks. -- _/|\_ Samphan Raruenrom.

2 5

Duplicating libcroco code in Inkscape tree
by Peter Moulder 11 Mar '05

11 Mar '05

I am working on supporting non-inline CSS stylesheets, by using libcroco (a C library for CSS parsing and determining what CSS properties apply to a given element). Not quite: libcroco 0.6 (the most recent released version) isn't really suitable for Inkscape's use for finding what properties apply to a given element: it requires a libxml in-memory representation of the document tree rather than allowing use of our preferred Inkscape::XML::Node. (See near end of http://www.inkscape.org/cgi-bin/wiki.pl?CSS_Support for more details.) I have prepared some modifications to libcroco to make this more suitable for us, and I've gradually been feeding patches to the libcroco maintainer, but that will take some time for all the changes just to reach CVS, let alone be released as libcroco 0.7, let alone be available on a reasonable number of our users' systems. There are two main ways of addressing this that I'm considering: i) Put our own version of the rule selection code (cr-sel-eng.{c,h}) into Inkscape, and make it play nice with an installed (external) copy of libcroco 0.6. ii) Put all of libcroco into the Inkscape source tree. For (i), there are two aspects of "playing nicely with installed libcroco": - Getting `#include "cr-foo.h"' to find cr-foo.h (usually referenced from user apps as `#include <libcroco/cr-foo.h>'). The simplest approach is to change all `#include "cr-foo.h"' to `#include <libcroco/cr-foo.h>'. This is my preferred approach at the moment. It's tempting to try instead to get `-I/usr/include/libcroco-0.6/libcroco' (or whatever the path on the user's system) into our INCLUDES variable. This approach would be pleasing in its simplicity, and would also slightly reduce work in merging changes back into upstream libcroco. However, given that the exact path varies from system to system, the best I can think of involves adding to configure.ac something like ink_cr_incl=`pkg-config --cflags libcroco-0.6 | sed 's, .*,/libcroco ,'` INCLUDES="$INCLUDES $ink_cr_incl" (while retaining libcroco-0.6 in a PKG_CHECK_MODULES call, which would take care of LDFLAGS and error handling). Not too big a deal, but then neither is the #include-changing alternative. - Avoiding linkage errors from having cr-sel-eng symbols both in Inkscape's internal libraries and also in installed libcroco. Is there some linker options to avoid this? Otherwise, the alternatives are either to #define all the external symbols of our own cr-sel-eng to something else, or to convert cr-sel-eng.c to C++, which I believe should give different linker symbols (mangled); we could wrap in a namespace{} too if we want. My local copy uses the convert-to-C++ approach. It involved adding explicit casts in a dozen or so places (no implicit cast from void* in C++, no treating enums as ints). Approach (ii) has at least the following advantages & disadvantages: Advantages: - All libcroco source files can stay in C and can retain their existing #include text. - It guarantees us that libcroco is available. Otherwise we must choose between either: - Requiring libcroco (and bundling on some platforms with poor package management -- can't they all just use Debian? ;-) ); or - Using `#ifdef WITH_LIBCROCO' in the source code, and accepting that not all builds of 0.42 (or whatever) will be able to read SVG files using non-inline style. Disadvantages: - Makes Inkscape source tree about 1MB bigger, and increases Inkscape's memory usage at runtime. - Any bug fixes to libcroco would have to wait until at least one release of Inkscape before being fixed. This is most of concern if the bug fix is security-related. Licensing doesn't seem to be a problem: libcroco appears to be LGPL. I haven't yet checked with the libcroco maintainer for his comments; I'll bcc him. Can people add to this list of advantages & disadvantes, or suggest alternatives, or give other relevant information? pjrm.

7 18

icon issues
by bulia byak 11 Mar '05

11 Mar '05

Jon, a couple small icon-related things: 1 when double clicking a guide to open guide dialog, i get ** (inkscape:24066): WARNING **: failed to load icon 'guide_dialog' 2 launch, ctrl+n to open a new window, ctrl+q to quit: (inkscape:24082): Gtk-CRITICAL **: gtk_size_group_remove_widget: assertion `GTK_IS_SIZE_GROUP (size_group)' failed

2 3

icon preview?
by bulia byak 10 Mar '05

10 Mar '05

Jon, what is this new icon preview dialog? Is it temporary?

4 6

text recommended reading: W3C charmod
by unknown＠example.com 10 Mar '05

10 Mar '05

Recommended reading for anyone here working on text stuff: http://www.w3.org/TR/charmod/ -mental

1 0

New text layout code
by Richard Hughes 10 Mar '05

10 Mar '05

I've just committed the first part of my text layout rewrite. The patch got a little excessively large so there's bound to be breakage somewhere (probably a lot of places). If you assign any bug that looks to be my fault to me (cyreve) that would be helpful. It's a little sparse at the moment, but I'm hoping to ramp up the features fairly quickly now I've got a decent base to work on. Known regressions: 1) Things go wrong if you delete a line break and then add one in the same place. I know exactly what I need to fix. 2) Linespacing was implemented as a custom attribute on the <tspan> fields. I want to move this into the css before I enable it (it's neater if everything is in SPStyle) but will, of course, retain backward compatibility with old files. 3) Likewise justification on <flowtext> (although I don't imagine anybody's seriously using this currently). 4) flowtext editing on the canvas didn't work very well before, and it still doesn't work very well. 5) I think vertical text is probably broken. It's been a while since I tried it. The old implementation was actually wrong according to the css spec, because the latin glyphs should have been rotated 90 degrees by default. New stuff that works now: 1) share/examples/flowsample.svg renders the rtl portions correctly 2) Up/down movement in text goes straight up and down, rather than going to the same character index in the line above. Also, it doesn't jump from one side of the gap in flowsample.svg to the other. It still drifts a bit over repeated up/down because I've left some compatibility layers in. 3) Insertion and deletion of text with styles should keep the XML tree a bit cleaner than before. 4) Um...I made the cursor go italic when you're over italic text (well I thought it was cool). This doesn't work for Bitstream Vera because oddly enough they didn't specify the angle of the italic text in the font file. New stuff that will work in the short to medium term: 1) Editing <flowtext> 2) Line spacing, full justification and whatever other 'easy' css properties I can find 3) Text selection, maybe a text toolbar too if I can persuade Bulia to write it for me :-) New stuff that will work eventually: 1) Moderately complete css3 Text functionality 2) Anything else that I dream up along the way That's it I think. Now I just wait for the bug reports to fly in. Richard.

3 5

printing
by herve couvelard 10 Mar '05

10 Mar '05

Hello, just une question, when it come to printing (wokrs fine). a ps files from inkscape show : <snip> %!PS-Adobe-2.0 %%BoundingBox: 0 0 596 842 %%HiResBoundingBox: 0 0 595.276 841.89 0 841.89 translate 0.8 -0.8 scale gsave [1 0 0 1 0 0] concat 0 0 0 setrgbcolor <==== taht is real black there newpath 47.4377 88.6988 moveto 47.4377 113.095 lineto 70.4789 113.095 lineto 70.4789 88.6988 lineto 47.4377 88.6988 lineto closepath </snip> but the printer (HP desjet 1220C - inkjet printer - cups hpijs driver) use black+color cartridges where/how can track that down to make her print only with black cartridge for black text ? Thanks in advance hervé

1 0

Re: [Sodipodi-list] Re: I can't admin the project after all
by Jon Phillips 10 Mar '05

10 Mar '05

On Wed, 2005-03-09 at 21:19 -0500, Pat Suwalski wrote: > Michael Schumacher wrote: > > Is there anything in Sodipodi that's not in Inkscape? Probably nothing > > except the more modular interface, and this is currently being worked on (in > > the direction of GIMP-style tabbed docks, AFAIK). > > There is one feature that was added shortly after the fork, and that is > applying transformations. So, if a point drawn at [0,0] was moved x+5 > and y+3, then applying would make its actual coordinated [5,3]. I can't > seem to find equivalent simplification commands in Inkscape, and I > certainly use them as it makes things like rotations and such far more > compatible. > I've forwarded this to the Inkscape list, as it has been talked about before. If it is useful, then it should get a look at...especially, if you all would like to see in Inkscape. Jon > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Sodipodi-list mailing list > Sodipodi-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sodipodi-list > -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

No more dialogs!!!
by Jon A. Cruz 09 Mar '05

09 Mar '05

I just wanted to say... We should not be coding dialogs any more. Instead we need to keep in mind breaking things down and making them reusable. One thing would be to avoid subclassing Gtk::Dialog. Instead we should have things more generic, and come up with a generic class based on Gtk::Container. These composit widgets could then be wrapped in a Gtk::Dialog for convenience, but then they could also be dropped into tabbed pages of a notebook, set vertically in a single window, etc. And then in our code, we should try to avoid the physical concept of "pop up the style dialog", and instead replace it with the logical concept of "present the style chooser to the user". That's a very subtle difference, but can help in lots of areas. Also... are there any other components we should come up with? Right of hand I can think of one in the 'Icon Preview' dialog I'm working on. It probably needs an document chooser, much like on the GIMP's layer dialog. However, others might need this too, so I was thinking it would be nice to have it generic and as reusable as the 'current color widget'. Anything else?

5 6

Icon loading changes
by Jon A. Cruz 09 Mar '05

09 Mar '05

I just did a big change in the behavior of Inkscape icons. Funny thing is, it's a net reduction in lines of code. Anyway, now when it goes to build an icon, it first asks GTK+ if there's a stock image of that name. If so, it loads it on up. And it also returns the stock GtkImage instead of a new instance of SPIcon built from an extracted bitmap. One of the things is that now the stock icons being used will reflect the current theme, when before they'd always be the default GTK+ stock icons regardless of what theme was being used. Also... if the theme is changed will the app is open, they stock icons will now change to stay in step. Perhaps we should use more stock icons. Perhaps we should get inkscape ones pushed out into standard stock land. Perhaps we should have nice SVG inkscape theme sets to switch when main themes are changed. Perhaps... Anyway, play around and see what comes up.

8 12

Icon preview
by Jon A. Cruz 09 Mar '05

09 Mar '05

It's a little buggy, but go ahead and check out the initial cut of "Icon Preview" under the View menu. I mainly just put stuff I needed for debugging into a dialog. Just hit "refresh" and it will render the top desktop's selected item as icons in different stock sizes.

2 2

bug with gradient editing
by David Christian Berg 09 Mar '05

09 Mar '05

Hey Bulia, just found a bug with gradient editing. Steps to reproduce: 1. Create a Text 2. Apply a gradient to the text 3. Delete the text 4. Undo deleting the text 5. Try to edit the gradient or switch to a solid fill. It won't work If you can't fix it right away, I'll file a bug report against it. Take care! David

5 8

Layer Merging, and Merging Groups of layers.
by Alan Horkan 08 Mar '05

08 Mar '05

[sorry, deleted old posts had to start a new thread] I said I'd take a look at how Adobe Photoshop handles groups of Layers and I was able to check Adobe Photoshop 7 and to be honest I wasn't impressed. Adobe Photoshop allows you to have lots of seperate layers and it also allows you to create what looks like a folder in the Layer Palette so that you can put Layers inside the folder and group them together. What I'm unimpressed by is that they depending on what you have selected - a Layer or a Layer Group Folder - the menu entries for "Layer, Merge Down" (and the other one) dynamically change lables and offer to Merge Layer Set. (I'm not sure about the specific wording, I only have very limited access to proprietary multimedia software so I'm describing this from memory). If you are usign the Merge Down function and you hit a Layer Group in the stack you are stopped dead. No attempt is made to move into the group and merge the next layer, no prompt is given offering to merge the whole group or just the next layer. The workflow stops, dead end. Inkscape cannot copy the dynamically changing menu behaviour because dynamically changing menu items almost always make for a bad user interface and even worse accessibility. However I do think this could be done better, my initial suggestion would be if "Merge Down" hits a Layer Group there would be a prompt offering to "Merge Next Only" or "Merge Group" but it is only a suggestion as I'm fairly sure Bulia has some implementation ideas of his own Hope that helps. If you want me to get screenshots or try to better describe how Adobe Photoshop behaves please do ask. Sincerely Alan Horkan Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://www.abisource.com

2 1

Fix for Inkscape execstack marking
by Mike Hearn 08 Mar '05

08 Mar '05

Hi, I have fixed the problem reported by Ivan Gyurdiev. As the MMX assembly does not appear to require an executable stack, the attached patch provides a .GNU-stack section allowing it to be protected. As you can see the stack is marked RW not RWE: mike@...646... src $ readelf -aW inkscape|grep GNU_STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 This patch will take effect in the autopackage nightly builds immediately (because that tree is where I wrote it). It's been put in the bug tracker here: https://sourceforge.net/tracker/index.php?func=detail&aid=1157714&group_id=… thanks -mike

2 1

Open Clip Art Library Release 0.11 Announcement
by Jon Phillips 08 Mar '05

08 Mar '05

Open Clip Art Library Release 0.11 Announcement March 8, 2005 UTC - Release 0.11 of the Open Clip Art Library (www.openclipart.org) is now available for download on-line as an individual package consisting of 2896 images submitted by over 200 artists from around the world. Some of the new clip art received this month includes more images of food, computer-related items and even a little boombox. In addition to the collected 0.11 package, each clip art file can now be found by keywords using developer Jonadab's new Keyword Search Tool. The Open Clip Art Library is growing rapidly because of increasing submissions from artists. Currently, the top five artists in terms of the amount of clip art submitted are: Danny Allen (951 images), Nicu Buculei (456), Jose Hevia (453), Andy Fitzsimon (250), and Alan Horkan (119). These Artist's and others contributions are the life blood of the Library. While the critical unit of contribution in traditional Open Source is code, it is a little different with the Open Clip Art Library project in that an actual clip art donation is just as helpful as the code supporting it. For March the Open Clip Art Library encourages submissions of clip art related to the concept of "Spring." In the coming months as the library grows in size, the project needs new developers to help build tools to process this growing repository. Upcoming planned features that the project needs assistance on include capturing and tracking of clip art requests, user account management, adding WebDAV support, and developing wizards to aid in composition. Use the following URLs to download the latest release of the Open Clip Art Library: http://www.openclipart.org/downloads/0.11/openclipart-0.11.tar.bz2 http://www.openclipart.org/downloads/0.11/openclipart-0.11.tar.gz http://www.openclipart.org/downloads/0.11/openclipart-0.11.zip http://www.openclipart.org/downloads/0.11/openclipart-tools.zip The Open Clip Art Library (http://www.openclipart.org/) aims to create an archive of clip art that can be used freely for any use. All graphics submitted to the project are placed into the Public Domain according to the Creative Commons Public Domain Declaration.

1 0

Re: [Inkscape-devel] gradient tool bug
by bulia byak 07 Mar '05

07 Mar '05

On Sun, 06 Mar 2005 23:19:26 +0100, Jakub Steiner <jimmac@...653...> wrote: > My question is exactly the other way around. If node editing tool is for > editing a shape, why have it define a gradient? In Sodipodi, you had to switch to node edit after having created a rectangle if you wanted to round corners. The rect tool could create a rect but not edit it. That was obviously crazy. I fixed that. Then we added on-canvas editing of pattern fills. It shows up whenever you have the shape handles or nodes (i.e. in node tool and all shape tools). This turned out to be quite convenient (at least for me). Now with gradients, I just followed the general trend, which is this: Each tool _creates_ objects of its type and allows for precise numerical control of them, but simple on-canvas _editing_ should be available everywhere for all objects. I think this is a good idea overall, though obviously in some cases it may lead to too much stuff on canvas. I don't think however that gradients are one of these cases. Does anyone else have an opinion? > sure about other artists, but I have a workflow where I first worry > about the shape and later on worry about the shading. I have no need to > be doing both at the same time. I often adjust shape and fill at the same time, and not having to switch tools is convenient for me. > > What about this: when no gradient handles are selected (all are > > white), it works as now. When a handle is selected (blue), the list > > will show (and let you change) the gradient definition for that > > handle's gradient. > > I fear this behavior isn't exactly obvious. Seeing that something is selected (blue) and assuming that the "Change" controls affect the selected thing is much more obvious IMHO than having some obscure "mode switch" in the toolbar. > What does showing both fill > and stroke gradients at the same time give you? It gives consistency and simplicity, above all. I select an object and I see _all_ of its gradients without having to think about modes and such. > The only thing obvious > to me is locking the vector of both gradients to be precisely the same. Yes, this is an advantage too. > Yet this is hardly an advantage even if it wasn't limited for both > having the same gradient applied (which is truly useless). It's not _thus_ limited. You can assign the different definitions to the gradients first and merge them after that. Even simpler, you can easily shift-drag one of the merged handles away, apply a different gradient to it, then merge it back. Then you will still be able to drag the merged gradients together, even though they will now have different gradient definitions. So it's not even a limitation, just a minor inconvenience. > I'm not > saying there isn't any. I just don't see it and I'm asking for a use > scenario. You said yourself (below) that merging gradients from different objects is useful. Now imagine that one of the objects is a fillless stroke and the other is a strokeless fill. I want to form a "virtual object" out of them by merging their gradient handles. With your proposal ("modes") this would be impossible - not just inconvenient but impossible. > I understand you have all this coded and you are motivated to justify > this design. In the end I will accept whatever there is, since I hardly > have any choice, but I strongly believe separating the two will lead to > a better interface that gives feedback on what's happening. I think it will just add a redundant control which will make the whole system less obvious and less discoverable by novices. I don't see what is the additional feedback that it will give you which my system would not give. > Snapping within multiple objects is useful for having a multiple object > form a "virtual" object. You may want to draw a car body structure and > keep the dashers separate. So the objects share the same shading. > > I don't see the need for having a precise snapping of stroke/fill > gradients if the gradient is supposed to be the same. In the end it just > gives the same result as having the object have no stroke. 1) Gradient definition does not have to be the same (see above) 2) Even if it's not useful for the same object's fill and stroke (I'm not sure why you think so, but OK), I think you can easily imagine wanting to form a "virtual object" from some objects without fill and others without stroke. > > Can you explain why would you need to switch a gradient from linear to > > radial, preserving the handle positions? This seems far-fetched to me. > > Why is this any better than simply drawing a new radial gradient for > > the same objects instead? > > See yourself adding the "New:" label? The interface doesn't speak on its > own, you had to describe its behavior because clicking on the button > doesn't give immediate feedback. You are right that in most cases I > continue to redesign the gradient placement, but the interface gave me > an immediate feedback on my actions as opposed to the current design. Even if I add a button to switch the selected gradient between linear and radial, this would be a separate button from the one which governs the newly created gradient. (Or are you proposing to always create linear and then, if needed, switch it to radial? That would be quite cumbersome.) And since the usefullness of the radial/linear switch for _existing_ gradients is not obvious to me, I think leaving only the control for _newly created_ gradients makes sense and reduces clutter. The fact that the "New:" part applies to newly created gradients is explained in the tooltips. Besides, this is consistent with the shape tools which, too, display "New:" when no objects of their type are selected, in which case adjusting the controls will affect newly created objects.

3 6

--new-gui
by Bryce Harrington 07 Mar '05

07 Mar '05

I've fussed around with the autoconf/automake stuff and in theory now you should be able to run `inkscape --new-gui` and see something other than a segfault. If so, great, if not, lemme know. I suspect due to a newly added share/ui directory, you will probably need to re-run autogen.sh and configure. Bryce

2 2

icons breakage
by bulia byak 07 Mar '05

07 Mar '05

Jon, in today's CVS: - There's a noticeable delay after the program window appears and before it shows icons in toolbars. It never happened before. - You removed the possibility for toolbars to be cut. Why? Now the window starts up wider than before, and if we add more controls to the selector toolbar it will have to be wider still. Moreover switching tools (e.g. switch to star) may resize the window, which is very annoying. Please fix this. Besides, you removed the only place where the "detach" flag was checked but did not remove its setting. This flag was added to make sure a detached toolbar is not cut while the attached one may be cut by the window. I think this must be restored.

2 5

layer commands we need
by bulia byak 07 Mar '05

07 Mar '05

Here's a list of layer commands that we need to implement, comments and additions welcome: Layers... // opens the Layers dialog ------------------- Move to Layer Above Shift+PgUp // move selection to the top of sibling layer above, or to the top of parent layer (but not root) if no siblings Move to Layer Below Shift+PgDn // move selection to the top of sibling layer below, or to the bottom of parent layer (but not root) if no siblings Move to Layer... // let me choose the layer name to move selection to ------------------- Unlock All Layers // unlock all layers in the document (or all siblings of the current layer?) Unhide All Layers ------------------- Unlock All in Layer // unlock all children of the current layer Unhide All in Layer ------------------- Group to Layer // convert group to layer Layer to Group

4 16

gradient bug? icons
by David Christian Berg 07 Mar '05

07 Mar '05

Hey guys, have a look at http://home.tu-clausthal.de/~dcb/gradients.png I've no clue, why that is... the one end is on top of the other, but instead of having just two plain areas it looks like in the screenshot. Anyways... icons: http://home.tu-clausthal.de/~dcb/icons.svg they still need some work, but... enjoy! David

3 9

NEW: gradient tool
by bulia byak 06 Mar '05

06 Mar '05

New in CVS: The Gradient tool (Ctrl+F1 or the g key) is a new convenient way to create, edit, and manage gradients: o Simply drag anywhere on canvas to create a gradient on selected objects. Existing gradients can be edited by dragging their handles (as in any tool that has on-canvas gradient editing enabled). o The tool's controls bar lets you choose the type of the newly created gradients (linear or radial) and whether they will be applied to the objects' fill or stroke. o For the gradient(s) of selected object(s), you can choose one of the gradient definitions in the document from the drop-down list in the controls bar. The Fork button creates a copy of the selected gradient definition and applies it to the selected objects, which is useful when you have several objects sharing one gradient definition but want to change that. The Edit... button opens the gradient dialog where you can edit the gradient definition (add/move/delete stops and change colors and opacities of stops). o The selected (blue) on-canvas gradient handle can be moved by arrow keys with all the regular modifiers (Alt ro move by 1 screen pixel, Shift to move by 10 times the distance). The Tab and Shift+Tab keys let you move selection from one handle to the next or previous. This functionality is largely equivalent to that of the Fill&Stroke dialog, but is much more convenient. Still TODO: - toggle buttons for spread (none/reflect/repeat) - button/dialog to rename selected gradient definition - X/Y spinbuttons for the position of the selected handle - the ability to assign color to the selected handle, so it's possible to edit at least two-stop gradients without opening the gradient editor - additional draggable handles for multi-stop gradients Also today I eliminated the old gradient position widget in Fill&Stroke as redundant. I'm thinking about removing the remaining gradient controls there too ("vector" list, Add/Edit, spread) because they are a duplication of what is available in the gradient tool, and have no added advantages in the dialog. All these changes were rather disruptive, so please test everything thoroughly. Of course any feedback on the usability, terminology (e.g. I had to invent the term "gradient definition" for that color strip with stops that can be applied to objects' gradients; Sodipodi termed them "vectors" which is incredibly misleading), or anything else is welcome.

5 6

mozilla futures
by Jon Phillips 06 Mar '05

06 Mar '05

You guys might have a look through these slides to see about mozilla + svg developments: http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/ As you all know, mozilla svg is in the mozilla trunk now. Jon -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

Inkscape crash while drawing a gradient
by Jean-François Lemaire 06 Mar '05

06 Mar '05

I just made Inkscape CVS crash while "drawing" a gradient. Here is the output from the terminal: (inkscape:21590): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject' (inkscape:21590): GLib-GObject-CRITICAL **: file gobject.c: line 1642 (g_object_get_data): assertion `G_IS_OBJECT (object)' failed ** ERROR **: file desktop-handles.cpp: line 31 (SPSelection* sp_desktop_selection(SPDesktop*)): assertion failed: (desktop != NULL) aborting... Emergency save activated! Cheers, Jef

2 1

Hacking on icon stuff
by Jon A. Cruz 05 Mar '05

05 Mar '05

Just wanted to let people know I'm in the middle of hacking on icon loading. My immediate goal was to get rid of the ugly rescaling and blurring of the stock icons. But in doing that I should also be able to get rid of all hardcoding of sizes. So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.

9 24

Some icons for the layer menu
by Jean-François Lemaire 05 Mar '05

05 Mar '05

Hello, I just finished drawing some simple icons for the layer menu; it looks too empty to my taste. I don't know if they will be of any use, but anyway, where can I post them for the world to see? The SVG is 47K. Cheers, Jef

2 1

Potrace 1.6, first try
by Bob Jamison 05 Mar '05

05 Mar '05

Peter Selinger recently released v1.6 of his tracing engine. I think that it is fairly well interfaced with our stuff, though I did have some problems with CVS. I -think- that the build is working fine again now, but in case any turn up missing while I am gone, I left a copy of the subtree here: http://troi.hous.es3.titan.com/inkscape/files/trace.tgz Just replace the missing files, not the whole thing. By the way, the tracing is MUCH faster now. Bob

1 1

Builds
by Bob Jamison 04 Mar '05

04 Mar '05

I have been more regular with Win32 builds lately in this dir: http://troi.hous.es3.titan.com/inkscape/builds Just look for the latest InkscapeYYMMDDhhmm.zip file. The one for this morning is: http://troi.hous.es3.titan.com/inkscape/builds/Inkscape0503040733.zip In the very near future, I'm going to attempt to gather and build -all- of the sources to get gtkmm/libxml/etc working on W32 without the use of other people's binaries (OPB), so that we can have a clean dependency tree of our own. Maybe supply a single source bundle and a build script to simplify the build for others. On another note, I also occasionally build a copy of firefox with svg/cairo on FC3. It seems to work on my recent Gentoo install nicely, too. It is here: http://troi.hous.es3.titan.com/inkscape/files/firefox-i686-linux-gtk2+xft+s… (built today). I attached the .mozconfig that made it, in case anyone wants to build their own. A good test is to look at the svg files on http://croczilla.com/svg Bob . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir ac_add_options --enable-svg ac_add_options --enable-svg-renderer-cairo ac_add_options --enable-system-cairo ac_add_options --disable-ldap ac_add_options --disable-calendar ac_add_options --disable-mailnews ac_add_options --enable-extensions="cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth" ac_add_options --enable-crypto ac_add_options --disable-composer ac_add_options --enable-single-profile ac_add_options --disable-profilesharing ac_add_options --disable-shared ac_add_options --enable-static ac_add_options --disable-debug ac_add_options --enable-toolkit-gtk2 ac_add_options --enable-default-toolkit=gtk2 ac_add_options --enable-xft ac_add_options --disable-freetype2 ac_add_options --disable-tests ac_add_options --disable-accessibility ac_add_options --disable-installer ac_add_options --enable-strip ac_add_options --disable-toolkit-qt #ac_add_options --enable-optimize="-O2 -march=i686" ac_add_options --enable-optimize="-O2" ac_add_options --enable-official-branding

1 0

Website news section CMS
by Jonathan Leighton 04 Mar '05

04 Mar '05

We previously discussed the idea of using a CMS such as WordPress to handle the news part of the Inkscape website. No real conclusion was reached, so I thought I'd send out this email asking for votes/opinions for and against. If we decide to go for it then I could probably get it done this weekend. Cheers, Jon -- Jonathan Leighton aka. Turnip http://turnipspatch.com/ | http://digital-proof.org/

5 9

Donation received
by Bryce Harrington 04 Mar '05

04 Mar '05

I got a donation from 'OSDN / VA Software' for Inkscape the other day, in the amount of $3.54 ($5 less PP/SF fees). I'm not sure what to do with it... I'll hold onto it for now until we either get a general fund set up, or it's needed for something for the project. The breakdown of the transaction appears below: Donated amount...........................: $5.00 PayPal fee...............................: $0.46 SourceForge.net fee......................: $1.00 TOTAL TO YOU.............................: $3.54 Comment from the donator: make inkscape even better - be blessed! Thank you The SourceForge.net Team Bryce

1 0

Inkscape Project Status Mar 1st
by Bryce Harrington 04 Mar '05

04 Mar '05

Well, SourceForge is still way behind in their stats, but here's the rest of the stats. Statistics Jan 15 Feb 1 Feb 15 Mar 1 ========== ====== ===== ====== ===== Lifetime Rank on SourceForge: 570 569 * * (96.0%) (96.0%) * * Max Week's Rank on SourceForge: 59 * * * (99.6%) * * * Total SF Page Views 2,283,160 2,296,458 * * Total SF Downloads 114,695 115,645 * * Total Freshmeat URL Hits 14,634 15,108 16,448 16,885 Total Freshmeat Subscriptions 151 156 169 173 Lines of Code in src/: 323,251 323,324 333,139 338,993 Code lines 227,965 227,872 234,651 238,641 Comment line 56,308 56,438 58,239 59,589 Blank 45,664 45,624 46,859 47,484 Lines of Docs in doc/: 17,901 17,918 26,848 26,848 Lines of content in website: 9,328 9,486 9,776 9,979 Size of the Inkscape wiki: 20,931 23,576 24,925 25,094 Bugs open/total: 145/858 148/917 155/972 177/1019 Features open/total: 353/530 352/556 370/579 384/ 602 Patches open/total: 6/148 7/154 5/167 6/ 170 CVS Commits (as per inkscape-cvs) 9,625 9,975 10,312 10,600 Inkscape-devel membership: 131 143 151 152 Inkscape-announce membership: 155 166 169 171 Inkscape-user membership: 177 181 193 201 Num Translations: 33 33 33 33 Ave Translation Ratio: 42.0 44.7 47.8 45.0 * - Statistics unavailable

1 0

[osdl_staff] 2005 desktop developer's conference announced (fwd)
by Bryce Harrington 03 Mar '05

03 Mar '05

---------- Forwarded message ---------- Date: Thu, 03 Mar 2005 09:57:55 -0800 From: Randy.Dunlap <rddunlap@...1...> To: osdl_staff@...1... Subject: [osdl_staff] 2005 desktop developer's conference announced http://www.desktopcon.org/2005/ -- ~Randy _______________________________________________ osdl_staff mailing list osdl_staff@...701... http://lists.osdl.org/mailman/listinfo/osdl_staff

1 0

URGENT BREAKAGE: preferences loading/saving
by bulia byak 01 Mar '05

01 Mar '05

Someone's recent change (likely the repr changes by swingincelt) broke preferences loading and saving. Now upon exit, a new <inkscape> element with all its children is nested at the end of the ~/.inkscape/preferences.xml instead of replacing the existing <inkscape>. Thus the size of the file grows by 13K on each run of the program, and any changes you make to the prefs are not read next time you run. Please fix ASAP.

3 5

Adobe Illustrator CS SVG files + incompatibility
by Jon Phillips 28 Feb '05

28 Feb '05

My girlfriend just made all these images for the clipart library by tracing them in Inkscape (rock!) and then editing and composing them with Adobe Illustrator CS. However, they cannot be opened in Inkscape. I'm writing this to let everyone know that there are about 10 images available at this link, http://openclipart.org/submissions.php, done by Linda Kim that would be good for testing interoperability of Adobe SVG and Inkscape. I created a bug on this and a new category for import bugs. If this one fits your fancy, it should be easy to write a script to strip out what Inkscape doesn't support, as can be done by hand in a text editor. However, to get Inkscape to allow for various unsupported features, or compliant svg that we don't suppor yet, might be more difficult. http://sourceforge.net/tracker/index.php?func=detail&aid=1153207&group_id=9… Also, if anyone needs more examples, I can get those created in Adobe Illustrator CS. Jon -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

2 2

Inkscape.org and the image/svg+xml mimetype
by Bob Jamison 28 Feb '05

28 Feb '05

Could someone please add these entries to /htdocs/.htaccess on the web site? AddType image/svg+xml .svg AddType image/svg+xml .svgz Inkscape.org can't serve svg at the moment, which can potentially be embarassing. ;-) This might need to be added to the wiki code, too. Bob

2 3

SVG+Xforms demo
by Bob Jamison 27 Feb '05

27 Feb '05

One of the guys on irc.mozilla.org/#svg (nick: woo) showed me a demo of svg-enabled Firefox with the xforms extension from mozilla.org. It is a little calculator demo, implemented using svg and xforms. Very nice. http://artforms.progressivex.com/mozilla/svgcalc.xml Bob

1 0

web site proposals
by bulia byak 27 Feb '05

27 Feb '05

I'd like to propose two things regarding the Inkscape web site. Volunteers are welcome: 1 Create an RSS feed for the main page news. 2 Create a new header graphic to replace the boring white "Inkscape" on blue. As a graphic app, we are starting to deserve something more sophisticated. The web site itself is OK, I don't think we need to drastically change the entire design (although suggestions are welcome), but the top panel is decidedly dull and pathetic. Show off your graphic talent! Send your submissions to the devel list for people to discuss. The best one (if the winner is not obvious, we may need to do a voting) will make it to the site. One technical note: the banner cannot be fixed width, because our site is not fixed width - so it must be either one piece for the top left corner or two pieces for two corners, with some flat color fill between them. The minimum screen resolution is 800x600.

7 14

Press: Inkscape in Linux User and Developer magazine
by Alan Horkan 27 Feb '05

27 Feb '05

[If you do setup an RSS news feed using open source tools like Word Press I like to be allowed to post information like this.] Press: Inkscape in Linux User and Developer magazine Issue 47 http://www.linuxuser.co.uk/ "Graphic designer Miriam Clinton investigates the free software tools of her trade with a look at the Gimp, Cinepaint, Quanta Plus, Inkscape and Sodipodi." One of the plus points mentioned in the article and in noticable contrast to other projects was the welcome Miriam recieved from the Inkscape community (and the efforts to get her involved). I'm very proud of this ditinction and I think a lot of it can be put down to the maturity of Bryce and the other developers who always moderate dicussions and keep things calm and in perspective. I think this is a valuable asset to the long term health of the Inkscape project. She expressed her disappointment at the Text functionality but as we all know it is a work in progress and the interface will inevitably improve and Ms. Clinton did note that Inkscape is a fairly young 'alpha' stage project and gave a largely favourable and optimistic report. In comparision I think she was quite critical of GIMP, CinePaint and Sodipodi which is quite fair from the point of view of a Graphic designer but usually Linux magazines are very forgiving of Open Source applications (Graphic design magazines are usually extremely critical -- freedom of source and free cost doesn't cut any ice with them -- a flamefest even by comparison to Miriams review). Gotta go. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com

1 0

Re: [Inkscape-user] SVG Fonts
by bulia byak 26 Feb '05

26 Feb '05

On Fri, 25 Feb 2005 15:51:15 -0800, Landon Blake <lblake@...732...> wrote: > This is something I might be able to work on.....I've just begun learning C and GTK GUI programming, so that I can contribute to Inkscape development. > > Any idea how I might get started? Attached is an archive of several files that someone called massifr (sorry I don't know the real name) created some time ago. This is a beginning of implementation of svg:font, svg:fontface and svg:glyph. Really the files are almost placeholders, with little real code, but you still can use them as the starting point. The author (his email is in the files headers) said he won't continue to work on them, but you can contact him with questions. (As well as any of the developers, of course - use the devel list and the jabber channel for any questions you might have.)

4 3

GNOME 2.10 splash screen contest
by Bob Jamison 25 Feb '05

25 Feb '05

Here is something that an Inkscape user might find of interest: http://gnomedesktop.org/node/2168 Also, Gnoppix needs some graphics: http://www.gnoppix.org/wiki/index.php/Main_Page So this could be a way for an IS artist to become famous! Bob

1 0

Another Newsforge article that mentions Inkscape
by Bob Jamison 25 Feb '05

25 Feb '05

There is a follow-up to the "graphics apps integration" article from Newsforge a couple of weeks ago. Just posted! Here it is: http://software.newsforge.com/software/05/02/24/1818224.shtml Bob

1 0

Inkscape: PT_GNU_STACK RWE
by Ivan Gyurdiev 24 Feb '05

24 Feb '05

Hi, I've subscribed to this list just to post this one question. The inkscape binary is marked with PT_GNU_STACK RWE. This creates problems for the SELinux strict policy, and requires that special privileges be granted for inkscape as a "legacy domain". The question is, does inkscape really require an executable stack? I'm not a gcc expert of any kind, but from what I've read I understand that asm code causes gcc to mark the binary as requiring executable stack. I think it can be overridden with ld -z noexecstack. It would be a lot easier to write the inkscape security policy if it didn't require executable stack. -- Ivan Gyurdiev <ivg2@...729...> Cornell University

5 13

Inkscape.app for Mac OS X
by Aymeric GILLAIZEAU 24 Feb '05

24 Feb '05

I have succesfully built Inkscape 0.40-1 via Fink under Mac OS X 10.3 After I have moved to "~/Desktop/Inkscape.app/Contents" following the way explained for the Gimp.app The application lauches itself with a double-click and it is available there http://niwaconcept.free.fr//x11/Inkscape.zip But if it can be stored there that would be better. The file is 60 Mb do dwnload, and then 280 Mb for the software itself. http://www.inkscape.org/cgi-bin/wiki.pl?CompilingMacOsX ____________________ PowerMac G4 400 Mhz 1 Gb RAM Mac OS X 10.3.6 Ubuntu Linux PPC 4.10

1 0

Nice inkscape article on Linuxplanet
by Lucas Vieites 23 Feb '05

23 Feb '05

Hi, Rob Reilly wrote a nice tutorial on Inkscape for beginners: http://www.linuxplanet.com/linuxplanet/tutorials/5757/1/ Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

1 0

Gradient editing...
by John Cliff 23 Feb '05

23 Feb '05

Been playing with bulias on canvas gradient stuff, And its SO good. Its not quite Andys chrome, but I created this in half an hour or so's messing about. Cheers Sim __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

2 1

Gradient handle => Pattern handles?
by Alan Horkan 23 Feb '05

23 Feb '05

I was thinking how cool the gradient handles were and was wondering if it would be difficult to extend similar functionality to Patterns? (Should I file a request?) - Alan Horkan

5 5

Master Opacity and Marker question
by cedric 21 Feb '05

21 Feb '05

Hi, I'm back to User Manual. I 've been trying the Master Opacity, to explain its use. But when applied to Markers, only the path seems to be affected by the opacity changes. Is there another way to do ? PS to Bulia : Wonderful your new gradient handles !! -- Cedric ----------------------------- LISEZ -> SOS GIMP : http://www.le-radar.com/?mm/gimp mais aussi : http://wwww.le-radar.com http://www.cgemy.com

2 1

removing trivial wrappers
by Robert Crosbie 21 Feb '05

21 Feb '05

There are some wrappers that I'm not sure what to do with: This one below returns a value, but it is never checked. I assume a straight replacement is fine in this case and ignore the return value. inline unsigned int sp_repr_add_child(Inkscape::XML::Node *repr, Inkscape::XML::Node *child, Inkscape::XML::Node *ref) { repr->addChild(child, ref); return true; } There are others like this one below, where the value is actually checked somewhere. Should the ckeck be removed since it will always be true anyway? inline unsigned int sp_repr_remove_child(Inkscape::XML::Node *repr, Inkscape::XML::Node *child) { repr->removeChild(child); return true; } ... ok = sp_repr_remove_child (NODE_DATA (old_parent)->repr, NODE_DATA (node)->repr) && sp_repr_add_child (NODE_DATA (new_parent)->repr, NODE_DATA (node)->repr, ref); ... sp_repr_set_attr is another one that always returns true, but is used as a return value and in conditionals in a number of places. Should all instances of append_child be replaced with addChild? There are many, but it could be a Janitor item. void addChild(Inkscape::XML::Node *child, Inkscape::XML::Node *ref); void appendChild(Inkscape::XML::Node *child) { addChild(child, _last_child); } Cheers, -- Rob. http://woodpendant.com

2 1

NEW: on-canvas gradient editing
by bulia byak 21 Feb '05

21 Feb '05

Now in CVS: Gradient editing on canvas is now available, much more convenient and powerful than the old way of dragging gradient knots in the Fill&Stroke dialog. o Any number of selected objects can simultaneously display handles and direction lines for their linear and radial gradients (in the objects' fills or strokes). You can drag these handles directly in the drawing, to interactively adjust gradient positions. o Gradient handles can be enabled in the Node tool, shape tools, Text tool, and Dropper tool (on by default), as well as in Selector and Zoom tools (off by default). Use the Inkscape Preferences dialog to change this. o Any gradient handle, if dragged close to a handle of another gradient, will merge with that handle (drag with Shift to prevent merging). Dragging such a merged handle will adjust any number of gradients attached to it. To separate merged handles, drag them away one by one with Shift. o Radial gradients display handles in the center and at the ends of two radii, which allows you to move, rotate, squeeze, or stretch the gradient to form an arbitrary ellipse. Also, you can independently adjust the focus of the gradient; drag the central handle with Shift to separate the focus handle. o When dragged, handles will snap to the edges and the central axes of the bounding boxes of all selected objects (drag with Shift to prevent snapping). o Dragging with Ctrl will snap the angle of the linear or radial gradient to the user-settable angle increments (default is 15 degrees). The center of a radial gradient, dragged with Ctrl, will be constrained to horizontal and vertical movement relative to its previous position. When dragged with Ctrl+Alt, a handle moves along the gradient direction or its perpendiculars, allowing you e.g. to stretch or squeeze a linear gradient without disturbing its angle. Overall, this is a major usability milestone, something I dreamed to do since Sodipodi times. Gradients are one of the most widely used features in Inkscape, and now they are finally made usable (well, almost - see below). The old gradient position widget in Fill&stroke remains for now (and still works), but I plan to remove it as soon as the new on-canvas editing is sufficiently tested. I would welcome any feedback on the new feature. Next in my plans: A Gradient tool, which will allow you to actually create new gradients by dragging (at the moment you still need to open Fill&stroke to switch an object to gradient) as well as adjust most gradient settings in its controls bar at the top of the window. In that tool, the selected gradient handle will be moveable by arrow keys (with all the usual modifiers), and setting any color via Fill&stroke, palette, dropper, or Paste style will be applied to the selected handle's gradient stop (instead of the entire selected object).

15 43

cxxtestgen.pl
by Robert Crosbie 21 Feb '05

21 Feb '05

I'm getting this trying to compile from latest CVS has cxxtestgen.pl been checked in, or did I just not update correctly? cxxtestgen.pl -part -o libnr/test-nr.cpp ./libnr/nr-types-test.h ./libnr/nr-translate-test.h ./libnr/nr-rotate-test.h ./libnr/nr-scale-test.h ./libnr/nr-point-fns-test.h ./libnr/nr-rotate-fns-test.h ./libnr/in-svg-plane-test.h ./libnr/nr-matrix-test.h make[2]: cxxtestgen.pl: Command not found make[2]: *** [libnr/test-nr.cpp] Error 127 ... Cheers, -- Rob. http://woodpendant.com

2 1

Nightly build service statistics
by Mike Hearn 20 Feb '05

20 Feb '05

Hi, The nightly autopackage is currently being downloaded approximately 10 times per day, that is, there have been slightly more than 100 downloads in the past ten days. It's too bad the SF statistics system is offline at the moment, I'd be curious to know how many people were downloading the official packages. Oh well. thanks -mike

2 2

canvas border dropshadow
by Jakub Steiner 20 Feb '05

20 Feb '05

Hi there fellas! How would you feel about dropping the dropshadow for the document canvas border? It's visually distracting for small icons. While I'd like to have a very light outline to see where the edge is, I don't like the border taking too much attention away from the actual artwork and that's what happens thanks to its non-symmetric look. cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

8 15

Wiki change notices
by Bryce Harrington 20 Feb '05

20 Feb '05

Hey Kees, Can you set up that nifty weekly wiki-change notice you did at work, for use with Inkscape? Bryce

1 0

Re: [Inkscape-devel] Setting physical resolution and exporting
by unknown＠example.com 20 Feb '05

20 Feb '05

Hello! Thanks for the answer, but that did not work in the version I had used. I had just modified the generated postscript files instead. Best regards, Artur > <start-nasty-hack> > > Turns out, that the EPS save uses the Postscript output module, just > with it's own set of parameters. So, if you printed the file using the > postscript output, changing the values in that dialog. Then, you saved > as EPS, it would use the settings you just set in the print. > > I'm not saying this is a good thing, but I'm pretty sure that will work. > > </start-nasty-hack> > > > --Ted

1 0

OSX packaging
by Kees Cook 20 Feb '05

20 Feb '05

Well, with help from many people and activity on the IRC channel, I've blindly cobbled together some stuff for an OSX .app package. This basically works a lot like our Win32 package: all the libraries come along for the ride. (Which makes it giant: installed >100M, .dmg is 32M) New things in the CVS tree: - configure has --enable-osxapp which turns on my guesses at path locations in src/path-prefix.h - packaging/osx-app.sh attempts to create a .app package from a built inkscape - Info.plist is built from Info.plist.in. I have no idea if this file is valid. To compile inkscape on OSX, with modern fink, everything is available except gc 6.4. I updated the wiki here: http://www.inkscape.org/cgi-bin/wiki.pl?CompilingMacOsX I didn't get into the gc details, but if you build your own gc, and install it in ~/sw, you can build inkscape with: SW=~/sw export CPPFLAGS="-I$SW/include -I/sw/include" export LDFLAGS="-L$SW/include -L/sw/lib" ./configure --prefix=$SW After a "make install", you can build your Inkscape.app with: bash packaging/osx-app.sh Inkscape ~/sw/bin/inkscape Info.plist which should also build the Inkscape.dmg This is all completely untested. The only thing I know for sure is that the library resolution works right (I can run inkscape from the .app directory -- via command line). I have no idea what happens from within OSX itself (I'm ssh'd into a friend's machine). But I'm pretty sure whatever goes wrong can be fixed via src/path-prefix.h and Info.plist.in Good luck! I'm going to sleep! :) -- Kees Cook @outflux.net

2 2

Re: [Inkscape-devel] NEW: on-canvas gradient editing
by Alexandre Prokoudine 20 Feb '05

20 Feb '05

On Sun, 20 Feb 2005 07:36:37 -0800, Kees Cook <kees@...62...> wrote: > ? http://www.inkscape.org/cvs-snap/ > > That URL gets updated every 20 minutes. Or does that not get you > something you're looking for? (And daniel's has been working since > yesterday afternoon) Hmm, they were not updated for quite a long while earlier, so I didn't even care to look there. Thank you for fixing my /dev/brain symlink :) Alexandre

1 0

New masthead
by Adam Pearson 20 Feb '05

20 Feb '05

bulia (I sent this to the user list in error!) I think the site would benefit from more colour and a contrasting (i.e., serif) font as per attached; but I think others with greater graphic skills than me are required! Regards Adam ----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: <inkscape-devel@...6...>; "Inkscape users list" <inkscape-user(a)lists.sourceforge.net> Sent: Sunday, February 20, 2005 9:27 AM Subject: [Inkscape-user] web site proposals > I'd like to propose two things regarding the Inkscape web site. > Volunteers are welcome: > > 1 Create an RSS feed for the main page news. > > 2 Create a new header graphic to replace the boring white "Inkscape" > on blue. As a graphic app, we are starting to deserve something more > sophisticated. The web site itself is OK, I don't think we need to > drastically change the entire design (although suggestions are > welcome), but the top panel is decidedly dull and pathetic. Show off > your graphic talent! Send your submissions to the devel list for > people to discuss. The best one (if the winner is not obvious, we may > need to do a voting) will make it to the site. One technical note: the > banner cannot be fixed width, because our site is not fixed width - so > it must be either one piece for the top left corner or two pieces for > two corners, with some flat color fill between them. The minimum > screen resolution is 800x600. > >

1 0

new SPRepr class names
by MenTaLguY 20 Feb '05

20 Feb '05

For reference: SPRepr -> Inkscape::XML::Node SPReprDoc -> Inkscape::XML::Document SPReprAttr -> Inkscape::XML::AttributeRecord SPReprAction -> Inkscape::XML::Event SPReprEventVector -> Inkscape::XML::NodeEventVector -mental

1 0

SPRepr renamed! commits may resume!
by MenTaLguY 20 Feb '05

20 Feb '05

Okay, comitted the most evil of the changes (check out the 80-some line ChangeLog entry XD). I'm not really done yet, but the remaining stuff is much less likely to cause merge conflicts with anything anyone else is working on. -mental

1 0

SPRepr renaming! hold off on commits!
by MenTaLguY 19 Feb '05

19 Feb '05

I'm getting ready to rename the SPRepr interface classes into the Inkscape::XML namespace. As I'll probably have to end up touching most of the files in the codebase, it might be a good idea to hold off comitting anything until I'm done. Yes, I can resolve update conflicts before I commit, but they are more likely to get resolved correctly if they happen on your end, since you will understand your particular changes better, and you will individually have fewer to handle than I would. -mental

1 0

New text layout engine design RFC
by Richard Hughes 19 Feb '05

19 Feb '05

See the attached header file for the first draft of what I think the interface for the new text layout engine should look like. The intended audience is developers, there's nothing to see here for people who don't enjoy reading source code. Comments are encouraged on design, comprehensibility, features, style and smackdowns. A few things to talk about, in no particular order: 1) Do we disapprove of public member variables, even where there's no disadvantages to using them? 2) The coding style guide doesn't mention the how the names of enumerations should be formatted. 3) I implement parse_svg_length_list() because the old flow_src did. Should this really belong closer to the XML layer? 4) Likewise the xml:space attribute. The difficulty with moving this is that you could cause roundtripping problems. Can we even do roundtripping? 5) Lots of private members are missing still, because I don't know what they're going to be yet. 6) The appearance of this document doesn't mean I've decided whether to wrap the existing code, switch over the users, then write my own innards, or to do it all in one big (destructive) commit. The latter is quite a lot less work, but the former will likely be broken for shorter intervals (although maybe more of them). 7..n) There are more things to discuss in the attachment, under the heading "Comments", near the top. That's it, I think. I'll remember something else as soon as I click 'send', of course. Richard.

4 5

.svgz reading
by unknown＠example.com 19 Feb '05

19 Feb '05

I just changed the gzip input stream to remove some of it's limitations. Please give it a shake-down and see if it holds up. (It works on assorted-tiling.svgz now)

2 2

Fwd: Re: [cairo] cairo anti aliasing
by unknown＠example.com 19 Feb '05

19 Feb '05

----- Forwarded message from Samuel Abels <newsgroups@...722...> ----- Date: Sat, 19 Feb 2005 01:19:37 +0100 From: Samuel Abels <newsgroups@...722...> Reply-To: Samuel Abels <newsgroups@...722...> Subject: Re: [cairo] cairo anti aliasing To: Tim Janik <timj@...723...> On Sat, 2005-02-19 at 00:38 +0100, Tim Janik wrote: > i am seriously considering to use cairo as a rendering backend in an > anti-aliased canvas i'm currently working on. In case you are using C++ - might we consider combining efforts? http://cms.debain.org/ -Samuel -- ------------------------------------------------------ | Samuel Abels | http://www.debain.org | | spam ad debain dod org | knipknap ad jabber dod org | ------------------------------------------------------ _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo ----- End forwarded message -----

1 0

Adding CxxTest
by unknown＠example.com 18 Feb '05

18 Feb '05

I just did an initial checkin to add CxxTest. http://cxxtest.sourceforge.net Once you do an update, just run "make check" from the top level and you should get src/libnr/testrunnr built and executed along with all the other tests. Or to get just that one, change to inkscape/src and then run "make libnr/testrunnr" to build it. It runs CxxTest to create the needed .cpp from *-test.h files, then builds it.

2 5

Fwd: Re: COMMENT: Flow Text
by unknown＠example.com 18 Feb '05

18 Feb '05

----- Forwarded message from Jon Ferraiolo <jon.ferraiolo@...720...> ----- Date: Fri, 18 Feb 2005 09:51:22 -0800 From: Jon Ferraiolo <jon.ferraiolo@...720...> Reply-To: Jon Ferraiolo <jon.ferraiolo@...720...> Subject: Re: COMMENT: Flow Text To: Thomas DeWeese <Thomas.DeWeese@...721...>, www-svg@...157... Thomas, Thanks for the great comments! The SVG Working Group has given me the assignment of responding to one of our comments below. You said: >4.14.2 The progression-align property > > Doesn't it make a _lot_ more sense to have this property >apply to the flow regions? What does it mean to have a center >aligned flowPara bracketed by two un-aligned flowPara elements? > > Also I think a description of how this is applied to content >is in order. I can think of several "reasonable" interpretations >which given 'odd' flow geometry could result in widely variable >results. The SVG WG believes the SVG 1.2 LC specification incorrectly defined a 'progression-align' property when instead it is better to reuse the 'display-align' property from XSL-FO (defined within http://www.w3.org/TR/xsl/slice7.html#area-alignment) , which delivers exactly what is needed. The next public draft of SVG will include the 'display-align' property instead. We agree that the 'display-align' property should apply to regions and not to flow content elements. The next public draft of SVG will say that 'display-align' applies to the text container object and not to elements that are part of the text flow such as <flowPara>. In terms of the last paragraph about odd flow geometries and widely variable results, I believe this issue only applies to non-rectangular regions. At the moment, the SVG WG is first addressing SVG Tiny 1.2 requirements (which only supports rectangular text regions) and is adopting the general policy proposed by others that flowing text layout must allow UA-specific layout algorithms to be deployed so that UA's are not prevented from delivering the best possible results. Although we haven't resolved your last paragraph completely yet, there is a possibility that we will allow layout variability in the general case (per the feedback of others), which might lead us to conclude that it is sufficient to simply provide layout guidelines for flowing text in arbitrary shapes (preserving the great technical work by the incredibly bright people who documented the existing algorithms - do you remember who contributed to that work?) but not *mandate* every possible detail for how layout is performed. Jon At 07:45 AM 11/8/2004, Thomas DeWeese wrote: >Hi all, > > These are concrete problems/suggestions on the flowText elements as >currently specified (or underspecified). > >4.2 The flowRegion element > > "The children of a flowRegion element are inserted into the > rendering tree before the text is drawn and have the same > rendering behavior as if they were children of a g element." > > This is new and I don't think it's a particularly good idea. If >people want the flowRegions to be rendered then there is the 'use' >element. Given the above how are filters handled? > > "A flowRegion element has basic shapes and path elements as > children" > > I'm not a real Schema expert but it appears that it allows >just about anything as a child (g, use, text, shapes). This is >without comment on how these are combined to form the flow regions. >Given that the desire here is almost identical to the clipPath element >(namely construct a set of geometry) I would strongly urge the WG >to adopt the wording and methods used in clipPath (which restricts >it's children pretty heavily). > > Given that the WG is likely not to take my advice ;) You need to >at least specify what having a 'g' means. Is all the geometry >concatenated as one flow region? Are implementors expected to 'union' >the fill regions of the children of the 'g'? Use if it is allowed >to reference arbitrary content (which it isn't for clipPath) has >similar issues. > > Also with text is all the text considered a single very complex >flow region or is each individual letter a flow region? What about >letters with multiple 'disjoint' pieces ('i',';','%')? > > All these comments apply equally to the flowRegionExclude section. > >4.5 The flowPara element > > It needs to be clearly defined if 'block' here means CSS block. >Also there are references to margin's elsewhere do they apply here? > > flowPara doesn't appear to allow flowLine as a child (in fact >no one seems to allow flow line as a child). > >4.7 flowRegionBreak element > > It should be specified what the behavior is in the case that a >flowRegionBreak element is empty or there are multiple together (as >it is for flowLine). Also flowSpan doesn't allow flowRegionBreak >element's as children, but flowLine and flowDiv do, is this >intentional? > > Is flowRegionBreak more a flowPara or a flowSpan or something >else (just a 'marker'?). > >4.13 Determining Strip Location > > How is line-height determined? > > What is the strip that is intersected with the geometry? > > If it is the line-height it is worth noting that this may be >smaller than the content height meaning that text content may >run into the flow geometry. If the content height (or line box) >is used then this doubles the number of intersections needed to >handle strip calculations (there are also other inefficiencies this >introduces). > >4.14.2 The progression-align property > > Doesn't it make a _lot_ more sense to have this property >apply to the flow regions? What does it mean to have a center >aligned flowPara bracketed by two un-aligned flowPara elements? > > Also I think a description of how this is applied to content >is in order. I can think of several "reasonable" interpretations >which given 'odd' flow geometry could result in widely variable >results. > >4.14.3 Overflow > > What is the processing model for this? > Is this event generated before/after DOM mutation events? > _Must_ it be issued for every mutation event that changes >the state or may an implementation 'compress' overflow events >as long as no rendering occurs between them? > > I would really like to lobby for allowing compression, otherwise >the layout must be performed on essentially _every_ modification of >the content tree. I think UA's should be allowed to defer layout >until just prior to rendering at which point if a flow has change >overflow state events must be issued (which may change the flow and >hence the overflow state, which may lead to new overflow events before >the rendering takes place, repeat as needed). > > This avoids the need to layout the text 12 times because 12 >properties were changed in the flowText tree (even when none of >the 12 actually causes an overflow event). > > For async renderers (that don't normally hold up rendering until >'script' completes) they would only be required to dispatch the event >before 'unsuspendRedraw/All' and 'forceRedraw' complete. > >4.15 Example > > Aside from the already noted 'well formedness' problem ("</flow>" >instead of "</flowRoot>"). The namespace declaration is wrong >(you want "xmlns=" not "xmlns:svg="). Also in the first example >the flowRegion appears to be a parallelogram instead of the >desired trapezoid (I think the last L should be L200,50 - although >even that goes 'outside' the stroked trapezoid on the bottom). >You might be better off using margins here and referencing the >stroked trapezoid. > >Other Properties: > > There should really be a consideration of other properties >implementations need to be mindful of from CSS. A few that >come to mind: 'margin', 'margin-*', 'text-indent'?, 'white-space'?, >'line-height'. Without this it is unclear what an implementation >is expected to support. > > ----- End forwarded message -----

1 0

Saving as pov
by Lucas Vieites 18 Feb '05

18 Feb '05

Hi, I've been trying to render the exported pov files from simple svg images but I keep getting errors. I'm using povray 3.6 to render the attached pov file, generated from the attached svg file. I'm also attaching the output ;-) Thanks for your help, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

1 0

resource leaks on Windows
by bulia byak 18 Feb '05

18 Feb '05

Today we have found and patched a number of GDI resource leaks. This will likely fix the bug where using text tool eventually caused Inkscape to freeze with endless "SaveDC failed" and "RestoreDC failed" messages streaming to the console: http://sourceforge.net/tracker/index.php?func=detail&aid=1070816&group_id=9… Everyone who has ever experienced it (and everyone else using Windows), please test a CVS build dated later than today and report your results.

2 1

doxygen updates
by Kees Cook 18 Feb '05

18 Feb '05

Okay, the website doxygen should update every night around 3am Pacific time now. -- Kees Cook @outflux.net

1 0

close confirmation fix
by unknown＠example.com 17 Feb '05

17 Feb '05

FWIW, forgot to mention that I think I fixed the close confirmation dialog last night. Try it out and see if it works as expected..

2 1

Setting physical resolution and exporting documents
by unknown＠example.com 17 Feb '05

17 Feb '05

Hello! I would like to set the physical resolution of a document to export it as an EPS file at a given resolution. However, I have not found setting of the resolution anywhere in the program. In the "print" menu there is a physical resolution option for the printed images, but it did not work for the EPS files. Another problem is exporting of the documents. It is possible by renaming the file by "save as", and so to export a document without changing its name a double rename is needed, what might be error prone. Thanks, Artur Rataj

2 1

Inkscape status 2005-02-15
by Bryce Harrington 16 Feb '05

16 Feb '05

Project Status Tuesday, Feb 15, 2005 Today at work after our all-hands meeting, one of the marketing guys named Carl grabbed me. He'd just upgraded to SuSE 9.2 but knew that we'd just released 0.41, and SuSE only had 0.39. We downloaded and installed the Autopackage version. I gave him a quick tour of the new features. When we got to the color trace function he slapped me on the shoulder, "My god, that's _exactly_ what I've needed!!" He loaded up one of the OSDL member logos and vectorized it with the color trace tool. We get these logos in every format known to mankind, and scaling them can be a real challenge sometimes. This week I've been showing off all sorts of things to people... The new inkscape.deviantart.com. I showed daj's "Rockin' in the Free World" to a professional musician. ScislaC's 'Gaze' astounds _everyone_ who sees it; this is without a doubt the most advanced piece of art ever done with Inkscape/Sodipodi/Gill (we have *got* to encourage Scislac to teach us all the tricks for how he was able to *do* that!) I also of course have to brag about the KDE 3.4 SVG Wallpaper contest, and that of the top 4, half are known to have been done with Inkscape (including the winner). The thing I point out to people at work is that despite how great Linux is technically, there are many, many people who "judge a book by its cover" and consider only how the thing looks. Like buying a car based on its paint job and leather upholstry instead of its engine. But graphical tools like Inkscape are enabling artists to give Linux that beauty, to make it visually as well as technically attractive. In the stats below, the most obvious thing is the sudden jump in linecount. No surprise there - this is all the new code such as gtkmm that finally got greenlighted to go into the codebase. Hopefully over the next few months we'll see the linecount reduced as this new code replaces the gobs of repetitive old code currently in there. The mailing list numbers show that we've gained a number of new members. (Welcome aboard!) Of course, anyone on Jabber or IRC recently will have already noticed the nice jump in activity, both with usage questions and with development work. Things seem to be going quite well! Statistics Jan 1 Jan 15 Feb 1 Feb 15 ========== ===== ====== ===== ====== Lifetime Rank on SourceForge: 598 570 569 569 (95.8%) (96.0%) (96.0%) (96.04%) Max Week's Rank on SourceForge: 45 59 * * (99.8%) (99.6%) * * Total SF Page Views 2,213,324 2,283,160 2,296,458 2,296,458 Total SF Downloads 110,182 114,695 115,645 115,645 Total Freshmeat URL Hits 14,291 14,634 15,108 16,448 Total Freshmeat Subscriptions 149 151 156 169 Lines of Code in src/: 321,883 323,251 323,324 333,139 Code lines 227,114 227,965 227,872 234,651 Comment line 56,048 56,308 56,438 58,239 Blank 45,398 45,664 45,624 46,859 Lines of Docs in doc/: 17,901 17,901 17,918 26,848 Lines of content in website: 9,234 9,328 9,486 9,776 Size of the Inkscape wiki: 21,030 20,931 23,576 24,925 Bugs open/total: 135/829 145/858 148/917 155/972 Features open/total: 340/514 353/530 352/556 370/579 Patches open/total: 5/145 6/148 7/154 5/167 CVS Commits (as per inkscape-cvs) 9,450 9,625 9,975 10,312 Inkscape-devel membership: 132 131 143 151 Inkscape-announce membership: 147 155 166 169 Inkscape-user membership: 172 177 181 193 Num Translations: 33 33 33 33 Ave Translation Ratio: 43.7 42.0 44.7 47.8 * - Statistics unavailable

3 2

Re: [Inkscape-user] Stroke paint >Pattern
by Ted Gould 16 Feb '05

16 Feb '05

On Mon, 2005-02-14 at 11:56 -0400, bulia byak wrote: >On Mon, 14 Feb 2005 16:47:47 +0100, Jakub Steiner <jimmac@...659...> wrote: >> Looking at it from the interface perspective, I'd call it a brush. > >Yes, that's the best term. > >> You >> could convert an object into a brush, just like you can now convert an >> object into a pattern. > >And adjust things like spacing, rotation, randomization... > >> Once you has a brush you could then use it on an >> object as another property (fill, stroke). > >I don't think it can be used on fill, only on stroke. Actually, brush >strokes will be their own kind of objects (implemented as SVG <g> with >extension attrs) so they won't have any fill. I was curious if this functionality could be implemented using markers. Perhaps subdivide the path and place the "brush strokes" on the nodes so that you'd get a brush effect kinda like GIMP. It might be difficult to do brushes that change over time though... --Ted PS - Took this thread to devel, it was on user.

2 1

Re: [cairo] The Great API Shakeup (fwd)
by PLinnell 16 Feb '05

16 Feb '05

> Message: 9 > Subject: Re: [Inkscape-devel] [cairo] The Great API Shakeup (fwd) > From: MenTaLguY <mental@...3...> > To: Craig Bradney <cbradney@...242...> > Cc: Inkscape ML <inkscape-devel(a)lists.sourceforge.net> > Date: Tue, 15 Feb 2005 20:51:30 -0500 > > <snip> > > I'd strongly recommend you folks put someone on the cairo mailing > list as an interface, since feedback from a project like Scribus > that is actively using cairo will be helpful to them. > > -mental > Done.

1 0

[cairo] The Great API Shakeup (fwd)
by Bryce Harrington 16 Feb '05

16 Feb '05

This last weekend, several cairo developers happened to be in the same physical room, (as part of XDevConf[*]). We took advantage of the opportunity and had a very productive meeting last night in which we tried to discuss as many open API issues as possible. The following people were involved in this ad-hoc meeting: Kristian Høgsberg, David Reveman, Keith Packard, Owen Taylor, Carl Worth The meeting was also attended by Jim Gettys and Bdale Garbee, without whose support we could not have been productive. Kristian took some good notes on the discussion last night, which we'll be cleaning up and sending out as a bunch of separate proposals to the list. Hopefully this stream of little proposals will be easier to digest than one giant summary of the meeting. And, this way any sub-discussions that spin off should be easier to manage. We'll include "API Shakeup" in each of the proposals, and we'll try to tie them into existing open threads as appropriate. Each mini-proposal will be followed up with a patch proposal to implement the change, (and each patch must include documentation). Then, of course, once any new discussion settles down, we can start committing all of this stuff. The scope of the changes means that all existing cairo-using code will have to be updated, (eg. we have a proposal that changes cairo_create). So, the breakage will be a bit painful. But hopefully, the work needed to bring forward any single piece of code will actually be quite minor. As this process wraps up, we'll pull together a single-source guide on what people need to do to get their code updated. Anyway, this should be a lot of fun. And we should have an easier-to-use, and less warty API when we're done. If anyone has pet peeves regarding API issues in cairo, this will be the time to bring them up, because we won't want to go through many more break-every-application changes again for quite some time. -Carl [*] X Developers' Conference http://freedesktop.org/wiki/Software/XDevConf _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

4 4

[Fwd: Translation update - spanish]
by Lucas Vieites 16 Feb '05

16 Feb '05

Previous message got rejected due to .zip attachment, I'm attaching it in tar.bz2 format now, cheers. --------- Mensaje reenviado -------- >De: Lucas Vieites <lucas@...212...> >Para: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> >Asunto: Translation update - spanish >Fecha: Fri, 11 Feb 2005 11:24:05 +0100 > Hi, I'm attaching an updated es.po file. A couple of fuzzies and >untranslated were left behind (a total of 4-5). > > By the way, I was invited today to give a "hands-on" tutorial on >Inkscape at a free-software meeting next month in Extremadura, a region >in Spain that started to develop their own Debian-based Linux >distribution ("Linex", www.linex.org) for use in schools and local >administrations. Any suggestions? > I was planning to do a quick tour through the tutorials included in >Inkscape and a few live demos. > > > Cheers, -- Lucas Vieites Fariña Asix Informática <info@...212...> http://www.asixinformatica.com/ Tel/Fax: +34 986 54 26 98

4 4

save-on-close issue
by MenTaLguY 16 Feb '05

16 Feb '05

Seems the problem is this rather evil bit of code in sp_dtw_desktop_shutdown: > if (doc && (((GObject *) doc)->ref_count == 1)) { Guess I was right about having exposed an existing bug. This is wrong for two reasons: 1. objects other than SPDesktops can reference SPDocuments, and there are non-inter-object-reference uses for refcounts: the wrong value being used for the wrong concept 2. GObject::ref_count is sort of an internal field (in the words of the glib API documentation, "All the fields in the GObject structure are private to the GObject implementation and should never be accessed directly.") The most obvious fix is to specifically keep a count of related active desktops in the SPDocument, and do a similar test with that. However, should we count SPDesktops, or more generally all SPViews (for example the preview view)? Is SPDocument necessarily the place to actually keep track of that, or should it be e.g. the Inkscape Application object? -mental

2 4

Inkscape::NSApplication ?
by MenTaLguY 16 Feb '05

16 Feb '05

What's the 'NS' in NSApplication for? Some kind of Hungarian notation? I'm not particularly fond of it... -mental

2 2

location of the actual close confirmation dialog?
by MenTaLguY 16 Feb '05

16 Feb '05

Bleah, I can't seem to find the code for the actual close confirmation dialog. Could someone please direct me to the right place? -mental

1 0

URGENT: fill & stroke breakage
by bulia byak 16 Feb '05

16 Feb '05

- launch - open any file from gui (file>open or file>open recent) - press ctrl+shift+F crashes with: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087741248 (LWP 19098)] IA__g_hash_table_destroy (hash_table=0x989fd20) at ghash.c:742 742 node = node->next; Current language: auto; currently c (gdb) bt #0 IA__g_hash_table_destroy (hash_table=0x989fd20) at ghash.c:742 #1 0x080d610a in ~SPDocument (this=0x8409fc0) at document.cpp:118 #2 0x40ae8ec4 in GC_invoke_finalizers () at finalize.c:787 #3 0x40ae8fb9 in GC_notify_or_invoke_finalizers () at finalize.c:844 #4 0x40aea3bd in GC_generic_malloc (lb=7, k=2) at malloc.c:188 #5 0x40aeb37a in GC_malloc_uncollectable (lb=7) at mallocx.c:572 #6 0x082bd37f in Inkscape::GC::Anchored::_new_anchor (this=0x9827e04) at gc-core.h:88 #7 0x0820e16a in NRArenaItem (this=0x9827e00) at gc-anchored.h:51 #8 0x08216ee2 in NRObject::invoke_ctor<NRArenaShape> (object=0x9827e00) at nr-object.h:75 #9 0x082568cd in NRObject::alloc (type=141831864) at libnr/nr-object.cpp:181 #10 0x08116a40 in sp_shape_show (item=0x92e7208, arena=0x989fd20, key=35, flags=1) at nr-object.h:114 #11 0x081017a1 in sp_item_invoke_show (item=0x92e7208, arena=0x863ef90, key=35, flags=1) at sp-item.cpp:697 #12 0x080fdb0c in sp_group_show (item=0x92e7208, arena=0x863ef90, key=35, flags=1) at sp-item-group.cpp:410 #13 0x08103d43 in sp_marker_show_instance (marker=0x9011b6c, parent=0x87f4200, key=160039424, pos=0, base=@0xbfffe240, linewidth=1.70000005) at sp-marker.cpp:581 #14 0x081160fa in sp_shape_update_marker_view (shape=0x86a22f8, ai=0x87f4200) at sp-shape.cpp:555 #15 0x08116eb0 in sp_shape_update (object=0x86a22f8, ctx=0xbfffe3c0, flags=4) at sp-shape.cpp:278 #16 0x08108e76 in SPObject::updateDisplay (this=0x86a22f8, ctx=0xbfffe3c0, flags=4) at sp-object.cpp:1016 #17 0x080fca30 in sp_group_update (object=0x86a22f8, ctx=0xbfffe520, flags=4) at sp-item-group.cpp:240 #18 0x08108e76 in SPObject::updateDisplay (this=0x867417c, ctx=0xbfffe520, flags=4) at sp-object.cpp:1016 #19 0x080fca30 in sp_group_update (object=0x867417c, ctx=0xbfffe700, flags=4) at sp-item-group.cpp:240 #20 0x08115058 in sp_root_update (object=0x843e6c0, ctx=0x83511b0, flags=3) at sp-root.cpp:559 #21 0x08108e76 in SPObject::updateDisplay (this=0x843e6c0, ctx=0xbfffe810, flags=3) at sp-object.cpp:1016 #22 0x080d54aa in sp_document_ensure_up_to_date (doc=0x8409f18) at document.cpp:577 #23 0x081a819e in sp_marker_list_from_doc (m=0x92f6fb8, current_doc=0x98a0200, source=0x8409ea8, markers_doc=0x0, sandbox=0x8409f18, menu_id=0x82ca5ff "marker-mid") at dialogs/stroke-style.cpp:841 #24 0x081a8a31 in ink_marker_menu (tbl=0x989fd20, menu_id=0x82ca5ff "marker-mid", sandbox=0x8409f18) at dialogs/stroke-style.cpp:1104 #25 0x081abb6e in sp_stroke_style_line_widget_new () at dialogs/stroke-style.cpp:1515 #26 0x081a32da in sp_object_properties_dialog () at dialogs/object-properties.cpp:178 #27 0x0822aa01 in sp_action_perform (action=0x845c330, data=0x0) at helper/action.cpp:135

4 7

Urgency and spirit
by Felix Rabe 15 Feb '05

15 Feb '05

Hi all, I agree that the CVS code should remain usable, but (not blaming anyone!) I don't think it is a productive way to then put everybody under pressure to fix every crash by yesterday. I just want to remind you (as an outsider and non-developer; I actually don't have any say here) that this project came into existence to grant more freedom to its developers. If you expect to have every bug fixed ASAP in (by nature) shaky code, you will start to drive people away again if you get used to this behavior. Just want to remind you *before* it becomes a serious problem. Greetings and happy hacking, - Felix

3 2

Selection in text editing
by Aewyn 15 Feb '05

15 Feb '05

Hi, I run into trouble again ;) How can I select text (some characters) while editing on canvas? I can, however with ctrl+shift+T, but it would be much easier on canvas. Thanks, Aewyn

6 19

Comment to bug 1077213
by Praktikant 14 Feb '05

14 Feb '05

Hi, This is the attachement I wanted to append to bug 1077213, but I didn't find out how to do it. This attachement is a snippet of the 300dpi export I did. Hope it helps. The dot is also missing at zoom levels between (ca.) 400% - 450%, among others. Inkscape 0.41 WinXP cu, Felix Rabe (aka xitnalta@...360...)

2 1

Build error on powerpc-apple-darwin7.8.0
by Chris Burdess 14 Feb '05

14 Feb '05

I have the following problem building inkscape on the above platform: object-edit.cpp: In function `void sp_spiral_outer_set(SPItem*, const NR::Point&, const NR::Point&, unsigned int)': object-edit.cpp:842: error: `isfinite' undeclared in namespace `std' Should this be a configure option? -- Chris Burdess

3 2

Update on Inkscape presentations
by Bryce Harrington 14 Feb '05

14 Feb '05

Hi all, We've got two proposals in for OSCon - one for a 90 min presentation by Ted and I about extensions in Inkscape, and a paper proposal by me and Kees on the Inkscape project methodology. In addition, it sounds like we may have someone who could do the SVG Open presentation (Piers, who lives there in the Netherlands). Rejon is working with him on trying to put it together. Bryce

2 1

[Fwd: Re: [Inkscape-devel] No more Brazilan Portuguese update?]
by Ludi Maciel 13 Feb '05

13 Feb '05

Ok. I and Fred will take it now.The Scribus and InkScape have the same translators for pt_BR now. I think that is good so now we can have a same guideline for the both apps and work close to Gimp translator too. Thanks. Ludi -------- Mensagem Original -------- Assunto: Re: [Inkscape-devel] No more Brazilan Portuguese update? Data: Sun, 13 Feb 2005 15:00:04 -0800 (PST) De: Arpad Biro <biro_arpad@...36...> Para: iludi@...707..., inkscape-devel(a)lists.sourceforge.net Hi, > I'm just wondering wthat is happening to pt_BR version of Inkscape. > The 0.40 had some untranslated issues, the same for 0.41 (more) > So, please, brazilian mainter show up! > Tell me what's going on. I and another guy can help in translation > (we are working in Scribus now, but no problem). pt_BR.po was last modified in July 2004. I don't have any information on the guy (Juarez) who used to do the translation, but you could probably contact him (address in the PO file). It would be great if you could join him or take the stuff over from him. Arpad Biro __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

No more Brazilan Portuguese update?
by Ludi Maciel 13 Feb '05

13 Feb '05

I'm just wondering wthat is happening to pt_BR version of Inkscape. The 0.40 had some untranslated issues, the same for 0.41 (more) ... So, please, brazilian mainter show up! Tell me what's going on. I and another guy can help in translation (we are working in Scribus now, but no problem). Regards. Ludi.

2 1

Improvment of wording in the overwrite dialog
by Andreas Nilsson 13 Feb '05

13 Feb '05

I am currently going over some of the dialogs to see if they can be improved and made more consitent with our friends Gimp and Scribus. I have some small suggestions for the wording in the overwrite dialog: 1. The wording overwrite is not a very nice term, "Replace" much friendlier. 2. The terms Yes and No are not optimal. When I get the question, my brain says "Yes, of course I want to keep the old document". 3. The line between the text and the buttons is noise. Gimps' overwrite/replace dialog is really nice, and I suggest we copy that right off. Here are screenshots from the Gimp, Inkscape and Scribus: http://www.inkscape.org/cgi-bin/wiki.pl?Overwrite_Document BTW, it would be really nice to have a irc-meeting with some people from Gimp and Scribus to discuss this whole Free Graphics Suite/Team thing soon. - Andreas Nilsson

5 12

Crash when opening SVG file with animate element
by Jasper van de Gronde 13 Feb '05

13 Feb '05

I encountered a file that causes InkScape to crash on my machine (WinXP) whenever I open it. It doesn't matter whether I open it from Explorer or through File\Open, it even crashes as soon as it tries to generate a preview in the open file box (if I select it in the file list instead of typing in the filename myself). I've stripped everything from the file that didn't stop it from crashing. I'm using InkScape 0.41, from a setup package downloaded from SF on 2005-02-10. Can anyone, on Win32 or any other platform, reproduce this. I've attached the file to this mail. If there is something that could be wrong with my system (or the build I downloaded) that might cause this I'd like to know it too of course. BTW, the relevant bug in the bugtracker is 1119935.

2 1

[Fwd: [Clipart] Re: svg shell extension]
by Jon Phillips 13 Feb '05

13 Feb '05

Hi Inkscapers, There is a developer attempting to build a WIN32 Shell Extension to render SVG file thumbnails in winxp. If anyone has any experience, please join this discussion on the open clip art library list, or copy him and the list if you all know anything about these topics. I think it is a very valuable addition. I thought it would be quickly possible to use inkscape to generate extensions, however, maybe not the best long term solution. Jon -------- Original Message -------- Subject: [Clipart] Re: svg shell extension Date: Sun, 13 Feb 2005 08:49:01 +0000 From: Andy Burns <openclipart@...708...> To: clipart@...626... References: <20050209113032.DAA2E9E941@...709...> >>I might be tempted to have a go at that [svg shell extension] > > Man, that would rock big time!!! OK, I didn't get much (read any) time during the week to start at this, but now I've got VC++ set up and I've created a skeletal shell extension, which doesn't do anything .svg specific yet ... Anyone have any suggestion what library/api to use to render SVG for the thumbnails, Jon suggested inkscape, but I don't think it exposes any API, correct me if I've overlooked something. I've had a look at libsrvg which looks suitable, has anyone used it on win32? Any others to consider? Thanks. _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

one last test - ignore
by Bryce Harrington 13 Feb '05

13 Feb '05

1 0

testing - please ignore
by Bryce Harrington 13 Feb '05

13 Feb '05

Testing fix to mail glitch

1 0

testing - ignore
by Bryce Harrington 13 Feb '05

13 Feb '05

testing mail glitch

1 0

SPDocument conversion
by MenTaLguY 13 Feb '05

13 Feb '05

Just a quick heads-up that I've converted SPDocument to a real C++ class -- that is, rather than being allocated and initialized using GObject, the normal C++ facilities are used (in this case the class is also now managed by the garbage collector). I had expected this to break some things, but with testing it looks like the code that had depended on deterministic freeing that I had been worried about has been cleaned up. I've gone ahead and comitted, but let me know if anything broke that I couldn't find... I do still need to convert the various document functions into member functions, and make SPDocument an abstract interface. Probably it will get renamed to Inkscape::Document too. -mental

1 0

Inkscape::Application architecture presentation
by Bryce Harrington 13 Feb '05

13 Feb '05

Hi all, This morning, Jizzbug noted that in inkscape_gtkmm we hadn't really gotten the Inkscape::Application object structured for handling multiple windows. Looking at the existing inkscape codebase, though, it looks like we've kind of outgrown the basic architecture, as we've added cmdline, inkview, etc. capabilities. I've collected some thoughts on how we could reuse this basic architecture but structure it with a bit more flexibility. I've done this as a set of SVG presentation slides. They're in CVS in inkscape/doc/NewAppArchitecture/. View them via `inkview *svg`. Also, I've temporarily posted it here: http://inkscape.org/doc/NewAppArchitecture.tgz Bryce

1 0

command line export broken
by bulia byak 12 Feb '05

12 Feb '05

Command line export is broken again due to its attempting to open a dialog ("extensions not found"). Ted, Kees, and anyone else, could you please look into it: http://sourceforge.net/tracker/index.php?func=detail&aid=1121499&group_id=9… Strangely, it works when I run it from the compile dir, but crashes when I run it from the install dir (see my comment there).

2 2