- Inkscape Devel - Inkscape Mailman

loading of anon namespace documents is broken
by bulia byak 07 Jan '05

07 Jan '05

Mental, after your changes to namespace handling, we can no longer load documents without any namespace declarations, e.g. simply <svg> <g style="fill: ;"> <path d="M1 979.362L1 1051.362L73 1051.362L73 979.362L1 979.362z"/> </g> </svg> This used to work before, and it also works in Batik, so I think we must restore that. Can you please fix?

2 1

removing "SP* Properties" dialogs
by bulia byak 07 Jan '05

07 Jan '05

I want to remove "SP* Properties" dialogs that are listed in the right-click menu of shape objects. Reasons: - they use technical terms without any explanations and are therefore confusing - they don't stay on top (I just didn't bother with them, planning to remove them eventually) - they're very limited (no units, no live update from selection) - most importantly, they're now completely redundant: if you want access to the raw attributes, use the XML editor; if you want convenient units, explanations, and live update from selection, use the controls bars of the corresponding tools. So I'd like to know if anyone is really using them, and if so, why and what needs to be done to help these users move away from this ancient remnant to more modern facilities. In other words, is there any unique functionality or convenience in them that I'm failing to see?

3 4

Toolbox as window
by David Christian Berg 06 Jan '05

06 Jan '05

Hi guys, I've wondering this all over Gnome since quite a while: When I detach a toolbar, why wouldn't it be in a resizable toolbox à la gimp, with a window manager frame around it. That would really be cool for a palette as well, when you could attach it to the bottom or right hand side like in Corel or have it as a floating palette as in InDesign. A detached toolbar with all the buttons in _one_ row is really annoying, because it simply clutters the screen. I'm sure this is not quite inkscape related, really... everything you'd do would be a workaround, I guess. But maybe you could hint me to where to file a RFE? Take care! David

3 6

GIMP Gradient Bug
by Ted Gould 06 Jan '05

06 Jan '05

Hey, So, once there was a bug that some people were having crashes with the GIMP gradient plugin. Does that bug still exist? Are people still seeing it? If so, are those people using relocatable binaries support? I'd like to see this fixed for 0.41. Thanks, Ted

4 5

Simplifying groups of shapes
by Bob Jamison 06 Jan '05

06 Jan '05

Hi, all, Since the tracer can now make <g>roups of paths, the existing ability to select the result and simplify it with a <ctrl>L has temporarily been lost for them. I added a few lines of code to splivarot to be able to descend into a group of paths and simplify them, too. The only trick necessary for breaking out the code into being recursive was this rule: a) If it is a shape, then the item has been replaced and the selection has changed. ...or ... b) If it is a group, and an item in it has been replaced, then the selection has -not- been changed. I tested it on many curves before committing. I don't think I did anything to break it, but some of Fred's code can be a mystery. Please give it a try and let me know. Bob

2 1

Re: Questions on Inkscape change events
by bulia byak 06 Jan '05

06 Jan '05

On Wed, 5 Jan 2005 18:39:05 -0500, Brandi Soggs <soggsbh@...635...> wrote: > 1) Every time that a user changes an object, we will need to make the same > change on the same object in for the other users. For our purposes, > document changes are visible changes- changes to the objects drawn or the > creation of new objects. We've seen in the documentation that there is no > central place that gathers changes. Ishmal suggested to us that we use the > sp-canvas as an area that always gets "hit" by document changes. When a > change reaches the sp-canvas, does it actually know all the details (what > happened to which sp-item) or does it just know "A change has occurred! > Redraw!" ? No, SPCanvas is way too low in the hierarchy for your purposes. I think what you need to watch is the SPRepr system. It's similar to DOM, i.e. it stores a representation of the source document, and is changed whenever everything is changed on canvas and elsewhere (and remember that "invisible" changes may affect visible objects, e.g. if you change a gradient definition in <defs> that will change all visible objects that use this gradient). Also reprs are what maintains the undo stack, so in principle you can hook into sp_document_maybe_done (a function which is called as soon as an undoable action is finished) and sync your repr copy with the master repr tree. Or you can look into the topmost undo stack record and see what exactly has changed. Or, if you are interested in one particular node, you can attach a listener to that node and you will be called whenever that node changes. > 2) We're curious how and where (both the techinque and the place in the > code) object ids are generated. We've had some trouble tracing it > ourselves. We're going to need to control object id generations well > enough to prevent two users from attempting to make two objects with the > same id. When sp_object_invoke_build is called (which happens both when the object is built from source on document load and when a new object is created), it runs sp_object_get_unique_id. That function checks if there is already an object with that id and if so, generates a new unique id and assigns to that object, otherwise leaves the old id alone and returns. > 3) We're not certain how all of the arguments to the functions > (sp_item_build, sp_item_set, sp_item_write, sp_item_commit, > sp_item_transform, and equivalent functions in sub-classes of sp-item). > Presumably these arguments are the actual details of a change that has > occurred. SPItem is a subclass of SPObject. SPItems represents all objects that are visible on canvas. All SPObjects, in turn, are generated from SPRepr nodes (though one repr may have more than one SPObject attached to it). All the functions you listed are standard methods of SPObjects and its subclasses, that are called at various stages of their lifetime, not necessarily associated with some user action. For example, sp_item_write and other *_write functions update the repr of this object, i.e. if the object has changed they bring the repr to sync. This may happen in lots of different situations, and the different levels of hierarchy handle their corresponding aspects of repr updating. For example any SPObject must have an id, and therefore sp_object_private_write writes the object's id into its repr: sp_repr_set_attr (repr, "id", object->id); Then, if this spobject is also an spitem, sp_item_write runs. It sets those attrs which are common to all visible items, i.e. transform and style. Then, SPRect is a subclass of SPItem, and sp_rect_write updates those attributes which are specific to rects (x, y, rx, ry). It does not have to worry about the id or transform because that was already taken care of by its parents. Similar hierarchies work for other standard methods (build, write_transform etc). However, you probably don't need all this. What matters for you is that SPRepr ends up with complete updates from all changed objects, and you can take what you need from there. It's the easiest for those new to the code, because the SPRepr tree is the closest thing we have to the actual SVG code, yet it is always up-to-date in memory (e.g. the XML editor is simply a visualization of the SPRepr tree). P.S. I'm posting a copy to the inkscape-devel list, hope you don't mind. Please feel free to ask any other questions on that list, me and others will be glad to help.

1 1

Re: [Inkscape-devel] proposed change to icons
by Andreas Nilsson 05 Jan '05

05 Jan '05

Alan Horkan wrote: > On Thu, 30 Dec 2004, Bob Jamison wrote: > > > >> Date: Thu, 30 Dec 2004 05:33:00 -0600 >> From: Bob Jamison <rwjj@...127...> >> To: Jon A. Cruz <jon@...18...>, >> inkscape <inkscape-devel(a)lists.sourceforge.net> >> Subject: Re: [Inkscape-devel] proposed change to icons >> >> Actually, varying the icons should be easier in the future >> when we have better support for CSS styles. Keep one icon >> file, and a set of stylesheets to tweak it. This would allow >> icon families, much the same as font families. >> > > > I really hope that the developers will not reinvent theming and that the > move to gtkmm and the greater use of standard widgets will make it easier > to support the existing standards for icons and themes as GTK already > includes support for SVG themes. > > I agree that theming from whitin the program is unessesary bloat. But it would be nice to have specific icon themes for the windows and osx builds, (much like Firefox has) to let them blend in with the rest of to the enviorment better. - Andreas

11 33

restore ruler units
by Aaron Spike 05 Jan '05

05 Jan '05

There has been some talk about units lately and I have a question. Please excuse me if this is what you've been talking about and I didn't catch it. The units in my template are mm. If I create a new document and change the units to inches the rulers change to inches. But If I save that document, close and open it again the ruler units are once again mm. And even more I have so far been unable to change them back to inches. I think Inkscape thinks they are already inches. Do other people experience this? Aaron Spike

6 14

Gtkmm screenshot (showing new Toolbox widget)
by Derek P. Moore 05 Jan '05

05 Jan '05

Since I uploaded that previous screenshot for all to see the current state of the Gtkmm work, I thought send up a screenshot showing off the toolbars. In this screenshot, the Tools and the Tool Controls bars are detached. The Tools bar is changed from a vertical orientation to horizontal. The Tool Controls bar is "minimized" into an arrow menu thingy. And the Commands bar (still attached) overflows beyond the size of the window, so you get a convenient arrow menu to access the those icons. As time goes on, we ought to be able to extend this Toolbox widget to include functionality people have requested in various mock-ups posted to this list.

3 6

Interesting problem
by Joshua A. Andler 04 Jan '05

04 Jan '05

I have a file that was originally an Illustrator file, and I saved it as SVG in Illustrator. I went to open the SVG file in Inkscape .40 & .40+ (today's CVS) and the log window popped up with: "WARNING: Requested update while update in progress, counter = 4" The end # (4) varied between 4-8, and there were probably 50+ instances of that message. One time, it eventually opened the file, and when I went to save it as an Inkscape SVG, Inkscape crashed. I figured I'd check here first to see what that message is about before filing a bug, but my guess is the file would be handy for debugging purposes. http://www.scislac.com/inkscape/cammy-mix.svg (1.6 megs) (it's an old project I wanted to get converted to SVG) On a side-note... I think I understand how Illustrator does it's drop-shadows now. It appears that it creates an embedded bitmap image for every shadow (almost like a clone though, since it updates with modifications to the original object). If this copy of the file loads, you'll see the missing image "red Xs" on the left ones face and behind her... where there were drop shadows before. It seems like a good method that we may want to take into account for our own use. If I should file a bug on this let me know. -Josh

1 0

Re: version numbers: 0.41, 0.42, Gtkmm, and 0.50
by Robert Staudinger 04 Jan '05

04 Jan '05

Hi, wrt. to the recent discussion about gtkmm i would like to humbly suggest the use of libglade or even libglademm when moving the ui-related parts of the codebase to c++. As briefly discussed on jabber today this should further simplify the code and make tweaking of the dialogs easy. Additionally it's the suggested way for gnome-related software. Thanks for your time, - Rob

5 6

Re: [Inkscape-user] Results of librsvg bug: Inkscape action?
by MenTaLguY 04 Jan '05

04 Jan '05

On Tue, 4 Jan 2005, Andrew Conkling wrote: > Well, I reported the bug about having to resave gradients to render > correctly with librsvg: > http://bugzilla.gnome.org/show_bug.cgi?id=161467 *sighs* Apparently they're still convinced that librsvg is conformant to the standard (it's not). I added a comment. [ Those following along at home are invited to read the SVG 1.1 specification themselves, in case I missed something. ] > But they make a good point about reordering gradients: > > Is there any way that Inkscape can reorder gradients according to number? The numbering is sort of arbitrary, so that approach wouldn't work consistently. Ordering objects in <defs> according to their dependencies (what they're really asking for) would require some serious work, which I don't think is worth it for the sake of a non-compliant viewer. If the librsvg folks want to go off and make up their own vector markup language based on SVG, fine, but we're not obligated to go out of our way to support it. -mental

1 0

namespace handling fixes
by MenTaLguY 04 Jan '05

04 Jan '05

I just comitted some code that should handle namespaces properly when saving. I've removed all the manual xmlns declarations that were stuck in the code; instead, they are now generated automatically and inserted into the output document on save. The new code can also use a specified namespace as the default namespace in a saved document, when it is possible to do so. Under normal circumstances we now save documents with SVG as the default namespace. Test and let me know if anything broke (it seems okay on my end). -mental

2 4

Re: [Inkscape-user] Results of librsvg bug: Inkscape action?
by bulia byak 04 Jan '05

04 Jan '05

On Tue, 04 Jan 2005 16:02:03 +0000, Andrew Conkling <andrewski@...633...> wrote: > ------- Additional Comment #5 From Dom Lachowicz 2005-01-02 16:32 ------- > it is best, in my opinion, if the SVGs are emitted in a "streamable" > format, which means that gradient 578 should appear before gradient 581 in > the file. 1. Sorting ids is not sufficient, generally. Gradients can have arbitrary ids. Their links can be arbitrary trees, not only linear chains. 2. Since sorting ids is sufficient in most cases but not in all, I don't want to code this partial solution into the application. This seems to be a good use case for output extensions. Thus, sorting elements is trivial in XSLT; you can write an XSLT stylesheet that rsvg-ifies our SVG and submit it, and someone will then hook it up as an extension. 3. Though we have fixed most of the same problem in Inkscape, some pieces still remain unfixed (bug 989084). I'd rather that we spend effort on fixing these.

1 0

NEW: invert selection, -in-all-layers
by bulia byak 04 Jan '05

04 Jan '05

The new Invert Selection command (the `!' key) inverts selection (deselecting what was selected and selecting everything else) within the current layer. Both Invert Selection and Select All now have "in all layers" variants that act across all visible and unlocked layers (Ctrl+Alt+A for Select All in All Layers, Alt+! for Invert Selection in All Layers).

1 0

Re: [Inkscape-user] FlowText line height and justify
by bulia byak 04 Jan '05

04 Jan '05

On Sun, 02 Jan 2005 22:47:51 +0100, Martin Ždila <zdila@...631...> wrote: > Hi friends > > Is there a way to set line spacing (line height) between lines of flowed > text? line-height in flowPara element doesn't work. That's one of the reasons why flowtext is not yet officially supported. The problem is, I don't see in the SVG 1.2 draft any mechanism for line height! I just recently ran into this, so I'm cross-posting this to the devel list hoping that someone can share some insight on this. I could not even find a mention of line height here: http://www.w3.org/TR/SVG12/ If someone is more lucky than I, I would be grateful for a pointer. Now, I'm reasonably sure that the mechanism SVG has in mind is the line-height CVS property. However it is not mentioned anywhere in the draft, which worries me. I can implement line-height support but I want to be sure first. > And for text > justification / alignment text-align doesn't work too. That is less problematic, SVG draft mentions the text-align property which we must support.

2 3

proposed change to icons
by Ben Crowell 03 Jan '05

03 Jan '05

Bryce wrote: >Since our development policy is "patch first, discuss later", I don"t >think we should make a decision about the defaults until the options >were all available for review. I've committed changes to eight of the icons (rotate, flip, raise, and lower), and that's all the changes I want to make. I'll leave it up to others to decide whether keep these new versions as is, tweak them further, or revert them completely to Bulia's versions. AFAIK, there is currently no mechanism for maintaining multiple versions of the icons from which users can choose. Mine are the current defaults, but if someone else wants to create a multiple-icon-option mechanism, and then debate which set should be the default, that's fine.

3 4

Re: [Inkscape-devel] Suggestion for the preferences dialog
by Bryce Harrington 03 Jan '05

03 Jan '05

On Tue, 28 Dec 2004, Andreas Nilsson wrote: > >What approach did you use to create this mockup? > > > >I gave a shot at trying to mock up something with glade, but with > >disappointing results. However this definitely looks doable. > > > >Bryce > > > > > Well, I used the Gimp... Cool, it looks really good. I'm not sure if we'll be able to replicate it exactly, but I think we should strive to get as close as we can - this looks extremely good. > I am trying to learn Glade, but so far, all my attempts have been > unsuccesfull. Yeah same here, I thought it might provide a shortcut to having to implement the tree management stuff, but no such luck. It does not appear to generate code for managing tree widgets, and the stuff that it can do well is reasonably straightforward to do by hand. Anyway, so I'd say, stick with gimp. ;-) > I do really hope that I have not created an uncodable monster here. :) > - Andreas Nilsson Nah, it'll just be a considerable challenge. :-) In fact, I had noticed earlier that we needed tree-oriented editing dialogs for several other purposes - the XML tree, layers, extensions, and possibly keyboard layouts. I was going to emulate the XML editor design, but what you've done for the preferences dialog looks like it provides the same basic capabilities, and I'm thinking that if we can implement this design, we can reuse it in at least 4 places. One alteration I'm considering in order to support the other kinds of dialogs is a toolbar on the top of the dialog (see the XML editor). For the XML editor this is used for adding/moving/deleting nodes. How do you think we could use this in the preferences dialog? Perhaps the help button could be moved up there (saving some space on the bottom of the screen?) Perhaps an 'export preferences' function? 'restore defaults'? The other thing I'm wondering is that some people are going to really like the extra space between widgets in the dialog (and it helps us adhere to the HIG, as you point out), however others will prefer more concise use of space in order to maximize the dialogs they can have open at once. Preferences are unlikely to be something people will want to have up all the time, and same with extensions, however with the XML editor and layers I'm not as sure - what do you think? Bryce

6 12

Volunteer work and an idea how to get into existing code bases
by Felix Rabe 03 Jan '05

03 Jan '05

Hi Bryce, It's a shame that I only saw your calls for volunteer work now that you replied to them yourself... But I think this is an excellent idea to invite new developers! There needs to be more of it, or maybe it just needs to be more visible (like with a tag in the subject, eg. "[CFV]" for "Call For Volunteers"). In fact, I was looking for an easy way to familiarize myself with existing (poorly or barely documented) code bases and came up with this (as yet sadly unimplemented) idea: Look for a bug that has been fixed sometime in CVS and get a diff for the fix. I think it might be another good invitation and might add value to code documentation if some good (ie. easy) fixes and enhancements were pointed out in the Wiki by the developers that commited them to CVS or by the newbies that found the diffs and found them to be straightforward. If I someday get to implement this idea, should I start a Wiki page? (This might take a few months though...) Or is somebody else willing to do it? Or is it a not-so-god (bad) idea altogether? Greetings, Felix

4 3

Open Clip Art Library Release 0.09 Announcement :: http://www.openclipart.org
by Jon Phillips 03 Jan '05

03 Jan '05

*PLEASE FORWARD* Open Clip Art Library Release 0.09 Announcement http://www.openclipart.org Release 0.09 of the Open Clip Art Library is now available for download on the site as an individual package: http://www.openclipart.org/downloads/openclipart-0.09.tar.gz http://www.openclipart.org/downloads/openclipart-0.09.zip This new package is 20MB and contains 3104 unique user-submitted files, an increase from previous releases. The Open Clip Art Library is also browsable at www.openclipart.org where one might find specific clip art by searching through categories such as animals, education, transportation, or geography. Thank you to everyone who sent encouraging e-mails while the Open Clip Art Library's hosting project, freedesktop.org, underwent necessary maintenance due to a server break-in. freedesktop.org now has a much stronger server management system in place and our services are now completely back on-line from the incident. This intermittent downtime caused our developers to consider mirroring strategies. If you have any server space available and would like to host a mirror, please e-mail our mailing list. In the end, these events bolster an open source project and make it much stronger. To start the new year right, we decided to restart our montly release cycle, and begin to focus our attention to the project roadmap (http://openclipart.org/cgi-bin/wiki.pl?Roadmap). For the upcoming 0.10 release, we encourage submission of Valentine's Day themed artwork, to help users with their love life. Behind the scenes, we will be integrating Bryce Harrington's Document Management System (DMS) to mediate the submissions we receive. DMS is a real breakthrough in document management, which is akin to source code management (CVS, SVN, etc), but for everyday practical group projects, versioning, and collaboration using various file formats. Our core developers have also been discussing a few different sub-projects such as adding support to our services for Font submissions (http://openclipart.org/cgi-bin/wiki.pl?Open_Font_Library) and also a way to auto-generate greeting cards (http://openclipart.org/cgi-bin/wiki.pl?Greeting_Cards). Please add your comments to the aforementioned wiki pages and help us realize these ideas in the coming year! If you are interested in this project, please join our mailing list (http://freedesktop.org/mailman/listinfo/clipart), check out the roadmap (http://openclipart.org/cgi-bin/wiki.pl?Roadmap), and continue to submit your clip art! As the new year starts we are hoping to attract new developers and artists to work on the project. Happy New Year! Visit the Library at http://www.openclipart.org/

1 0

Re: [Inkscape-devel] Inkscape 0.41 release plans
by Ben Crowell 03 Jan '05

03 Jan '05

>Also Ben Crowell's Perl >scripts and XSLT scripting are very nice features that should be more >accessible, if possible, via the Scripts dialog or otherwise. Incorporating some of the Perl scripts would be fun, and I'd like to do it. However, IIRC there is still only a sketch of an API? Give me an API, and I'll get to work. Basically I need: - a way to get an svg file as input, and send it back as output - a way to report errors (including errors due to not having the right CPAN modules installed) - a way to get input strings from the user - a way to display some documentation to the user about what this script does - provisions for internationalizing all the strings the user will see Also, some of my scripts have known unixisms, which I can clean up, but I will still need help with testing on Windows, since I don't have a Windows box.

3 2

CVS not compilable
by bulia byak 03 Jan '05

03 Jan '05

1. In src/io/Makefile_insert, several files are listed with InitialCaps but they are actually all-lowercase, so make fails. 2 After fixing 1, I get: io/xsltstream.cpp: In member function `virtual void Inkscape::IO::XsltOutputStream::flush()': io/xsltstream.cpp:183: error: `xmlErrorPtr' undeclared (first use this function) io/xsltstream.cpp:183: error: (Each undeclared identifier is reported only once for each function it appears in.) io/xsltstream.cpp:183: error: syntax error before `=' token io/xsltstream.cpp:184: error: `err' undeclared (first use this function) Please fix these ASAP, and please be careful to not leave CVS in uncompilable state, especially on holidays when it may be hard to reach people.

4 6

Re: Inkscape interface
by Jon Phillips 02 Jan '05

02 Jan '05

Joshua wrote: > Good day, Jon, Alan and Peter. > > > > Attached to this e-mail is just a simple little mock up of an idea for an alternate Inkscape interface. > > > > Since most users like the current interface, there would, of course, be no need to change it. But when I read that, amazingly, future versions of Inkscape will incorporate SVG animation, (!) I thought the interface might need a little adjustment to incorporate future features (like the animation feature, filters, anything else that could be used to display the power of SVG). > > > > I could be way off with this, but it's just an idea. > > > > Thanks for the great work. > > Great, I've forwarded ths onto the Inkscape mailing list. I think the draggable toolbars that can be repositioned is a good idea. We do need to come up with a scheme for re-attachable menus, and your mockup is a step in the right direction. Please attach your email and screenshot to the RFE related to this: http://sourceforge.net/tracker/index.php?func=detail&aid=862662&group_id=93… Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 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)

5 6

Re: non-uniform text scaling
by vellum 02 Jan '05

02 Jan '05

Peter wrote: > For the moment I've backed out my change, as I consider this a worse > bug. I hope to fix things later. > Fair enough. I got the impression earlier from Bulia that the non-uniform scaling area was a little messy to work in. Anyway my original needs have been addressed for which I'm really happy, and I raised that bug for the record. Will you reinstate the bug? Since it will still be there until the code is fixed properly. When you do decide to fix it let me know and I'll be happy to test and compare with other programs. vellum

4 6

the big removal of 0.8s and 1.25s
by bulia byak 02 Jan '05

02 Jan '05

As discussed recently, I have changed the zoom levels so that at 100%, one px unit is equal to one screen pixel. This change led to switching all internal calculations from a mix of px and pt to pure px. This simplified code in many places and got rid of lots of ugly 0.8 and 1.25 multipliers that were scattered throughout the codebase. Correspondingly, the default template now uses the px units. I think that makes sense, given that most people use Inkscape for screen graphics. Now zoom to 100% (the `1' key) and you'll see your graphic exactly as it will look when exported with default resolution (now 90dpi, not 72dpi as before). This is a pretty big change. I tested everything I touched, but I may have missed something. Please test thoroughly. All old files with saved zoom will now load at 1.25*zoom, but that's inevitable; if you see any other problems, please report here.

3 4

CFV: Update Inkscape FAQ
by Bryce Harrington 02 Jan '05

02 Jan '05

Here's another Call for Volunteers... The Inkscape FAQ is pretty good, but it's been a long time since someone did a thorough review of it and brought it up to date. We need someone who is reasonably knowledgeable about Inkscape to go through it and bring it a little more up to date. I think it probably also ought to have a table of contents with links to the Q's... 1. Save this webpage to your disk: http://inkscape.org/faq.php 2. Open it in a text editor 3. Review/revise each question 4. Add new questions you think are worth putting in 5. Remove any questions that are obsolete 6. Post your results here for a web guy to put on the site If you already have access for updating the Inkscape site, feel free to commit and update directly. Bryce

4 5

Inkscape Status 2005-01-01
by Bryce Harrington 02 Jan '05

02 Jan '05

Saturday, January 1, 2005 With 0.40 still warm from the presses, we've decided to press on with a 0.41 release in mid to late January. ScislaC and myself have prioritized the bugs, identifying 21 high criticality bugs. We've not decided the strategy for attacking these bugs but one way or another we must fix a large proportion of these before our release. At the prompting of new members in the Inkscape development community, I've written up a set of 'Call For Volunteers' posted to the mailing list at the end of December. Meanwhile, Derek (aka Jizzbug) and myself have been pounding out the Gtkmm code. The plan is to see this integrated into the main codebase immediately after the 0.41 release. The stats are steadily improving, and we're seeing continued growth in both our development and user communities. Welcome, new folks. :-) The translation ratio has notched up a bit more, however our bug ratio has slipped down a percent from 15% in Dec to 16% now. However, I'll bet we knock it back down for the 0.41 release. Statistics Nov 1 Dec 1 Jan 1 ========== ===== ===== ===== Lifetime Rank on SourceForge: 684 636 598 (95.2%) (95.6%) (95.8%) Max Week's Rank on SourceForge: 62 16 45 (99%) (99.9%) (99.8%) Total SF Page Views 1,487,659 1,921,981 2,213,324 Total SF Downloads 69,078 89,345 110,182 Total Freshmeat URL Hits 11,849 13,351 14,291 Total Freshmeat Subscriptions 125 141 149 Lines of Code in src/: 306,602 309,285 321,883 Code lines 217,198 218,803 227,114 Comment line 53,262 53,798 56,048 Blank 42,699 43,249 45,398 Lines of Docs in doc/: 16,841 17,901 17,901 Lines of content in website: 8,121 8,732 9,234 Size of the Inkscape wiki: 18,977 21,379 21,030 Bugs open/total: 104/683 119/774 135/829 Features open/total: 279/426 307/467 340/514 Patches open/total: 7/130 5/143 5/145 CVS Commits (as per inkscape-cvs) 8,279 8,878 9,450 Inkscape-devel membership: 108 120 132 Inkscape-announce membership: 113 137 147 Inkscape-user membership: 144 162 172 Num Translations: 33 33 33 Ave Translation Ratio: 38.5 42.2 43.7 * - Statistics unavailable

1 0

CFV: Inkscape Examples Webpages
by Bryce Harrington 02 Jan '05

02 Jan '05

Hi all, Felix made a good suggestion to start posting some 'Call For Volunteers' on tasks that new folks would find straightforward to work on. Here's the first. A while back I started an 'Inkscape Examples' section on our website. We've got a couple things posted, but it's been largely neglected. We need a volunteer to take charge of beefing this section of the website up. This task requires good HTML skills (PHP helps too). No Inkscape development knowledge is needed. Art/design talents will also be pretty important. The purpose of the Inkscape Examples site is to show off different _ways_ Inkscape is used. It's needs to go beyond just showing off new features (we use the Screenshots page for that), but must be complete works. It's not intended to be simply a place for users to post their work (we have a Gallery section, plus OCAL and Deviant art for that), but rather to provide _one_ example of different _type_ of use. It's not intended to teach people how to use Inkscape (we have the Tutorials for that), but more to inspire and entice people into using Inkscape in new ways. Ideally, the site should have a listing of different types of things that can be made with Inkscape, with each having a link to a set of pages describing that thing. (Sort of like a woodworking magazine article showing how to build a cabinet.) For example: * Web site design * CD booklet * Portrait * Presentation * Cross-stitch pattern * Icon set * Landscape design * Org chart * Company logo * etc. Also, there could be examples of different art "styles". For instance, creating 'distressed' art like Brisgeek is into right now, or using the Trace Bitmap feature to artify a photo, or creating three dimensional effects via spherical gradients. "Presentations" could have a link to a page containing an example presentation that someone made, a set of steps for how the user created their presentation, problems/solutions encountered, and the source files for review. Sort of like an article in a woodworking magazine explaining how the author built a table. I think this effort could be done by just collecting examples of work other users have done and posted, interviewing the creator, and writing it up into a decent example, and putting it onto the website. I'd bet, if done well, you could also get it published in an online magazine like OS News. If you want to work on this, your first step will be to go ahead and put together an example of something, and post it here. We will also need someone to take care of editing/reviewing examples and posting them into the website, so if you're interested in doing that, send me your SourceForge ID. Bryce

3 2

[Fwd: Inkscape interface]
by Jon Phillips 02 Jan '05

02 Jan '05

Here is an email I received a few minutes ago... Jon -------- Original Message -------- Subject: Inkscape interface Date: Sat, 1 Jan 2005 14:07:12 -0500 (EST) From: Joshua <jwar@...629...> Reply-To: jwar@...629... To: jon@...235..., horkana@...44..., Peter.Moulder@...38... Good day, Jon, Alan and Peter. Attached to this e-mail is just a simple little mock up of an idea for an alternate Inkscape interface. Since most users like the current interface, there would, of course, be no need to change it. But when I read that, amazingly, future versions of Inkscape will incorporate SVG animation, (!) I thought the interface might need a little adjustment to incorporate future features (like the animation feature, filters, anything else that could be used to display the power of SVG). I could be way off with this, but it's just an idea. Thanks for the great work. -Joshua / Jiaxiang _______________________________________________ No banners. No pop-ups. No kidding. Make My Way your home on the Web - http://www.myway.com -- Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 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 1

Fw: non-uniform text scaling
by vellum 02 Jan '05

02 Jan '05

Bulia wrote: >What was the change and what was the bug? Bulia, Peter will probably get back to you. The original bug was a record of non-uniform scaling of text causing incorrect pt size designation of font. Peter made changes to correct this and I tested a day or so later as reported below. The new bug was that transformed text could not be transformed again back to a known pt size. This was worse than the original. Hence Peter removed his changes. The original bug should be reinstated in the bug list. vellum ----- Original Message ----- From: "vellum" <kaver@...68...> To: "Peter Moulder" <Peter.Moulder@...38...> Sent: Saturday, January 01, 2005 3:51 PM Subject: non-uniform text scaling > Peter, > I have tested your changes using 0412311700. The changes you have made seem > to work to cure the original bug. However, I think they have created or > uncovered another one. That is: The transformed texts cannot be transformed > back to the original point size. > > In Xarax. Transform say a 10pt text non-uniformly to some other value say > 37.32pt. Select the transformed text and choose 10pt as the font size, > apply. The text will go back to 10pt. > > In Inkscape transform the 10pt text non-uniformly to 38.6pt. Select > transformed text, choose 10pt, apply. The text goes back to 14.3pt. Further > attempts to change it to 10pt are to no avail. > > When the text is transformed uniformly then there is no problem with > Inkscape. And that seems to be the case whether the width/height lock is on > or whether it is done with Ctrl drag. > > In your second comment on the bug sheet 041231 4:41. I think I understand > what you are saying regarding the translation and the other two columns of > the transformation matrix. However, I do not know what the other two columns > are called and each of the other programs tends to have these values hidden, > or if shown it is not clear what they are. When I change values in the > transformation matrix the text seems to go all over the place since I do not > know what I am changing. > > Can you tell me what Column 1 and Column 2 are called? Then I can get onto > your request. > > regards, vellum > >

1 0

[Fwd: Re: [Inkscape-devel] CFV: Inkscape Examples Webpages]
by Felix Rabe 01 Jan '05

01 Jan '05

I'm still not used to this strange kind of replying :/

2 2

elongating lines doesn't work anymore
by David Christian Berg 01 Jan '05

01 Jan '05

Hey guys, first of all let me wish you a wonderful year 2005! May it be rewarding not only concerned the Inkscape development. Now: I don't have latest CVS, so maybe this is fixed again. My RFE "[ 1036484 ] Elongating straight lines" that was fixed by Bulia seems to have to be reopened. At least I don't manage elongating lines using a modifier key anymore. Any clues? David

2 2

dividing the inch
by Aaron Spike 31 Dec '04

31 Dec '04

It is customary to divide inches in halves, fourths, eighths and sixteenths, right? In Inkscape dark grid lines (love that feature by the way) and ruler marks appear in halves, fifths and tenths. sp_ruler_metrics in sp-metrics.h has it all right. But sp_ruler_set_metric is only called in desktop.cpp and SP_PT is hardcoded as the metric. To make the divisions follow the document preferences the call to sp_ruler_set_metric would probably have to be moved farther down the line into sp_desktop_widget_update_rulers and some math would need to be changed. I don't know if Inkscape would want to do this. A really feature bloated app might even let you work in your prefered unit and configure you own arbitrary divisions. Then I could divide inches in thirds. I tried hacking out a change for this a while back and started to get the idea that messing with units probably wasn't appropriate for a newbie with now knowledge of C++. It seems messing with units actually means messing with the fundamental assumptions on how Inkscape should deal with units. So I don't have a question, as such, I would just like to see what others think. Aaron Spike

2 1

CFV: Gtkmm - Develop a Context Menu
by Bryce Harrington 31 Dec '04

31 Dec '04

Okay, last Call for Volunteers today, I promise! This one will be quite tricky and requires good knowledge of C++, Gtkmm, and the Inkscape codebase. The menu needs to be very dynamic and well tied in with Inkscape's internals, so if you don't already know Inkscape code thoroughly, you'll need to be prepared for a lot of digging and learning. Fortunately, you can start simple and build up as you go. :-) 7. Context Menu ================ The current context menu in Inkscape is not very powerful. We can do better. First skim through the tutorial on context menus on the gtkmm.org site: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch10s03.html In the Gtk+ codebase, the context menu is implemented in the function sp_ui_context_menu, in the file interface.cpp. Review that function to see how the context menu works currently. As a general rule, there should be no more than about ten items total on the context menu. The context menu, by definition, should customize the set of items it displays to the user based on what the user has right clicked on. It should tie in with the Actions system, and should display appropriate menu items for the selected context. The context menu must check the context item against the current selection. The context item is the thing directly under the mouse cursor when the right-click action occurs. The current selection is the item or items selected by the left-click menu. Note that it's definitely possible for these to be different - the user may left click to select a circle, then right click over a rectangle to change its properties. It is also possible to have no selection, or to select multiple items. Each of these implies a different type of context, and would be handled differently. If the context item is completely different from the selection, then display only actions which don't require the object to be selected. For instance, do not display the 'Delete' action, since that will cause the _selected_ item to be deleted rather than the context item. Same thing for cut, copy, etc. Note that context commands should *not* change the selection to get around this. If the context item is the same as the selected item, then detailed operations should be shown for that item, including actions that can be performed on selections. In this case, you'd display Delete, Cut, Paste, etc. If multiple items are selected, and the context item is one of the items in the selection, then present actions that can be performed on multiple selected items. Delete, cut, copy, duplicate should act on all selected items, for instance, and commands for group, Text-on-path, booleans (Union, Difference, etc.) should be presented. If the context item is part of the chrome (i.e., a toolbar button, the status bar, etc.) then display a context menu appropriate to that item, plus some commands specific to the inkscape application itself. For instance, it should allow all of the actions available through doubleclick, shift-click, alt-click, etc. with the button, and inkscape preferences, view/hide the chrome item, etc. Think about the context menu in three sections. The top third and bottom third should have the most commonly expected commands, and the middle should have the less common commands. The top (and sometimes the bottom) will be the closest to the mouse cursor when popped up so it will be most convenient for common actions to be located there. The middle is less accessible so rarer functions should be placed there. Strive to always place the same command in the same location in the context menu. The top portion of the menu should have actions which are common, frequently used commands needed for any shape or context. The bottom portion should consist of the commands that are common for the specific shape or context selected. The middle portion should consist of commands specific to the shape or context, but less commonly used. Any action available in the context menu should also be available through other means, but you can include actions that otherwise require several clicks. For instance, in the context of a font item, you could include actions for changing the font size; this is normally available only by first opening the text and font dialog, then selecting the font size from the font size widget. To get the Gtkmm codebase: $ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape Bryce

1 0

CFV: VDX and PDF extensions
by Bryce Harrington 31 Dec '04

31 Dec '04

For those interested in learning more about extensions, here are two that might be worth incorporating: http://vdxtosvg.sourceforge.net/ http://www.solidcode.net/pdf2svg/ Try them out - do they actually look useful and compatible with Inkscape? If so, add them to our extensions. You'll need to create a .inx file (see /usr/share/inkscape/extensions/ for examples), and test it out on a variety of files to make sure it's not too buggy. Then post a patch to the patch tracker (or report back if it looks like a no-go). Also, if you can find any other xxx2svg filter programs out there, go ahead and test out adding them too. Good places to look include svg.org and Freshmeat.net. You can also create your own filters pretty easily using packages such as perl's SVG.pm. I had good luck at hooking together SVG.pm and Perl's POD converter to create a pod2svg filter. ;-) Bryce

1 0

grid (and ruler) units
by Aaron Spike 31 Dec '04

31 Dec '04

I've seen it in my web logs a few times now. People are searching google to find out how to change the ruler units in Inkscape. I'm not surprised because that was one of my first questions. I ended up finding the answer in the release notes. If the "Document Preferences" dialog said "Grid and Ruler units" instead of just "Ruler units" the answer would be more apparent. If that isn't acceptable it could go in a FAQ. Aaron Spike

2 1

CFV: Performance measuring/testing
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's a much more techie task we need done. Over the past several releases there's been some observations of slowness in the Inkscape renderer. We'd all like Inkscape to be nice and snappy, even for huge documents. However, we've not really had good, standardish ways of measuring performance. A good way of measuring it would be helpful in several ways: It'd help developers quickly see if a change improves or degrades performance; it'd enable us to track performance from release to release; and, it'd be a tool we could add new performance "Problem Cases" to as we go. The task is to create a collection of scripts that one can run on a copy of inkscape, that exercise it in some different ways and records the speed it did each thing. Right now, you can do some testing by just running Inkscape in cmdline mode on a large .svg file, and time how long it takes for Inkscape to startup, create the .png, and exit. (Later, maybe we can add some testing triggers inside the code so we can better measure performance of particular pieces (like just the startup time, just the gui init, etc.) Also, later hopefully we'll have some internal scripting or Atk support to allow further automated testing of the app. But static runs should be enough to give us some good info to start with.) It would be interesting to run this performance suite against older versions of the software, and measure how performance has changed over time. It'd be especially cool if this could produce an SVG graph. :-) Bryce

1 0

CFV: Update Roadmap
by Bryce Harrington 31 Dec '04

31 Dec '04

Here's another task... This one needs to be done fairly soon; I'm hoping to get to it later this weekend if nobody else can. We've decided to have an accelerated 0.41 release in mid to late January. This means that we need to shuffle the roadmap. Wiki skills are needed. Some knowledge of Inkscape's development activities would be helpful, but if you're good at asking questions you won't need much depth. http://inkscape.org/cgi-bin/wiki.pl?Roadmap * Tasks related to gtkmm need to be moved from Milestone 7 (0.41) to milestone 8 (0.42). * Most development tasks for 0.41 will also need to be bumped forward to 0.42 (speak with bulia, mental, etc. if you have questions - or ask them to update their tasks directly) * Most or all tasks listed for Milestone 8 (0.42) need to be bumped up one number, to Milestone 9 (0.43). Also bump all the subsequent tasks up one release number, too. * Also update the website copy of the roadmap: http://inkscape.org/roadmap.php Thanks, Bryce

1 0

Re: [Inkscape-user] proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

After posting on inkscape-user and increasing the sample size, it seems to me that there is a clear consensus in favor of the new style. Bulia wrote: >There's no need to argue. Ben, you can continue working on the new >icon set, and when you are ready we will ship your icons.svg alongside >the old one, so people can choose whichever they like. Trent, the same >for you: you are welcome to develop a set of icons that work best for >your black background, and we'll ship them also. When there's at least >one complete set besides the old one, we can make a preference with a >UI to choose one of them on load. The real issue is whose icons will be the defaults. Since most people seem to like mine better than yours, I think mine should be the defaults. I would like to request a clear decision on this from the core developers before I invest a lot more time on the icons.

3 3

about inkscape in FreeBSD
by Albert 31 Dec '04

31 Dec '04

Dear developers, I have found that surprigsingly the new ports tree for FreeBSD 5.3 can only install and run inkscape 0.38 The mantainer claimed that there are several memory leaks issues because of the usage of boehm-gc, as explained here : http://lists.freebsd.org/pipermail/freebsd-gnome/2004-December/ 009256.html Are the developers aware of this issue? Is there any hope to have a FreeBSD running 0.40 version any time soon? Thank you. Albert

3 2

proposed change to icons
by Ben Crowell 31 Dec '04

31 Dec '04

I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking.

7 9

Help needed with UI work in Gtkmm codebase
by Bryce Harrington 30 Dec '04

30 Dec '04

If anyone's interested in contributing some time to the new Inkscape UI work, we can use some help with setting up the menus. It's extremely straightforward work, there's just a lot of it to do. Basically, for each menu item we need to write code to establish things like handlers, signals, descriptions, etc. I've coded up a examples for several menu items, so you'd just copy and extend that for all of the menu items. If you're interested in working on this drop me a line and I'll fill you in. The task writeup is in the PLAN document in the 'experimental' module in CVS, under bryce/inkscape_gtkmm/. Bryce

1 1

Volunteer needed for bug prioritizing
by Bryce Harrington 30 Dec '04

30 Dec '04

One of the first tasks needed in the lead-up to the 0.41 release is to go through the new bugs in the bug tracker and prioritize them. This is a straightforward task, and takes one evening to do. I usually tackle this myself but since I've been rather busy with gtkmm lately, I'd love to encourage someone else to take it on. The new bugs are the ones that are listed at Priority '5'. The task is read them and then change their priority to 3/6/9 depending on if they are low/med/high. High priority bugs are those that cause data loss or application crash. In addition, if the bug reports are too terse I try to add a note requesting more info. If it looks easy to reproduce and I have some extra time, I sometimes give it a shot and comment if I see the problem too. That's pretty much it. If you'd like to help with this task let me know, and I'll set your admin privs for the bug tracker so you can do this. Thanks, Bryce

1 1

Newsforge Inkscape article (fwd)
by Bryce Harrington 30 Dec '04

30 Dec '04

---------- Forwarded message ---------- Date: Thu, 30 Dec 2004 07:16:33 -0800 (PST) From: Jiaxiang <jwasheville@...36...> To: Bryce Harrington <bryce@...260...> Subject: Newsforge Inkscape article Good day, Bryce. Did you catch this article about Inkscape on Newsforge.com? http://www.newsforge.com/article.pl?sid=04/12/23/1638201 -Joshua __________________________________ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com

1 0

Re: [Inkscape-user] proposed change to icons
by bulia byak 30 Dec '04

30 Dec '04

There's no need to argue. Ben, you can continue working on the new icon set, and when you are ready we will ship your icons.svg alongside the old one, so people can choose whichever they like. Trent, the same for you: you are welcome to develop a set of icons that work best for your black background, and we'll ship them also. When there's at least one complete set besides the old one, we can make a preference with a UI to choose one of them on load. As for me, I prefer the crisp, bright, and laconic style and, when I create new icons in my set, I will continue developing that style. Everyone can use what they like.

1 0

proposed change to icons
by Ben Crowell 30 Dec '04

30 Dec '04

On inkscape-devel, I've proposed some changes to some of Bulia's icons. Some people seemed to like the new versions better, and some didn't. We didn't seem to have a statistically significant sample of opinions, so I'm reposting now to both inkscape-devel and inkscape-user. I've made some changes to the icons in the copy of Inkscape I have running on my own machine. If other people agree that this is an improvement, I'll do some more work in the same style. Here is a screenshot: http://www.lightandmatter.com/proposal.png The rotation and flip tools are my new versions, and next to them you can see the lower and raise icons in the original style, with the greenish-yellow color. My idea here was to tone down the colors a little, and also use transparency to create more of a visual impression of the object rotating. It's meant to look like the new Gimp 2.0 icons, which IMO are very professional looking. The svg from which the icons were constructed is here: http://www.lightandmatter.com/icons.svg Please give an on-list opinion in binary, 0=don't change, 1=change. (The icons can be tweaked more later, of course, if there is a consensus for it.)

3 2

save as format
by bulia byak 30 Dec '04

30 Dec '04

Recently save and save as started to default to Plain SVG instead of Inkscape SVG. Very annoying. Those who touched this code recently, could you please look into it?

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

>> What I would like to see is that when I load a document that I've >> explicitly set dimensions to - such as a woodworking project set to >> inches, or a game map set to km, or my website layout set to px, that >> they show up that way, but by default if I start a new drawing or open >> one that has not had any units specified for it, that it defaults to my >> preference (cm or whatever). >This is exactly how the current system works. Except for the last part >- it always defaults to pt if no units specified, but this can be >changed. I think it should be changed. I agree with Bryce -- it should be possible to set a per-user pref that would automatically be applied to new documents.

1 0

Re: [Inkscape-devel] NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

IMO it would be more useful to be able to set the default units on a per-user basis, rather than on a per-document basis. The method of storing the preference in a standard piece of stationery requires extra steps from the user. Personally I just want millimeters, always, and never anything but millimeters :-)

4 6

NEW: units, misc
by Ben Crowell 30 Dec '04

30 Dec '04

First of all, as an American, let me just apologize to the rest of the world for being the only country in the world stupid enough not to have embraced the metric system. Anyhow, I'd like to propose doing what Adobe Illustrator does (or what I think I remember it does). Every user has a preference for the unit he likes to use by default. When he creates a new document, everything in that document is by default measured in those units, but he can change that on a per-documet basis.

2 1

Re: [Inkscape-devel] Suggestion for the preferences dialog
by Ben Crowell 30 Dec '04

30 Dec '04

The mockup looks nice! I would really like to have a way to set my prefs so that the units of measurement always default to mm rather than points.

3 7

Spam!!! Fw: [Inkscape-devel] Дешево
by Anatoly Podlesnuk 30 Dec '04

30 Dec '04

This is a spam! Please block this email dalpiger@...329... -----Original Message----- From: "Latisha Kline" <dalpiger@...329...> To: inkscape-devel(a)lists.sourceforge.net Date: Wed, 29 Dec 2004 00:13:06 -0700 Subject: [Inkscape-devel] Дешево > Нoвыe cотовые, ноутбуки, КПК за З0проц. oт cтоимocти wB8. > > jD http://198.66.213.30/?6T1sDmrBU4psZ zJD > > Санкт-петербург,карта www.meteo-tv.ru > >

2 1

NEW: units, misc
by bulia byak 29 Dec '04

29 Dec '04

* Document units: now you can set the default units for each document in the Document Preferences dialog. These units apply to the rulers and the statusbar coordinates (previously unchangeable) and are preselected in all unit menus (such as in the Selector controls bar). The units are saved with the document, so you can make yourself a default template with your preferred units. * The px (pixels) unit is added to most unit menus. This is what is called "user unit" in the SVG specification, and in SVG code it is written either with the px suffix or (more often) without any suffix. Inkscape converts most dimensions to user units when writing them to SVG, and now you can use this unit via the GUI as well. Note however that the conversion ration from px to absolute length units may vary in different SVG renderers and different output media (e.g. Inkscape uses px/pt = 0.8 for screen editing), so you should not use px and absolute units in the same document. If you want one px to correspond to one bitmap pixel on export, use the export resolution of 90 dpi. * In Selector, the statusbar now reports not only the number of selected objects but also the number of layers in which they are selected and, if there's only one, the name of the selection layer.

2 3

Initial checkin of stream package
by Bob Jamison 29 Dec '04

29 Dec '04

Hi, all. Today I added the /src/io dir to the automake tree. It has some new interfaces and implementations whose purpose is to make it easier to read and write streams of data. Basically they are lightly based on java's input and output streams and readers and writers, and -not- on iostreams, which turned out to be too much of a burden for too little benefit. It is intended that they can be subclassed and/or chained together to get the desired effect. Also, they encourage people to use Inkscape::URI's instead of char *filenames and FILE *. This has been discussed for months for the purpose of referring to resources, but has been slow in appearing. These two are based on bytes (unsigned char) ================================= InputStream -- reads unformatted (aka binary) data OutputStream -- writes unformatted data These are for formatted unicode IO (gunichar and Glib::ustring) ============================= Reader -- formatted (aka text) data input like stream >> data; Writer -- formatted output like stream << data. Also has a printf() InputStreamReader -- uses an inputstream as its source OutputStreamWriter -- uses an outputstream as its destination So far there are =========== (these need to be filled out, but work for files now) UriInputStream --reads data from an Inkscape::URI UriOutputStream -- writes data to an Inkscape::URI need to be implemented: ----------------------------- UriReader UriWriter These work in the tests: ================= XsltInputStream XsltOutputStream GzipInputStream GzipOutputStream StringInputStream StringOutputStream These need to be fleshed out and tweaked, but basically they are usable already. I need to run to an appointment, so I'm making this brief. I just wanted people to know that this is available. Bob

3 4

NEW: background color spillover
by bulia byak 29 Dec '04

29 Dec '04

Inspired by a recent message in the Sodipodi list, I did this: * The page background color is now applied to the entire canvas, not to the framed page only as before. Makes more sense than before IMHO.

1 0

Inkscape 0.41 release plans (Debian)
by Ben Crowell 29 Dec '04

29 Dec '04

Sorry, I'm new to Debian and still learning the ins and outs of apt-get :-)

1 0

��
by Latisha Kline 29 Dec '04

29 Dec '04

Mob{e cnrnb{e, mnsrasjh, JOJ g` G0opnv. or crnhlocrh wB8. jD http://198.66.213.30/?6T1sDmrBU4psZ zJD Q`mjr-oerepaspc,j`pr` www.meteo-tv.ru

1 0

Inkscape 0.41 release plans
by Ben Crowell 29 Dec '04

29 Dec '04

An 0.41 release would be very helpful. I'm collaborating on a book with someone, and he's intimidated by having to compile the latest CVS in order to get a certain crucial bug fix. He could download a nightly build, but I'm not sure if he'd have problems with libraries. Once 0.41 comes out, I can just tell him to download the statically linked binary. It would be interesting to hear from some of the packagers about how things are going. IIRC the person handling the FreeBSD port is struggling to fix some memory leaks introduced by the new garbage collector (OS-specific, apparently), so the BSD port is still at 0.38. I think the debian package is also lagging?

2 1

Spiro / Raph Levien
by Bryce Harrington 28 Dec '04

28 Dec '04

---------- Forwarded message ---------- Date: Wed, 29 Dec 2004 00:17:07 +0100 (CET) From: Jose Hevia <100026838@...625...> To: clipart@...330... Subject: Re: [Clipart] OCAL identified by IBM as resource for Linux migrations >From http://www.advogato.org/person/raph/ 16 Nov 2004 » Spiro I've tentatively chosen a name for my curve editor: Spiro. I posted a "code escape" here and on the Typophile forums. So far, I've gotten little or no response from my posting here, but lots of people checking it out and sending feedback on the Typophile board. Interestingly, many of the commenters are encouraging me to patent the idea and/or otherwise try to make money off it. I'll have a new code snapshot soon. In the meantime I've been tracing the miniscules from 72pt metal Centaur (see screenshot). There's nothing like trying to use the thing for real to point out what needs improving :) There's no rush, as I'm still tweaking the core algorithms, but obviously this is something that should go into other free software applications, most especially Inkscape. What I'm most inclined to do is release all the core code as GPL, package up nice Win32 and MacOS versions with refined GUI's (especially cut'n'paste with the dominant apps on those platforms) as commercial apps, and also try to license the code for inclusion in proprietary apps. We'll see how all that plays out. ->I'd been reading his diary for long 17 Oct 2004 » [...]If I go this route, I'll need to factor the code into UI dependent and UI independent parts. That's probably good discipline in any case, especially if I'm hoping for the code to be adapted into other apps that need curve editing (Gimp paths, inkscape, etc.).[...] Jose Hevia _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart

1 0

Changing helper/sp-intl.h refs to glibmm/i18n.h
by Bob Jamison 28 Dec '04

28 Dec '04

It was discovered by one of the guys in the Jabber room last night that sp-intl.h's wrapping of gettext() in the _() macro is redundant. It is already defined by glib/g18n.h, or more proper for us, glibmm/i18n.h. After getting the concensus that making the change was ok, I went ahead and did a mass search/replace, followed by a build to test it. I removed helper/sp-intl.h, and removed its entry in helper/Makefile_insert. I changed all of the #includes from helper/sp-intl.h to glibmm/i18n.h in the 169 files listed below. Sorry about the big commit, but anything that can remove unnecessary legacy code must be helpful. The build seems to be fine, but if anyone sees any problems, please tweak it. Bob ./arc-context.cpp ./desktop.cpp ./desktop-events.cpp ./dialogs/align.cpp ./dialogs/clonetiler.cpp ./dialogs/debugdialog.cpp ./dialogs/desktop-properties.cpp ./dialogs/display-settings.cpp ./dialogs/docker.h ./dialogs/export.cpp ./dialogs/filedialog.cpp ./dialogs/fill-style.cpp ./dialogs/find.cpp ./dialogs/item-properties.cpp ./dialogs/layer-properties.cpp ./dialogs/object-attributes.cpp ./dialogs/object-properties.cpp ./dialogs/rdf.h ./dialogs/scriptdialog.cpp ./dialogs/sp-attribute-widget.cpp ./dialogs/stroke-style.cpp ./dialogs/text-edit.cpp ./dialogs/tracedialog.cpp ./dialogs/transformation.cpp ./dialogs/xml-tree.cpp ./document.cpp ./draw-anchor.cpp ./draw-context.cpp ./dropper-context.cpp ./dyna-draw-context.cpp ./event-context.cpp ./extension/db.cpp ./extension/extension.cpp ./extension/init.cpp ./extension/internal/eps-out.cpp ./extension/internal/gnome.cpp ./extension/internal/ps.cpp ./extension/internal/svg.cpp ./extension/system.cpp ./file.cpp ./help.cpp ./helper/units.cpp ./helper/units-test.cpp ./inkscape.cpp ./inkview.cpp ./interface.cpp ./knot.cpp ./main.cpp ./node-context.cpp ./nodepath.cpp ./object-edit.cpp ./object-ui.cpp ./path-chemistry.cpp ./pencil-context.cpp ./pen-context.cpp ./print.cpp ./rect-context.cpp ./select-context.cpp ./selection-chemistry.cpp ./selection.cpp ./selection-describer.cpp ./select-toolbar.cpp ./seltrans.cpp ./slideshow.cpp ./sp-anchor.cpp ./sp-ellipse.cpp ./sp-guide.cpp ./sp-image.cpp ./spiral-context.cpp ./sp-item.cpp ./sp-item-group.cpp ./sp-line.cpp ./splivarot.cpp ./sp-offset.cpp ./sp-path.cpp ./sp-polygon.cpp ./sp-polyline.cpp ./sp-rect.cpp ./sp-shape.cpp ./sp-spiral.cpp ./sp-star.cpp ./sp-text.cpp ./sp-tspan.cpp ./sp-use.cpp ./star-context.cpp ./text-chemistry.cpp ./text-context.cpp ./text-editing.cpp ./toolbox.cpp ./tools-switch.cpp ./trace/trace.cpp ./verbs.cpp ./widgets/dash-selector.cpp ./widgets/font-selector.cpp ./widgets/gradient-position.cpp ./widgets/gradient-selector.cpp ./widgets/gradient-vector.cpp ./widgets/layer-selector.cpp ./widgets/paint-selector.cpp ./widgets/sp-color-gtkselector.cpp ./widgets/sp-color-notebook.cpp ./widgets/sp-color-scales.cpp ./widgets/sp-color-selector.cpp ./widgets/sp-color-wheel-selector.cpp ./widgets/spw-utilities.cpp ./widgets/sp-xmlview-attr-list.cpp

1 0

Suggestion for the preferences dialog
by Andreas Nilsson 28 Dec '04

28 Dec '04

(This might have been fixed in 0.40, but since I run Debian testing I still use 0.39. If that is the case, ignore this mail.) I currently find the preferences dialog a bit hard to navigate, partly because it feels a bit crowded, but mostly because it presents the usability problem of tabs in tabs. See for example the Interface Hall of Shame: http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/tabs.htm The tools/shapes creates the most trouble of navigation. (see http://ramnet.se/~nisse/diverse/temp/inkscape_tabsintabs.png) So, I did a little gimping and came up with a new preferences dialog similar to the one beep-media-player uses. http://ramnet.se/~nisse/diverse/temp/inkscape_new_prefs_mockup.png The icons are ones that I found on jimmacs site and thought somewhat fitted, or ones I drew very quickly. What do you think? - Andreas Nilsson

5 7

Inkscape 0.41 release plans
by Bryce Harrington 27 Dec '04

27 Dec '04

Hi all, After chatting with Ishmal, Mental, Bulia, and others, it sounds like we ought to shoot for cutting a near-term release, in the mid- to late-January timeframe. The reasoning for this is that we already have some noteworthy new features that would be worth getting out to users, and because the Gtkmm work, while progressing along well, won't be finished that quickly. If no-one has any serious objections to this proposal, we would go back into a feature freeze within the first week or so of January, focus on bug fixing for a couple weeks, and try to push out the 0.41 release by the end of the month. (As a side PR benefit, there are a number of conferences and symposia in the Feb/Mar period, so this would give fresh bits for folks to play with.) In parallel to the above release effort, the focus on the Gtkmm work will continue (and hopefully intensify), with the objective of merging immediately after the 0.41 release. The code won't be finished at that point, and won't be used for the primary UI (you'll have to use a special flag to activate the Gtkmm), but we'll finally have the code in the main codebase proper, which will hopefully enable the remainder of the work to get done swiftly. Bryce

4 5

possible bug
by Makurin Roman 26 Dec '04

26 Dec '04

When I trying to export my *.svg into *.png and path contains white spaces I`ve got an error. -- JID: drolyk@...189... ICQ: 105266647

1 0

SVG prefix commit
by MenTaLguY 25 Dec '04

25 Dec '04

Okay, I've comitted the change; from now on, name SVG elements in Inkscape like "svg:g" rather than "g". Important note: attribute naming has not changed, it's just elements I was pretty careful not to break anything, but I can't guarantee it; it was a pretty wide-ranging change. Let me know if anything broke. -mental

2 5

brief history of namespace support in Inkscape
by MenTaLguY 25 Dec '04

25 Dec '04

Just as a bit of background... Originally, in Sodipodi, namespaces were ignored entirely. Any element without a prefix was assumed to be SVG, xlink: was always assumed to be XLink, and sodipodi: always Sodipodi stuff. We did add xmlns declarations just to keep parsers happy, but that was it. Obviously that was deeply wrong to do. It was difficult for me to get buy-in for a sweeping change, however. What I did finally did get accepted was a simple hack -- I remapped the prefixes on load to what Sodipodi expected. So, at that point, if you loaded a document where the SVG namespace was bound to the blah: prefix, "blah:g" would become "g" in memory. Similarly, if ook: were bound to the Sodipodi namespace, "ook:namedview" would become "sodipodi:namedview" in memory. This is the code we inherited from Sodipodi, and the approach I refer to as "normalized qnames". Now, there were a couple shortcomings that remained: One, this was only done on load. The serialization code still didn't know anything about namespaces and we simply relied on stuffing a bunch of xmlns attributes in the document and hoping that covered everything. Not a simple thing to fix, unfortunately. Two, non-namespaced elements would appear to be in the svg namespace. This means that some non-SVG elements would get interpreted (and saved) as SVG elements. Thankfully, that was trivially fixable by normalizing svg elements to use the prefix svg: instead of none. As I noted on the Sodipodi list at that time, I did want to go back and address those two shortcomings, but Things Happened, and a year or two later I'm writing this. We did inherit both shortcomings, so it's high time I did something about them. I just knocked out the second one, and I'm hoping I can spend some time on the first one soon. The serializer improvements shouild actually afford a lot of opportunity to make our XML output prettier, including using shorter prefixes (e.g. maybe just i: for inkscape's namespace) in serialized files. And of course using SVG as the default namespace again, where practical to do so. -mental

1 0

I'm leaving a debug message in
by Ted Gould 25 Dec '04

25 Dec '04

Hey, I know that this is annoying, but I think it is important for a short while. The message that I'm leaving is a notice that an extension is being unloaded. This is because now extensions are getting unloaded if they aren't used for a while -- and this code has never been used before. But, since it happens seemingly randomly, I don't want people to start debugging something that is actually a bug in these unload routines. Now, I think that I've tested all the cases, but I'd like to keep it in for a while to make sure. -- Ted

1 0

Problems with XML Editor
by Valentin Cristescu 24 Dec '04

24 Dec '04

Hi, I can't start the XML Editor. The message is: Inskcape encountered an internal error and will close now. I'm using Fedora Core 3.

2 1

Non-coder tasks
by Bryce Harrington 24 Dec '04

24 Dec '04

Today a question came up regarding how non-coders can help improve Inkscape. This info has been added to the Inkscape FAQ, under 'Are there non-coding ways to help?': http://www.inkscape.org/faq.php Let me know if you have other ideas we could list there. Bryce

2 2

element namespaces
by MenTaLguY 24 Dec '04

24 Dec '04

FYI, now that things are sort of quiescent, I'm going to start on disambiguating the SVG and null namespaces, as I have threatened to do in the past. This means that (internally) we'll start using the svg: prefix to refer to SVG element names. "g" will become "svg:g" etc. Probably we will hide the "svg:" prefix in the XML editor though. Important things to remember: * this only affects the way we name elements, not attributes -- attribute names should remain unchanged as most standard SVG attributes are supposed to be in the null namespace (except for the xlink: ones) * only elements in the SVG namespace will be affected; the remainder are already named unambiguously * there is no inherent relationship between prefixes and namespaces; for practical reasons we have enforced one within inkscape, and we rewrite existing prefixes to match this mapping when we load documents -mental

5 16

[cairo] Very slow performance (fwd)
by Bryce Harrington 23 Dec '04

23 Dec '04

---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 09:54:59 -0500 From: Chris <fltk@...78...> To: cairo@...278... Subject: [cairo] Very slow performance I have some fairly complex SVG artwork that I created. I have noticed that the performance of Cairo is quite a bit slower than some other svg libraries. My image has about 3500 paths and on my machine this image takes less than a second to load and render in Inkscape (librsvg/libart based?). Even Inkscape feels slow compared to commercial applications when handling this file. I made a simple test program that loads this file and renders it to an image buffer in Cairo. It takes over 30 seconds to do this. That's incredibly slow and makes me wonder about the usability of Cairo in everyday applications. Would rendering to OpenGL or xlib be faster? I'm planning on adding SVG support to FLTK by using Cairo so even if those are faster that might not help me as FLTK has it's own cross-platform drawing functions that I will be using. Where is the bottleneck? Is libart just that much faster at doing the rendering? The source code for my simple test is here: http://www.functionalfuture.com/radical/cairotest.c The SVG image I'm using is here: http://www.functionalfuture.com/radical/centi_unfinished.svg.gz -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

3 2

Linking suggestion
by Bob Jamison 23 Dec '04

23 Dec '04

Hi, all, again. Now that Ted and I are going through the headaches of linking, extensions, shared objects, and their ilk, I have a suggestion about how we are linking Inkscape. Currently, the main Makefile.am is built at automake time to Makefile.in by reading all of its Makefile_insert files from the various subdirectories. The final 'inkscape' target is made as the result of libinkpre.a, all of the sub-libraries from each of the Makefile_inserts, then libinkpost.a. This is because of link-order problems. This is just my opinion, but wouldn't it be easier/cleaner to make one large libinkscape.a by concatenating it from each of (pick one) libBlah_a_SOURCES or libBlah_a_OBJECTS ... in each of the Makefile_inserts??? Then we would have one nice reference library that can be used by other projects, can be made into a .so or .dll, and that can more easily export its symbols. And best of all, there would be no link-order problems. This would in no way alter the set of Makefile_inserts that we have in the build tree. The main Makefile would merely use different information from them. The small .a's would still be built (or be buildable) and everyone can still do their private testing. It would only change the makeup of the large libinkscape.a lib. Any thoughts? This would not affect the majority of devs, but would -GREATLY- simplify the world for those of us who need to worry about link issues. Bob

5 7

problem compiling from CVS, python-related
by Ben Crowell 23 Dec '04

23 Dec '04

Thanks, Bob, for the hint about --with-python=no. I'm now experiencing a different error, shown below, which seems to be related to Perl. I'm trying now with both python and perl disabled. I actually have a modicum of Perl expertise, so if you can tell me what it is about my Perl install that's causing this failure, I might be able to add something to the configure script to autodetect it and give an informative error message. ============================================================== /bin/sh ../libtool --mode=link g++ -Wall -W -Wpointer-arith -Wcast-align -WsignWswitch -Wno-unused-parameter -g -O2 -o extension/plugin/libgimpgrad.la -rpatns extension/plugin/gimpgrad.lo -lgc -lpthread -ldl -Wl,-E -L/usr/local/lib /r/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lm -lpthread -lc -lcrypt *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against *** static library /usr/lib/perl/5.8/auto/DynaLoader/DynaLoader.a is not portabl g++ -shared -nostdlib /usr/lib/gcc-lib/i486-linux/3.3.4/../../../crti.o /usr/libginS.o extension/plugin/.libs/gimpgrad.o /usr/lib/libgc.so -L/usr/local/lib /u/DynaLoader.a -L/usr/lib/perl/5.8/CORE -lperl -ldl -lpthread -lcrypt -L/usr/lib//lib/gcc-lib/i486-linux/3.3.4/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc-libr/lib/gcc-lib/i486-linux/3.3.4/../../../crtn.o -Wl,-E -Wl,-soname -Wl,libgimpgrbs/libgimpgrad.so.0.0.0 /usr/bin/ld: cannot find -lperl collect2: ld returned 1 exit status make[2]: *** [extension/plugin/libgimpgrad.la] Error 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2

5 7

Re: [cairo] Very slow performance (fwd)
by Bryce Harrington 23 Dec '04

23 Dec '04

Whoa, it amazes me what people are doing with Inkscape these days... ---------- Forwarded message ---------- Date: Thu, 23 Dec 2004 12:54:22 -0500 From: Chris <fltk@...78...> To: Carl Worth <cworth@...573...> Cc: cairo@...278... Subject: Re: [cairo] Very slow performance On Thu, 2004-12-23 at 12:34 -0500, Carl Worth wrote: > It is slow, and we'll need to fix that. > > But cairo does render the whole thing correctly, right? That's > encouraging. Actually, it doesn't render quite right. At least compared to Inkscape. Inkscape render: http://www.functionalfuture.com/radical/centi_unfinished.png Cairo render: http://www.functionalfuture.com/radical/centi_test.png It seems like it draws everything OK. At least for the stuff you can see. However, the layering/ordering is not correct and some things are hidden that shouldn't be. -- // Chris _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

io compile problem
by Bryce Harrington 23 Dec '04

23 Dec '04

<ddiaz> i'm getting: io/GzipStream.cpp:17:20: zutil.h: No such file or directory io/GzipStream.cpp: In member function `bool Inkscape::IO::GzipInputStream::load()': io/GzipStream.cpp:160: warning: unused variable 'srcCrc' io/GzipStream.cpp: In constructor `Inkscape::IO::GzipOutputStream::GzipOutputStream(Inkscape::IO::OutputStream&)': io/GzipStream.cpp:256: error: `OS_CODE' undeclared (first use this function) io/GzipStream.cpp:256: error: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [io/GzipStream.o] Error 1 make[1]: Leaving directory `/elresto/inkscape/inkscape.win32/src'

2 1

Fwd: Re: [Inkscape-devel] element namespaces
by bulia byak 23 Dec '04

23 Dec '04

On Thu, 23 Dec 2004 12:48:28 -0500, MenTaLguY <mental@...3...> wrote: > http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0412221011… It needs to be explained that this builds uses a version of boehm that may fix the Windows freeze bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1073459&group_id=9… So Windows folks who experienced this bug, please test this build and report your results here.

1 0

Build errors in CVS
by Trent Buck 23 Dec '04

23 Dec '04

I just tried to build Inkscape from CVS for the first time in a couple of weeks. I noticed the following Debian-specific problems: - AFAICT, python-dev and libperl-dev are now build dependencies; they should be added to the Build-Depends line in debian/control. - After building, dh_strip attempts to strip an ar archive, causing packaging to fail. From the build log: $ dpkg-buildpackage -rfakeroot [...] dh_installmime dh_link dh_strip strip: debian/inkscape/usr/lib/inkscape/plugins/stcstnTn/DynaLoader.a: Invalid operation dh_strip: command returned error code 256 make[2]: *** [binary-arch] Error 1 make[2]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' make[1]: *** [buildpackage] Error 2 make[1]: Leaving directory `/alt/foo/pkg/cvs/inkscape/WORKING/inkscape' -- -trent Look -- a diversion! It's shiny! -- Daniel Stone

4 4

filedialog change
by bulia byak 21 Dec '04

21 Dec '04

In file dialogs, I removed the name of the file above the preview: - it's a bit tautologic, as the file is already selected in the list anyway - removing it frees a bit more space for the preview itself - most importantly, long filenames stretch the preview and thus distort the dialog layout, and there's no way to ellipcize the filename label (at least yet, as of GTK 2.6) I like this change, but I realize there may be different opinions, so comments are welcome.

5 9

Re: [cairo] cairo backend for xpdf - first drop (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

More evaluation info about the PDF backend in Cairo ---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 16:40:10 -0500 From: Carl Worth <cworth@...43...> To: Alexander Larsson <alexl@...43...> Cc: cairo <cairo@...278...> Subject: Re: [cairo] cairo backend for xpdf - first drop On Mon, 20 Dec 2004 19:54:12 +0100, Alexander Larsson wrote: > I found an embarrasing bug in it. It kept reading the fonts over and > over again. With that fixed, and with all the performance fixes in Cairo > cvs xpdf-cairo now feels faster than the standard xpdf on my machine. > > I'm attaching the new patch. Alexander, This is fantastic work. I think I may have found a new favorite PDF viewer. The rendering of the glyphs is so much nicer compared to standard xpdf. Though I notice that the improved hinting allows some extra room in which the intra-word spacing could be improved. To my eye, intra-word problems, (such as two adjacent letters colliding) stand out more with the hinting of xdpf-cairo, whereas with xpdf-standard the words are just blurry everywhere. Do you generally still have word structure available in PDF files? Or is every glyph already placed individually? Meanwhile, line art appears to have better snapping with xpdf-standard, (or more likely that's just the lack of antialiasing). I've been meaning to propose a cairo_set_snapping API for some time and I think this application gives us perfect justification and some great test cases for that. Oh, and we still need to add sub-pixel rendering to cairo fonts, (geometry too!), to make things even more legible. Once we get all that done, I think it might even be pleasant to read many documents on a display instead of printing them out. I'm quite happy to see this area improve. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [cairo] New PDF backend snapshot (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 15:41:47 -0500 From: Carl Worth <cworth@...573...> To: Kristian HÃ¸gsberg <krh@...618...> Cc: cairo@...278... Subject: Re: [cairo] New PDF backend snapshot --[[text/plain]] Kristian, Thanks so much for all your hard work on the PDF backend! I'm sorry I've been so slow to review it. I think this is good work, and I want it to land in CVS soon. I have a few comments, (most importantly with respect to the public API). On Wed, 15 Dec 2004 12:52:38 -0500, Kristian HÃ¸gsberg wrote: > I've pondering the cairo_document_t idea a bit and restructured the PDF > backend so that it's split into a cairo_pdf_document_t object and a > cairo_pdf_surface_t object. I believe this makes the code easier to > follow, but I'm no longer sure we need to expose a cairo_document_t in > the user API. If it's easier to have two objects in the backend, that is fine. > public API. 2) It will be a nice way to set metadata and other PDF > specific information for the document. Can't we just do that with cairo_pdf_surface functions? What advantage does the user get from having two different objects? So far, it seems the user just has to do more work before being able to use the PDF backend, (compared to the others). > +void > +cairo_set_target_pdf (cairo_t *cr, > + cairo_pdf_document_t *document); The notion behind the cairo_set_target family of functions is to allow the user to select a backend without having to create any new object. So the cairo_set_target_pdf function should accept the same arguments as cairo_pdf_surface_create. So, I think I would like to see the new public cairo_pdf API match the existing cairo_ps API exactly: cairo_surface_t * cairo_ps_surface_create (FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); void cairo_set_target_pdf (cairo_t *cr, FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); > There are two significant changes outside cairo_pdf_surface.c in this > patch: I've added the set_clip_trapezoids surface method which is > supposed to let cairo pass the absolute clipping path to the backends. (Kristian and I discussed this off-list and he has now proposed a new patch without the set_clip_trapezoids method. See: http://people.redhat.com/krh/cairo-pdf/cairo-pdf-4.patch ) > The other change is the addition of cairo_array_t implemented in > cario_array.c. This is an standard autogrowing array, doubling the > allocation size when it runs out of space. I was using chained lists > before in the PDF backend, but I converted those to arrays. I added the > array as a general data type, since cairo uses the same type of array in > other places and it might make sense to rewrite those places to use this > array type. Eliminating some code duplication seems like a good thing. But I don't like giving up type safety, and worse, I don't want to give up direct access of arrays using C [] notation. This kind of thing is always a tough call since C has no support for what we really want here. Regardless, if the code is to stay, then: > + if (old_size == 0) > + new_size = 1; > + else > + new_size = old_size * 2; > + > + while (new_size < required_size) > + new_size = old_size * 2; should be: new_size = new_size * 2; to eliminate the infinite loop. And these three functions: > +static cairo_status_t > +_cairo_pdf_surface_set_matrix (void *abstract_surface, > + cairo_matrix_t *matrix) > + > +static cairo_status_t > +_cairo_pdf_surface_set_filter (void *abstract_surface, > + cairo_filter_t filter) > + > +static cairo_status_t > +_cairo_pdf_surface_set_repeat (void *abstract_surface, > + int repeat) merit at least a comment stating they are unsupported. This isn't *too* big a deal as I want to eliminate these functions from the surface interface anyway, (they really only belong on patterns). Once the issues above are resolved I'd like to get this into CVS. I haven't actually played with the PDF output yet, but we can have fun playing with that after it lands in the tree. Thanks again. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [Inkscape-user] Textbox
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Cliff wrote: > > On Thu, 16 Dec 2004 13:56:59 +0100, Imre Vida > > <Imre.Vida@...617...> wrote: > > > Do you plan to implement such a feature? > > > > Yes. In fact it already works, though there's no UI for it yet. See > > share/examples/flowsample.svg > > > > Theres no decent, complete UI, but to add the elements needed to put > text into shapes you can select them, right click and do 'add text to > shapes' to add the text itself you currently need to use the xml > editor. better than starting from scratch tho. What sort of UI does this need to have? Is this something that'll be easy to do, or will it need to be planned out? Bryce

2 1

Mozilla/Firefox SVG now has <image> tags
by Bob Jamison 21 Dec '04

21 Dec '04

This is so cool. The code for implementing the <image> tag in Mozilla SVG, which was previously a set of patches, apparently has made it into the mainline. Previously, the Mozilla guys were forced to use the <foreignObject> tag. Here is the SVG file w/images that I always use to test this stuff. Ignore the text alignment; obviously I need to convert it to curves. http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ff_ccp_dump.png Bob

1 0

problem compiling from CVS, python-related
by Ben Crowell 21 Dec '04

21 Dec '04

Can anyone suggest how to fix/work around this problem compiling the latest CVS version? It seems to be related to python extensions. TIA! ======================================================================================= [snip] Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-inkscape_perl_wrap.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Tpo" -c -o extension/script/extension_script_libscript_a-inkscape_perl_wrap.o `t est -f 'extension/script/inkscape_perl_wrap.cpp' || echo './'`extension/script/i nkscape_perl_wrap.cpp; \ then mv -f "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wr ap.Tpo" "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Po"; else rm -f "extension/script/.deps/extension_script_libscript_a-inkscape_pe rl_wrap.Tpo"; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-InkscapePython.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" -c -o extension/script/extension_script_libscript_a-InkscapePython.o `test -f 'exte nsion/script/InkscapePython.cpp' || echo './'`extension/script/InkscapePython.cp p; \ then mv -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.T po" "extension/script/.deps/extension_script_libscript_a-InkscapePython.Po"; els e rm -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" ; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig extension/script/InkscapePython.cpp:13:20: Python.h: No such file or directory extension/script/InkscapePython.cpp: In member function `virtual bool Inkscape::Extension::Script::InkscapePython::interpretScript(Glib::ustring&, Glib::ustring&, Glib::ustring&)': extension/script/InkscapePython.cpp:62: error: `Py_Initialize' undeclared (first use this function) extension/script/InkscapePython.cpp:62: error: (Each undeclared identifier is reported only once for each function it appears in.) extension/script/InkscapePython.cpp:67: error: `PyRun_SimpleString' undeclared (first use this function) make[2]: *** [extension/script/extension_script_libscript_a-InkscapePython.o] Er ror 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2 -

2 1

Re: File Chooser
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Taber wrote: > For some reason I can subscribe to get the Inkscape mail list but my posts get > rejected so am sending this direct.... Can you forward us one of the rejection emails? Maybe we can figure out what's going wrong. > Yes, Gtk filechooser is a total DISASTER as seen by anyone in our office. In > fact it will probably surface more with Firefox as 10 million converts start > trying to download files. It even took me several weeks before I realized > the listbox on left is a bookmark list and it seems like now I just have to > go thru more keystrokes. So you have our vote to modify it to allow > filenames to be typed in. This type of Gtk weirdness really hurts Gtk > adoption. > > btw We now depend on Inkscape for our graphics work and thank all of you for > the great job you are doing on it - it is simply one of the most energetic > and best managed open source projects. How can we convince Fedora folks to > include it ? When Firefox hopefully soon supports SVG, Inkscape will be a > must and hot ticket. > John Cool, good to hear. I don't know how Fedora decides what to include, but perhaps you can send an email to them requesting it? An email to encourage Firefox's SVG efforts would probably be worthwhile too. Bryce

1 0

Multiple page documents in SVG
by Bryce Harrington 20 Dec '04

20 Dec '04

This question came up a couple times this past week. SVG 1.2 (which we don't yet support) provides a method for doing multiple paged documents: http://www.w3.org/TR/SVG12/multipage.html Example: <svg xmlns="http://www.w3.org/2000/svg" version="1.2"> <pageSet>  <page> <circle cx="100" cy="100" r="20" fill="blue"/> </page>  <page> <rect x="100" y="100" width="20" height="20" fill="red"/> </page> </pageSet> </svg> Bryce

4 3

-users -developers test please ignore
by vellum 20 Dec '04

20 Dec '04

1 0

test ignore
by vellum 20 Dec '04

20 Dec '04

1 0

RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

[Please cc: me on replies] Hi, I'm resending this after not hearing any responses to my first email over a period of two weeks... :) I'm using Inkscape 0.40 packaged for Debian unstable. If its an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue/bug, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the "file" utility, to be regular postscript, rather than encapsulated postscript). I've tentatively tracked this down to be the lack of the full first-line of "%!PS-Adobe-3.0 EPSF-3.0" and instead only having "%!PS-Adobe-3.0". Ghostscript utilities, such as eps2eps, produce the full line, while inkscape produces the shorter version. Changing the latter to the former seemed to convince the Linux "file" utility that the file was now EPS. Any ideas on what's the right thing to do? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I"ve given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

3 2

Re: [Inkscape-devel] RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

Hi Bulia, Thanks for the reply... I'm guessing that you shouldn't need skencil to reproduce this bug and do a test EPS import, since I don't have it on my system and EPS imports work (I always assumed that you'd use ghostscript for EPS imports). Anyway, that bug looked familiar but the consensus was that something might be wrong due to an Adobe Illustrator issue. Mine however are EPS outputs produced only using Free Software tools (potrace from gimp-based input scan). If it really helps you, I could probably send you the inputs off-list, but I'd prefer to keep them private unless necessary. For the record, I can make it do this with any sample EPS file I gave it (comparing it to size in ghostview or through import into scribus). Thanks for the help. Let me know if there's anything else I can do. Any ideas about Postscript versus EPS recognition issue I mentioned also? Take care, Daniel > Whenever I place EPS files into a new Inkscape document, they appear > to be smaller (in pixel size or actual size, based upon bounding box) > than they should be. It seems to be this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1027699&group_id=9… If you attach there your comments and the sample EPS and SVG files from potrace it would be very helpful. The bug seems to be easy to fix (apparently the px and pt units are confused somewhere, we had several bugs of this kind) but I can't fix it now because I don't have Skencil installed (afaik we can only import EPS via Skencil).

2 1

Inkscape on LWN
by Bryce Harrington 20 Dec '04

20 Dec '04

Peter pointed out that LWN is featuring Inkscape on its Front page this week. http://lwn.net/ Bryce Vector graphics with Inkscape December 8, 2004 This article was contributed by Joe 'Zonker' Brockmeier. With the release of Inkscape 0.40, we decided to take a look at the latest release and get up to speed with the status of the project. Inkscape started as a fork of the Sodipodi project, but has evolved into a robust project in its own right. Inkscape is a drawing tool that uses the Scalable Vector Graphics (SVG) specification for its native format, and also exports to PNG, as well as saving in Adobe Illustrator format, PostScript, Encapsulated PostScript and PovRay formats. Inkscape will open or import graphics from Adobe Illustrator and Dia, other programs' SVG documents and a wide array of bitmap graphics formats. Inkscape runs on Linux, Windows and Mac OS X. We installed the Inkscape static RPM on a SUSE 9.2 system to see what the program is capable of, and whether Inkscape was stable and feature-complete enough for productive use. The Inkscape download page on SourceForge includes source packages, RPMs and Windows binaries. To test Inkscape we started off by creating basic basic shapes using Inkscape's rectangle and ellipse tools and fiddling with color fills, stroke styles, rotation and so forth just to get a feel for Inkscape's tools. It took about fifteen minutes for this writer to get comfortable with the Inkscape interface. With an application like Inkscape, using a mouse (or tablet) is almost unavoidable. However, Inkscape's shortcut keys allow the user to perform a lot of actions, such as selecting different tools or raising and lowering an object from one layer to another, from the keyboard -- rather than having to grab the mouse to switch between tools or adjust layers. For example, to toggle the current tool from Inkscape's path tool to the select tool, all that's necessary is to hit the space bar or F1. To move an object up one layer, simply hit "Page Up" or "Page Down" to move it lower. Speaking of layers, layer management is one of the major new features in Inkscape with the 0.40 release, according to the release notes. Another new feature in 0.40 is a "text-on-path" feature. This allows the user to conform text to a path -- which is useful for creating interesting logos and other artwork that requires text to wrap text to a shape other than a rectangle. The feature is certainly easy to use. All that's required is to select a path and the text object that is to conform to the path. Rectangles, ellipses and other objects must be converted to a path before the user can wrap text to fit that object. By manipulating that object, the user can change the flow of the text even if the text has been removed from the object or if the object is "invisible" because there is no fill color or stroke color associated with the object. The only thing we couldn't figure out was how to specify a starting point on a path for the text. We also enjoyed Inkscape's "Trace Bitmap" feature, which allows the user to trace an imported bitmap. By importing a photo or other bitmap, it's possible to create an scalable object that can then be turned into paths or otherwise edited in Inkscape. Inkscape has incorporated the potrace utility for this. The trace bitmap feature works best with line art, but can be used to produce some fun effects with photos or other artwork. Inkscape's performance and stability are excellent. We created a number of documents using Inkscape, exported our documents and some of the Inkscape tutorials to PNG, EPS and PS, and didn't see any glitches. The program never crashed while we were testing, and all of the features that are currently in Inkscape seem to work as advertised. We did noticed that some detail was lost when exporting to EPS from the tutorials, but this may not be an Inkscape limitation. Though Inkscape doesn't have a full user manual at this stage, it does include several useful tutorials for basic and advanced concepts when working with Inkscape, as well as an excellent man page. It also features an "Elements of Design" document, which may be useful for users who lack a background in art and design. The Inkscape interface also features context help for most tools as well as context-sensitive tips in the bottom status bar. For the most part, this writer found the interface to be straightforward and intuitive. The "Vacuum Defs" item under the File menu was a bit of a puzzler at first, though it was finally determined that it was for removing unused information from the defs tags in a document. We presume this is a good thing. Some of Inkscape's functions can be used without even needing to start the Inkscape GUI. For example, inkscape file.svg -e file.png will convert an SVG file to a PNG. This can be particularly useful for users who wish to convert a number of SVG files into PNG format. SVG experts can edit an SVG document directly, if they so choose, by using Inkscape's built-in XML editor. Very few users will be likely to need this tool, but it's there for those who need or want to edit a document's elements directly. Inkscape may not be at the same level of functionality as Adobe Illustrator or Corel Draw, but it's certainly capable of creating some excellent graphics -- even if this writer isn't quite up to the task of fully exploiting its potential. With other open source applications like The Gimp and Scribus, Linux is a serious contender for users who are looking for a desktop publishing platform.

10 38

Extensions stuff
by Ted Gould 19 Dec '04

19 Dec '04

Hey all, First, I'll apologize for my disappearing -- I've been crazy busy, but I hope that it will start to be getting better. I've not read through most of the Inkscape lists, and there seems to be some discussion on extensions, I'm going to try to hit everything I remember in one mega e-mail. -- It seems that there are problems loading the GIMP gradient plugin. Who is getting those? Is there a consistent set? Is this related to people who are/aren't compiling in the bin relocate code? I'm sure the extensions stuff isn't thread safe. This worries me, as I'd like to move alot more functionality into being plugins in the near future. -- There seemed to be a few "where are extensions going?" type of e-mails. I guess my 'grand goal' is to have them pretty much everywhere, but in the short term I'd like to get functionality similar to GIMP's filters working. This would involve having a menu item which would cause modifications to the document based on some plugable functionality. I hope this can be done with scripts and plugins, and made to 'just work' for every user of Inkscape. This goal may seem overly ambitious, but there is tons of the infrastructure already in place. Some solid documentation has been started on this by Bryce. Find it here: (it also explains the terminology that we've been using) http://cvs.sourceforge.net/viewcvs.py/inkscape/inkscape/doc/extension_syste… -- Extensions dialog -- I think that this is a really good idea. I'd like to be able to load and unload the extensions from a dialog -- for testing also. If someone could mock up the dialog and take care of all "the GUI stuff" I'd be happy to help with the tying it into the rest of the system part of it. Otherwise, this has lower priority for me to getting effects working happily. One thing that I'd like to see in this dialog is a place to put a textual "Why this extension didn't load" so we can explain missing dependencies to users somewhere. -- API for extensions, this is still in flux. But, it is something that needs to be figured out. I know at one point we'd discussed using the SVG DOM from the W3C. I don't know how that would work out, or how difficult it would be. Bryce and I outlined some general functions that would be needed for "Command and Control" in the document above, but those ideas are definitely not fleshed out. -- Now that we're XSLTized -- should we be adding that as an extension type? I could see it working for input/output extensions, perhaps as effects also? Okay, that is all I can remember right now... tell me more, I should be more responsive now! --Ted PS -- If anyone is looking for "bite-sized" extensions task to do over winter break or something similar, ask, I think that I have a few.

4 5

layer display
by bulia byak 18 Dec '04

18 Dec '04

When you enter a group, the layer selector in the statusbar shows only the ancestors of the group, while regular layers that are siblings of the parent layer disappear. Is there a reason for this? I would much prefer it to always show siblings of each ancestor layer. Without this, to go to the layer above, I have to use the widget twice: once to go up from the group and then again go to the layer above.

2 3

Re: [Inkscape-devel] Re: [Inkscape-user] RPM build errors
by Ted Gould 17 Dec '04

17 Dec '04

On Mon, 2004-12-06 at 16:07 +0000, Jonathan Leighton [Turnip] wrote: > #7 0x0828ab18 in Inkscape::Extension::Dependency::check () > #8 0x082890e8 in Inkscape::Extension::Extension::check () > #9 0x0828c50f in Inkscape::Extension::Input::check () > #10 0x0828b0f9 in Inkscape::Extension::Dependency::check () > #11 0x08289e69 in Inkscape::Extension::DB::foreach () > #12 0x0828b20e in Inkscape::Extension::init () > #13 0x080c53b2 in sp_main_gui () > #14 0x080c55ae in main () Hmm, I can't find anywhere that Inkscape::Extension::Dependency::check calls Inkscape::Extension::Extension::check() (and thus, Inkscape::Extension::Input::check()). Can someone look at src/extension/dependency.cpp just to make sure I'm not insane? Anyone have any other ideas? --Ted

7 14

[Fwd: [cairo] 10000% performance increase for clip surfaces]
by Bob Jamison 17 Dec '04

17 Dec '04

Hi, all. Saw this today on the Cairo list. I don't know if the patch is valid, but it seems to improve performance for me on Cairo, too. Open Source at work. BOb

1 0

script for embedding raster images
by Ben Crowell 17 Dec '04

17 Dec '04

The following patch to sp-image.cpp allows Inkscape to read Adobe Illustrator files that have the "data:;base64" syntax for embedded images. The embedded images are displayed correctly on the screen. However, if you save the file, the resulting svg output still has "data:;base64", which is obviously a Bad Thing. I started looking around in the code for where the output happens, but C++ isn't a language I'm very comfortable with, and I rapidly got lost. I'd be grateful for any insight from anyone who understands the code and the language better. I'd prefer not to commit the patch for the input without making the output standards-compliant. ===================== patch to sp-image.cpp ======================= 902a903,913 > // bcrowell, 2004 dec 13: > // Adobe Illustrator writes output like this: > // data:;base64, > // This is illegal according to the SVG standard, but there seems to be a consensus > // on inkscape-devel that Inkscape should allow input like this anyway. It would > // be nice to do a better syntax check here, but Lauris Kaplinski's old-school C parser > // is already pretty complicated; probably we should be using a C++ regular expression > // library instead. The following line allows input of lame Illustrator SVG: > data_is_image = 1; > // However, the output isn't any more correct than the input. >

5 5

Solaris and SunPro patch
by Robin KAY 16 Dec '04

16 Dec '04

I have made a giant patch against inkscape 0.38.1 which allows it compile under Solaris and with the SunPro compiler. No doubt it won't apply cleanly against the CVS head but I'll look in to that in a few days. Most of the changes are fairly straightforward. A lot of function prototypes had different type signatures to their implementations. Namespace declarations were terminated with semicolons when they shouldn't be. A few source files used GNU extensions. Some numerical constants had ambiguous types. The Solaris maths library doesn't have separate functions for single precision values and fpresetsticky is called fpsetsticky. I created a header file, floatmaths.h, which contains appropriate defines to remedy this. I also replaced <stdint.h> with <inttypes.h>. C99 library support starts with Solaris 10. The only changes of dubious merit I can think of were; changing round to rint as I'm not sure if this will affect the semantics of the code in questions, and importing an implementation of hash_map when you should really switch to GHashTable as the comments suggest. I couldn't see an obvious place to initialize the GHashTables. Note that the floating point optimization level (-fsimple=n) must be 1 or lower as aggressive optimization will break assertions in the code. I will probably create a Inkscape package for blastwave.org (CSW). BTW, on an unrelated note, are there any plans for animation support? -- Wishing you good fortune, --Robin Kay-- (komadori) diff -ur inkscape-0.38.1-orig/src/chunk.h inkscape-0.38.1/src/chunk.h --- inkscape-0.38.1-orig/src/chunk.h 2004-07-02 01:52:04.126170000 +0100 +++ inkscape-0.38.1/src/chunk.h 2004-07-01 04:19:00.151422000 +0100 @@ -0,0 +1,84 @@ +/*! \file deque + * \brief This header provides the definitions and decleration of the chunk class used in hash_map + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +//#include <alloc.h> +#include <iterator> + +// using pair +#include <utility> + +// using operator new +#include <memory> + +// Type legend: +// H: (small) key type, should support effective == +// K: key type +// T: content type + +typedef unsigned int uint; + +template <class H, class K, class T, uint chunk_size> +class chunk { + typedef std::pair<const K, T> pair_t; // <key, value> pair +public: + chunk(): next(0){ + d = reinterpret_cast<pair_t*>(dd); + } + void free_data(size_t end_pos=chunk_size) { + //destroy(d,d+end_pos); + for (size_t i=0; i<end_pos; i++) { + (&d[i])->~pair_t(); + } + }; + + + H h[chunk_size]; // hash values + chunk* next; // next chunk +/// chunk* prev; // previous chunk + // we're using a char[] to get some "raw" memory + char dd[chunk_size * sizeof(pair_t)]; // space for data pairs + pair_t* d; // iterator used to access data pairs + + // the find functions will return a 0-pointer if the element was not found + + // find to use when doing lookups and inserts + pair_t* find_p(H hh, const K& kk, uint last = chunk_size) { + for (uint i = 0; i < last; ++i) { +#ifdef N_USE_HASH + if (kk == (d[i]).first) {return &d[i];} +#else + if (hh == h[i] && kk == (d[i]).first) {return &d[i];} +#endif + } + return 0; + } + + // find to use when deleting elements, we will move the last + // element in the bucket to the place + // hpp is a place to return a pointer to the small hashvalue + + pair_t* find_d(H hh, const K& kk, H** hpp, + uint last = chunk_size) { + for (uint i = 0; i < last; ++i) { +#ifdef N_USE_HASH + if (kk == (d[i]).first) { +#else + if (hh == h[i] && kk == (d[i]).first) { +#endif + *hpp = &h[i]; + return &d[i]; + } + } + return 0; + } + // set a value + // this function is the only one used to set elements directly + void set(H hh, const pair_t& p, uint i) { + h[i] = hh; + // do inplace new + pair_t* pp = &d[i]; + new(pp) pair_t(p); + } +}; diff -ur inkscape-0.38.1-orig/src/desktop-snap.cpp inkscape-0.38.1/src/desktop-snap.cpp --- inkscape-0.38.1-orig/src/desktop-snap.cpp 2004-03-03 23:44:37.000000000 +0000 +++ inkscape-0.38.1/src/desktop-snap.cpp 2004-07-01 03:07:30.120952000 +0100 @@ -71,7 +71,7 @@ NR::Point const req0(req); /* Implement "move from req0 by some multiple of mv" as "dot product with something orthogonal to mv remains unchanged". */ - NR::Point const n2(rot90(mv)); + NR::Point const n2(NR::rot90(mv)); double const d2 = dot(n2, req); if(sp_intersector_line_intersection(n2, d2, n, d, req) == intersects) { return L2(req - req0); Only in inkscape-0.38.1/src: desktop-snap.o diff -ur inkscape-0.38.1-orig/src/desktop.cpp inkscape-0.38.1/src/desktop.cpp --- inkscape-0.38.1-orig/src/desktop.cpp 2004-04-06 06:39:41.000000000 +0100 +++ inkscape-0.38.1/src/desktop.cpp 2004-07-01 03:05:16.156205000 +0100 @@ -823,7 +823,7 @@ gtk_box_pack_start (GTK_BOX (sbar), dtw->sticky_zoom, FALSE, FALSE, 0); // zoom status spinbutton - dtw->zoom_status = gtk_spin_button_new_with_range (log(SP_DESKTOP_ZOOM_MIN)/log(2), log(SP_DESKTOP_ZOOM_MAX)/log(2), 0.1); + dtw->zoom_status = gtk_spin_button_new_with_range (log(SP_DESKTOP_ZOOM_MIN)/log(2.0), log(SP_DESKTOP_ZOOM_MAX)/log(2.0), 0.1); gtk_tooltips_set_tip (tt, dtw->zoom_status, _("Zoom"), NULL); gtk_widget_set_usize (dtw->zoom_status, STATUS_ZOOM_WIDTH, -1); gtk_entry_set_width_chars (GTK_ENTRY (dtw->zoom_status), 6); @@ -1744,20 +1744,20 @@ sp_desktop_widget_update_zoom (SPDesktopWidget *dtw) { g_signal_handlers_block_by_func (G_OBJECT (dtw->zoom_status), (gpointer)G_CALLBACK (sp_dtw_zoom_value_changed), dtw); - gtk_spin_button_set_value (GTK_SPIN_BUTTON (dtw->zoom_status), log(SP_DESKTOP_ZOOM(dtw->desktop)) / log(2)); + gtk_spin_button_set_value (GTK_SPIN_BUTTON (dtw->zoom_status), log(SP_DESKTOP_ZOOM(dtw->desktop)) / log(2.0)); g_signal_handlers_unblock_by_func (G_OBJECT (dtw->zoom_status), (gpointer)G_CALLBACK (sp_dtw_zoom_value_changed), dtw); } gdouble sp_dtw_zoom_value_to_display (gdouble value) { - return floor (pow (2, value) * 100.0 + 0.5); + return floor (pow (2.0, value) * 100.0 + 0.5); } gdouble sp_dtw_zoom_display_to_value (gdouble value) { - return log (value / 100.0) / log (2); + return log (value / 100.0) / log (2.0); } gint diff -ur inkscape-0.38.1-orig/src/dialogs/filedialog.cpp inkscape-0.38.1/src/dialogs/filedialog.cpp --- inkscape-0.38.1-orig/src/dialogs/filedialog.cpp 2004-04-07 07:14:56.000000000 +0100 +++ inkscape-0.38.1/src/dialogs/filedialog.cpp 2004-07-01 02:17:05.166324000 +0100 @@ -348,7 +348,7 @@ -}; //namespace Dialogs -}; //namespace UI -}; //namespace Inkscape +} //namespace Dialogs +} //namespace UI +} //namespace Inkscape diff -ur inkscape-0.38.1-orig/src/dialogs/filedialog.h inkscape-0.38.1/src/dialogs/filedialog.h --- inkscape-0.38.1-orig/src/dialogs/filedialog.h 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/dialogs/filedialog.h 2004-07-01 02:16:48.494087000 +0100 @@ -167,13 +167,9 @@ }; //FileSaveDialog -}; //namespace Dialogs -}; //namespace UI -}; //namespace Inkscape - - - - +} //namespace Dialogs +} //namespace UI +} //namespace Inkscape #endif /* __FILE_DIALOG_H__ */ diff -ur inkscape-0.38.1-orig/src/dir-util.cpp inkscape-0.38.1/src/dir-util.cpp --- inkscape-0.38.1-orig/src/dir-util.cpp 2004-01-26 00:29:37.000000000 +0000 +++ inkscape-0.38.1/src/dir-util.cpp 2004-07-01 19:10:45.924433000 +0100 @@ -6,10 +6,10 @@ #include "dir-util.h" #include <string.h> -const gchar * -sp_relative_path_from_path (const gchar * path, const gchar * base) +const char * +sp_relative_path_from_path (const char * path, const char * base) { - const gchar * p, * b, * r; + const char * p, * b, * r; if (path == NULL) return NULL; if (base == NULL) return path; @@ -31,10 +31,10 @@ return path; } -const gchar * -sp_extension_from_path (const gchar * path) +const char * +sp_extension_from_path (const char * path) { - const gchar * p; + const char * p; if (path == NULL) return NULL; diff -ur inkscape-0.38.1-orig/src/display/nr-arena-shape.cpp inkscape-0.38.1/src/display/nr-arena-shape.cpp --- inkscape-0.38.1-orig/src/display/nr-arena-shape.cpp 2004-04-07 07:14:56.000000000 +0100 +++ inkscape-0.38.1/src/display/nr-arena-shape.cpp 2004-07-01 02:44:01.685201000 +0100 @@ -13,7 +13,8 @@ */ -#include <math.h> +#include "../floatmaths.h" + #include <string.h> #include <glib.h> #include <libnr/nr-rect.h> diff -ur inkscape-0.38.1-orig/src/document.cpp inkscape-0.38.1/src/document.cpp --- inkscape-0.38.1-orig/src/document.cpp 2004-03-14 03:21:29.000000000 +0000 +++ inkscape-0.38.1/src/document.cpp 2004-07-01 19:23:15.250308000 +0100 @@ -839,7 +839,7 @@ } SPItem* -sp_document_item_at_point (SPDocument *document, unsigned int key, NR::Point p, gboolean into_groups) +sp_document_item_at_point (SPDocument *document, unsigned int key, NR::Point const p, gboolean into_groups) { g_return_val_if_fail (document != NULL, NULL); g_return_val_if_fail (SP_IS_DOCUMENT (document), NULL); diff -ur inkscape-0.38.1-orig/src/extension/db.cpp inkscape-0.38.1/src/extension/db.cpp --- inkscape-0.38.1-orig/src/extension/db.cpp 2004-04-04 04:58:41.000000000 +0100 +++ inkscape-0.38.1/src/extension/db.cpp 2004-07-01 02:58:43.204554000 +0100 @@ -247,4 +247,4 @@ return; } -}; }; /* namespace Extension, Inkscape */ +} } /* namespace Extension, Inkscape */ diff -ur inkscape-0.38.1-orig/src/extension/db.h inkscape-0.38.1/src/extension/db.h --- inkscape-0.38.1-orig/src/extension/db.h 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/extension/db.h 2004-07-01 02:16:29.950175000 +0100 @@ -68,7 +68,7 @@ extern DB db; -}; }; /* namespace Extension, Inkscape */ +} } /* namespace Extension, Inkscape */ #endif /* __MODULES_DB_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/extension.cpp inkscape-0.38.1/src/extension/extension.cpp --- inkscape-0.38.1-orig/src/extension/extension.cpp 2004-04-08 06:33:02.000000000 +0100 +++ inkscape-0.38.1/src/extension/extension.cpp 2004-07-01 02:57:42.971575000 +0100 @@ -928,6 +928,6 @@ } -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Extension */ +} /* namespace Inkscape */ diff -ur inkscape-0.38.1-orig/src/extension/extension.h inkscape-0.38.1/src/extension/extension.h --- inkscape-0.38.1-orig/src/extension/extension.h 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/extension.h 2004-07-01 02:12:37.479116000 +0100 @@ -129,6 +129,8 @@ variable. It should really take up a very small space. It's important to note that the name is stored as the key to the hash table. */ + class param_t; + friend class param_t; class param_t { public: gchar * name; /**< The name of this parameter */ @@ -263,8 +265,8 @@ const SPStyle *style); }; -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __INK_EXTENSION_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/implementation/implementation.cpp inkscape-0.38.1/src/extension/implementation/implementation.cpp --- inkscape-0.38.1-orig/src/extension/implementation/implementation.cpp 2004-03-17 06:52:34.000000000 +0000 +++ inkscape-0.38.1/src/extension/implementation/implementation.cpp 2004-07-01 02:46:20.282594000 +0100 @@ -129,9 +129,9 @@ return 0; } -}; /* namespace Implementation */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Implementation */ +} /* namespace Extension */ +} /* namespace Inkscape */ /* Local Variables: diff -ur inkscape-0.38.1-orig/src/extension/implementation/implementation.h inkscape-0.38.1/src/extension/implementation/implementation.h --- inkscape-0.38.1-orig/src/extension/implementation/implementation.h 2004-03-17 06:52:34.000000000 +0000 +++ inkscape-0.38.1/src/extension/implementation/implementation.h 2004-07-01 02:21:30.733764000 +0100 @@ -18,7 +18,7 @@ namespace Extension { namespace Implementation { class Implementation; -};};}; +} } } #include <extension/extension.h> @@ -94,9 +94,9 @@ const SPStyle *style); }; -}; /* namespace Implementation */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Implementation */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __INKSCAPE_EXTENSION_IMPLEMENTATION_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/implementation/script.cpp inkscape-0.38.1/src/extension/implementation/script.cpp --- inkscape-0.38.1-orig/src/extension/implementation/script.cpp 2004-04-08 06:31:58.000000000 +0100 +++ inkscape-0.38.1/src/extension/implementation/script.cpp 2004-07-01 02:52:19.418915000 +0100 @@ -54,7 +54,7 @@ officially in the load function. This allows for less allocation of memory in the unloaded state. */ -Script::Script (void) : Implementation::Implementation() +Script::Script() /*: Implementation::Implementation()*/ { command = NULL; return; @@ -569,9 +569,9 @@ return; } -}; /* Inkscape */ -}; /* module */ -}; /* Implementation */ +} /* Inkscape */ +} /* module */ +} /* Implementation */ /* Local Variables: diff -ur inkscape-0.38.1-orig/src/extension/implementation/script.h inkscape-0.38.1/src/extension/implementation/script.h --- inkscape-0.38.1-orig/src/extension/implementation/script.h 2004-04-02 17:23:15.000000000 +0100 +++ inkscape-0.38.1/src/extension/implementation/script.h 2004-07-01 02:48:59.139245000 +0100 @@ -55,9 +55,9 @@ }; -}; /* Inkscape */ -}; /* Extension */ -}; /* Implementation */ +} /* Inkscape */ +} /* Extension */ +} /* Implementation */ #endif /* __INKSCAPE_EXTENSION_IMPEMENTATION_SCRIPT_H__ */ /* diff -ur inkscape-0.38.1-orig/src/extension/internal/ps-out.cpp inkscape-0.38.1/src/extension/internal/ps-out.cpp --- inkscape-0.38.1-orig/src/extension/internal/ps-out.cpp 2004-04-02 16:24:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps-out.cpp 2004-07-01 02:56:56.473003000 +0100 @@ -63,4 +63,4 @@ return; } -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps-out.h inkscape-0.38.1/src/extension/internal/ps-out.h --- inkscape-0.38.1-orig/src/extension/internal/ps-out.h 2004-04-02 16:24:57.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps-out.h 2004-07-01 02:56:42.269315000 +0100 @@ -29,7 +29,7 @@ }; -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ #endif /* EXTENSION_INTERNAL_PS_OUT_H */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps.cpp inkscape-0.38.1/src/extension/internal/ps.cpp --- inkscape-0.38.1-orig/src/extension/internal/ps.cpp 2004-04-09 07:16:06.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/ps.cpp 2004-07-01 02:55:55.706445000 +0100 @@ -845,8 +845,8 @@ } -}; /* namespace Internal */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Internal */ +} /* namespace Extension */ +} /* namespace Inkscape */ /* End of GNU GPL code */ diff -ur inkscape-0.38.1-orig/src/extension/internal/ps.h inkscape-0.38.1/src/extension/internal/ps.h --- inkscape-0.38.1-orig/src/extension/internal/ps.h 2004-03-03 04:30:21.000000000 +0000 +++ inkscape-0.38.1/src/extension/internal/ps.h 2004-07-01 02:55:29.807654000 +0100 @@ -70,8 +70,8 @@ static void init (void); }; -}; /* namespace Internal */ -}; /* namespace Extension */ -}; /* namespace Inkscape */ +} /* namespace Internal */ +} /* namespace Extension */ +} /* namespace Inkscape */ #endif /* __EXTENSION_INTERNAL_PS_H__ */ diff -ur inkscape-0.38.1-orig/src/extension/internal/svg.cpp inkscape-0.38.1/src/extension/internal/svg.cpp --- inkscape-0.38.1-orig/src/extension/internal/svg.cpp 2004-04-06 06:39:43.000000000 +0100 +++ inkscape-0.38.1/src/extension/internal/svg.cpp 2004-07-01 02:54:13.362159000 +0100 @@ -172,4 +172,4 @@ return; } -};};}; /* namespace inkscape, module, implementation */ +} } } /* namespace inkscape, module, implementation */ diff -ur inkscape-0.38.1-orig/src/extension/internal/svg.h inkscape-0.38.1/src/extension/internal/svg.h --- inkscape-0.38.1-orig/src/extension/internal/svg.h 2004-03-03 04:30:21.000000000 +0000 +++ inkscape-0.38.1/src/extension/internal/svg.h 2004-07-01 02:53:52.417928000 +0100 @@ -33,7 +33,7 @@ }; -};};}; /* namespace Inkscape, Extension, Implementation */ +} } } /* namespace Inkscape, Extension, Implementation */ #endif /* __SVG_H__ */ /* diff -ur inkscape-0.38.1-orig/src/fast_bucket.h inkscape-0.38.1/src/fast_bucket.h --- inkscape-0.38.1-orig/src/fast_bucket.h 2004-07-02 01:52:59.717860000 +0100 +++ inkscape-0.38.1/src/fast_bucket.h 2004-07-01 04:18:05.727462000 +0100 @@ -0,0 +1,191 @@ +/*! \file fast_bucket.h + * \brief This header provides the definitions and decleration of the fast_bucket class used in hash_map + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +// using pair +#include <utility> + +// using operator new +#include <memory> + +#include "chunk.h" + +#define chunk_size 10 + +template <class H, class K, class T> +class fast_bucket { + fast_bucket(const fast_bucket<H, K, T>&); + const fast_bucket<H, K, T>& operator=(const fast_bucket<H, K, T>&); + typedef std::pair<const K, T> pair_t; + typedef chunk<H, K, T, chunk_size> chunk_; + typedef T value_t; + typedef K key_t; +private: +public: + // chunks + chunk_* first; // the first chunk in the single linked list + + // housekeeping for first chunk + // this is located in the fast_bucket class because it is the only + // place it is used and it comes with a price in space + uint end_pos; // is index to the "end iterator" (one past...) + + // find to use when deleting elements, we will move the last + // element in the bucket to the place + // hpp is a place to return a pointer to the small hashvalue + pair_t* find_d(H hh, const K& kk, H** hpp) { + // check the first chunk + pair_t* t; + if (t = first->find_d(hh, kk, hpp, end_pos)) {return t;} + + // check the rest + chunk_* c = first->next; + while (c) { + pair_t* pp; + if ((pp = c->find_d(hh, kk, hpp)) != 0) {return pp;} + c = c->next; + } + return 0; + } + + // move last element to a place according to args + // this is the delete operation, so we need to do it the nice way! + void move_last_element_to(pair_t* pp, H* hp) { + // is the first chunk empty? + if (end_pos == 0) { + // the chunk is empty -- get rid of it + chunk_* trash = first; + first = trash->next; + end_pos = chunk_size; + delete trash; + } + + const uint last_element_pos = --end_pos; + *hp = first->h[last_element_pos]; + //destroy(pp); + pp->~pair_t(); + + // do inplace new + new(pp) pair_t(first->d[last_element_pos]); + //destroy(&(first->d[last_element_pos])); + (&(first->d[last_element_pos]))->~pair_t(); + } + + + // inserting into the first chunk + pair_t* insert_last(H hh, const pair_t& p){ + uint last_element_pos; + // common case first to help pipeline + if (end_pos != chunk_size) { + last_element_pos = end_pos++; + first->set(hh, p, last_element_pos); + } + else { + // no place left, add a chunk + add_chunk(); + last_element_pos = end_pos++; + first->set(hh, p, last_element_pos); + } + return &(first->d[last_element_pos]); + } + + void add_chunk() { + chunk_* second = first; + first = new chunk_; + first->next = second; + end_pos = 0; + } + +public: + fast_bucket() { + first = new chunk_; + end_pos = 0; // end position + } + ~fast_bucket() { + // just destroy data and delete the chunks + chunk_* c = first->next; + while (c) { + chunk_* trash = c; + c = c->next; + trash->free_data(); + delete trash; + } + first->free_data(end_pos); + delete first; + } + + // return size of bucket in valid elements + uint size() { + uint chunks = 0; // n chunks excl. the last + chunk_* c = first->next; + while (c) { + c = c->next; + ++chunks; + } + // the elements in the first chunk is end_pos + return (chunks * chunk_size) + end_pos; + } + pair_t* find(H hh, const K& kk) { + // first chunk + pair_t* pp; + if (pp = first->find_p(hh, kk, end_pos)) {return pp;} + // the rest + chunk_* c = first->next; + while (c) { + pair_t* pp; + if ((pp = c->find_p(hh, kk)) != 0) {return pp;} + c = c->next; + } + return 0; + } + + // insert element in bucket + std::pair<pair_t*, bool> insert(H hh, const pair_t& p) { + // check if the key is here + if (pair_t* pp = find(hh, p.first)) { + // it is -- overwrite + pp->second = p.second; ///!!! is this ok?? + return std::pair<pair_t*, bool>(pp, false); + } + else { + // insert last + return std::pair<pair_t*, bool>(insert_last(hh, p), true); + } + } + + // find or insert element + value_t& find_or_insert(H hh, const key_t& k) { + // check if the key is here + if (pair_t* pp = find(hh, k)) { + return pp->second; + } + pair_t* pp = insert_last(hh, pair_t(k, value_t())); + return pp->second; + } + + + // delete element from bucket + void erase(H hh, const K& k) { + // check if the key is here + H* hp; + pair_t* pp; + if (pp = find_d(hh, k, &hp)) { + // it is -- overwrite with the last element + move_last_element_to(pp, hp); + } + } + + // end_value returns a value& to the last element. + value_t& end_value() { + uint last_element_pos = end_pos - 1; + return first->d[last_element_pos].second; + } + + // end_value returns a pointer to the last pair. + pair_t* end_pair() { + uint last_element_pos = end_pos - 1; + return &(first->d[last_element_pos]); + } +}; diff -ur inkscape-0.38.1-orig/src/floatmaths.h inkscape-0.38.1/src/floatmaths.h --- inkscape-0.38.1-orig/src/floatmaths.h 2004-07-02 01:53:43.021623000 +0100 +++ inkscape-0.38.1/src/floatmaths.h 2004-07-01 14:13:00.159211000 +0100 @@ -0,0 +1,15 @@ +#ifndef FLOATMATHS_H +#define FLOATMATHS_H + +#include <ieeefp.h> +#include <math.h> + +#if defined(__sun) && defined(__SVR4) +#define fabsf fabs +#define ceilf ceil +#define floorf floor +#define isfinite finite +#define fpresetsticky fpsetsticky +#endif + +#endif diff -ur inkscape-0.38.1-orig/src/hash_map.h inkscape-0.38.1/src/hash_map.h --- inkscape-0.38.1-orig/src/hash_map.h 2004-07-02 01:51:58.422066000 +0100 +++ inkscape-0.38.1/src/hash_map.h 2004-07-01 14:04:52.600609000 +0100 @@ -0,0 +1,119 @@ +/*! \file stl_hash_map.h + * \brief This header provides the definitions and declaration of the hash_map. + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + +#ifndef __STL_HASH_MAP_H__ +#define __STL_HASH_MAP_H__ + +#include <utility> +#include <vector> +#include "fast_bucket.h" +#include "stl_hash_functions.h" + +namespace cphstl { + +template <class key_t, class value_t, class Hash_t, class Equal> +class hash_map { + + typedef std::pair<const key_t,value_t> pair_t; + typedef std::pair<const key_t,value_t> value_type; + typedef const pair_t* const_iterator; + typedef unsigned long hashvalue_t; + typedef fast_bucket<hashvalue_t,key_t,value_t> fast_bucket_t; +public: + typedef pair_t* iterator; + +#ifndef JTABLE_SIZE +#define JTABLE_SIZE 8192 +#endif + + hash_map(size_t size = JTABLE_SIZE): + jump_table_size_(size), size_(0){ + memset(jump_table,0,sizeof(jump_table)); + } + ~hash_map() { + //destroy(jump_table, jump_table+jump_table_size()); + int len = jump_table_size (); + for (int i=0; i<len; i++) { + if (jump_table[i] != 0) + jump_table[i]->~fast_bucket_t(); + } + } + + iterator end() {return 0;} + + value_t& operator[](const key_t&); + + /* + NOT IMPLEMENTED: + pair_t* insert(const key_t&); + pair<iterator, bool> insert(const value_type& val); + void erase(iterator pos); + const_iterator find(const key_t& key); + */ + + iterator find(const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(jump_table[index]) { + fast_bucket_t* fb = jump_table[index]; + return fb->find(hv, key); + } + return end(); + } + + +// should return size_type?? bjarne 487!!! + void erase(const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(jump_table[index]) { + fast_bucket_t* fb = jump_table[index]; + fb->erase(hv, key); + } + } + + std::pair<iterator, bool> insert(const value_type& val) { + key_t key = val.first; + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(!jump_table[index]) { + fast_bucket_t* fb = new fast_bucket_t(); + jump_table[index] = fb; + fb->insert_last(hv, val); + return std::pair<iterator, bool>(fb->end_pair(), true); + } + fast_bucket_t* fb=jump_table[index]; + return fb->insert(hv, val); + } + + + size_t size() {return size_;} + size_t max_size() {return size_*1000;} +private: + size_t jump_table_size_; + size_t jump_table_size() { return jump_table_size_;} + size_t size_; + fast_bucket_t* jump_table[JTABLE_SIZE]; + Hash_t h; +}; + +template <class key_t, class value_t, class Hash_t, class Equal> +value_t& hash_map<key_t,value_t,Hash_t,Equal>::operator[](const key_t& key) { + hashvalue_t hv = h(key); + size_t index = hv % jump_table_size(); + if(!jump_table[index]) { + fast_bucket_t* fb = new fast_bucket_t(); + jump_table[index] = fb; + fb->insert_last(hv,pair_t(key,value_t())); + return fb->end_value(); + } + fast_bucket_t* fb=jump_table[index]; + return fb->find_or_insert(hv, key); +} + +} + +#endif diff -ur inkscape-0.38.1-orig/src/helper/bezier-utils.cpp inkscape-0.38.1/src/helper/bezier-utils.cpp --- inkscape-0.38.1-orig/src/helper/bezier-utils.cpp 2004-04-04 04:58:41.000000000 +0100 +++ inkscape-0.38.1/src/helper/bezier-utils.cpp 2004-07-01 02:21:01.847146000 +0100 @@ -24,9 +24,11 @@ #define SP_HUGE 1e5 #define noBEZIER_DEBUG -#include <math.h> #include <stdlib.h> + #include "bezier-utils.h" +#include "../floatmaths.h" + #include <libnr/nr-point-fns.h> #include <glib.h> diff -ur inkscape-0.38.1-orig/src/helper/canvas-bpath.cpp inkscape-0.38.1/src/helper/canvas-bpath.cpp --- inkscape-0.38.1-orig/src/helper/canvas-bpath.cpp 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/helper/canvas-bpath.cpp 2004-07-01 02:20:36.488376000 +0100 @@ -12,6 +12,8 @@ * */ +#include "../floatmaths.h" + #include <libart_lgpl/art_rect.h> #include <libart_lgpl/art_vpath.h> #include <libart_lgpl/art_bpath.h> diff -ur inkscape-0.38.1-orig/src/helper/sp-ctrlline.cpp inkscape-0.38.1/src/helper/sp-ctrlline.cpp --- inkscape-0.38.1-orig/src/helper/sp-ctrlline.cpp 2004-04-01 09:37:49.000000000 +0100 +++ inkscape-0.38.1/src/helper/sp-ctrlline.cpp 2004-07-01 02:20:23.830183000 +0100 @@ -17,7 +17,8 @@ * */ -#include <math.h> +#include "../floatmaths.h" + #include "sp-canvas.h" #include "sp-canvas-util.h" #include "sp-ctrlline.h" diff -ur inkscape-0.38.1-orig/src/inkview.cpp inkscape-0.38.1/src/inkview.cpp --- inkscape-0.38.1-orig/src/inkview.cpp 2004-04-01 09:37:47.000000000 +0100 +++ inkscape-0.38.1/src/inkview.cpp 2004-07-01 19:25:54.971029000 +0100 @@ -424,7 +424,7 @@ is_jar(const gchar *filename) { //fixme: mime check or something - char *extension; + const char *extension; if ((extension = strrchr(filename, '.')) != NULL) { if (strcmp(extension, ".jar") == 0 || strcmp(extension, ".sxw") == 0) return true; diff -ur inkscape-0.38.1-orig/src/libnr/nr-point.h inkscape-0.38.1/src/libnr/nr-point.h --- inkscape-0.38.1-orig/src/libnr/nr-point.h 2004-03-01 07:29:05.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-point.h 2004-06-30 23:19:29.483328000 +0100 @@ -7,6 +7,10 @@ #include <libnr/nr-coord.h> #include <libnr/nr-dim2.h> +#ifndef __GNUC__ +#define __attribute__(x) +#endif + struct NRPoint { NR::Coord x, y; }; diff -ur inkscape-0.38.1-orig/src/libnr/nr-rotate.h inkscape-0.38.1/src/libnr/nr-rotate.h --- inkscape-0.38.1-orig/src/libnr/nr-rotate.h 2004-02-26 09:23:57.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-rotate.h 2004-07-01 20:56:22.496040000 +0100 @@ -15,7 +15,7 @@ rotate(); public: - explicit rotate(Coord theta); + explicit rotate(Coord const theta); explicit rotate(Point const &p) : vec(p) {} bool operator==(rotate const &o) const { diff -ur inkscape-0.38.1-orig/src/libnr/nr-svp-uncross.cpp inkscape-0.38.1/src/libnr/nr-svp-uncross.cpp --- inkscape-0.38.1-orig/src/libnr/nr-svp-uncross.cpp 2004-02-09 02:26:08.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-svp-uncross.cpp 2004-06-30 23:25:41.579973000 +0100 @@ -191,7 +191,7 @@ } /* test continuation direction */ NR::Coord order = nr_svl_slice_compare (cs, ns); - if (fabs (order < 0.01)) { + if (order < 0.01) { /* Potentially close, test endpoint */ /* Bitch'o'bitches (Lauris) */ if (cs->vertex->next->y < ns->vertex->next->y) { diff -ur inkscape-0.38.1-orig/src/libnr/nr-svp.cpp inkscape-0.38.1/src/libnr/nr-svp.cpp --- inkscape-0.38.1-orig/src/libnr/nr-svp.cpp 2004-02-26 09:23:57.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-svp.cpp 2004-06-30 23:21:15.844477000 +0100 @@ -15,6 +15,7 @@ #include <assert.h> #include <stdio.h> +#include <ieeefp.h> #include <glib.h> #include "nr-values.h" diff -ur inkscape-0.38.1-orig/src/libnr/nr-types.cpp inkscape-0.38.1/src/libnr/nr-types.cpp --- inkscape-0.38.1-orig/src/libnr/nr-types.cpp 2004-02-20 08:49:50.000000000 +0000 +++ inkscape-0.38.1/src/libnr/nr-types.cpp 2004-06-30 23:16:52.979743000 +0100 @@ -16,7 +16,7 @@ double len = hypot(_pt[0], _pt[1]); g_return_if_fail(len != 0); g_return_if_fail(!isnan(len)); - static double const inf = 1e400; + static double const inf = pow(10.0, 400.0); if(len != inf) { *this /= len; } else { diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-font.cpp inkscape-0.38.1/src/libnrtype/nr-font.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-font.cpp 2004-02-23 01:49:12.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-font.cpp 2004-07-01 18:48:47.982943000 +0100 @@ -65,7 +65,7 @@ } NRRasterFont * -nr_rasterfont_new (NRFont *font, NR::Matrix transform) +nr_rasterfont_new (NRFont *font, NR::Matrix const transform) { return ((NRTypeFaceClass *) ((NRObject *) font->face)->klass)->rasterfont_new (font, transform); } diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-rasterfont.cpp inkscape-0.38.1/src/libnrtype/nr-rasterfont.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-rasterfont.cpp 2004-03-24 09:36:39.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-rasterfont.cpp 2004-07-01 18:43:09.925595000 +0100 @@ -13,6 +13,8 @@ #include <string.h> +#include "../floatmaths.h" + #include <libnr/nr-macros.h> #include <libnr/nr-point-l.h> #include <libnr/nr-rect.h> @@ -161,7 +163,7 @@ static NRRFGlyphSlot *nr_rasterfont_ensure_glyph_slot (NRRasterFont *rf, unsigned int glyph, unsigned int flags); NRRasterFont * -nr_rasterfont_generic_new (NRFont *font, NR::Matrix transform) +nr_rasterfont_generic_new (NRFont *font, NR::Matrix const transform) { NRRasterFont *rf; diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-type-directory.cpp inkscape-0.38.1/src/libnrtype/nr-type-directory.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-type-directory.cpp 2004-03-15 02:17:28.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-type-directory.cpp 2004-07-01 01:19:59.318131000 +0100 @@ -298,9 +298,7 @@ bool ink_strstr (const char *haystack, const char *pneedle) { -#ifndef WIN32 - return (strcasestr(haystack, pneedle) != NULL); -#else +#if defined(WIN32) || (defined(__sun) && defined(__SVR4)) // windows has no strcasestr implementation, so here is ours... // stolen from nmap char buf[512]; @@ -323,6 +321,8 @@ } else foundto = needle; } return false; +#else + return (strcasestr(haystack, pneedle) != NULL); #endif } diff -ur inkscape-0.38.1-orig/src/libnrtype/nr-type-xft.cpp inkscape-0.38.1/src/libnrtype/nr-type-xft.cpp --- inkscape-0.38.1-orig/src/libnrtype/nr-type-xft.cpp 2004-03-02 05:40:35.000000000 +0000 +++ inkscape-0.38.1/src/libnrtype/nr-type-xft.cpp 2004-07-01 01:29:06.315821000 +0100 @@ -12,6 +12,7 @@ #include <string.h> #include <stdio.h> +#include <X11/Xlib.h> #include <X11/Xft/Xft.h> #include <glib.h> diff -ur inkscape-0.38.1-orig/src/livarot/AVL.h inkscape-0.38.1/src/livarot/AVL.h --- inkscape-0.38.1-orig/src/livarot/AVL.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AVL.h 2004-06-30 23:27:39.658293000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/AlphaLigne.cpp inkscape-0.38.1/src/livarot/AlphaLigne.cpp --- inkscape-0.38.1-orig/src/livarot/AlphaLigne.cpp 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AlphaLigne.cpp 2004-07-01 02:19:14.112206000 +0100 @@ -9,8 +9,7 @@ #include "AlphaLigne.h" //#include "Buffer.h" - -#include <math.h> +#include "../floatmaths.h" AlphaLigne::AlphaLigne(int iMin,int iMax) { diff -ur inkscape-0.38.1-orig/src/livarot/AlphaLigne.h inkscape-0.38.1/src/livarot/AlphaLigne.h --- inkscape-0.38.1-orig/src/livarot/AlphaLigne.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/AlphaLigne.h 2004-07-01 00:40:00.969485000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/BitLigne.cpp inkscape-0.38.1/src/livarot/BitLigne.cpp --- inkscape-0.38.1-orig/src/livarot/BitLigne.cpp 2004-04-01 09:37:50.000000000 +0100 +++ inkscape-0.38.1/src/livarot/BitLigne.cpp 2004-07-01 02:19:28.910299000 +0100 @@ -8,8 +8,7 @@ */ #include "BitLigne.h" - -#include <math.h> +#include "../floatmaths.h" BitLigne::BitLigne(int ist,int ien,float iScale) { diff -ur inkscape-0.38.1-orig/src/livarot/BitLigne.h inkscape-0.38.1/src/livarot/BitLigne.h --- inkscape-0.38.1-orig/src/livarot/BitLigne.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/BitLigne.h 2004-07-01 00:37:30.705467000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> #include "LivarotDefs.h" Only in inkscape-0.38.1/src/livarot: BitLigne.o diff -ur inkscape-0.38.1-orig/src/livarot/DblLinked.h inkscape-0.38.1/src/livarot/DblLinked.h --- inkscape-0.38.1-orig/src/livarot/DblLinked.h 2004-02-29 02:13:59.000000000 +0000 +++ inkscape-0.38.1/src/livarot/DblLinked.h 2004-06-30 23:27:58.066138000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/Ligne.cpp inkscape-0.38.1/src/livarot/Ligne.cpp --- inkscape-0.38.1-orig/src/livarot/Ligne.cpp 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Ligne.cpp 2004-07-01 02:19:36.479344000 +0100 @@ -10,10 +10,7 @@ #include "Ligne.h" //#include "Buffer.h" #include "BitLigne.h" - -#include <math.h> - - +#include "../floatmaths.h" //int showCopy=0; //#define faster_flatten 1 diff -ur inkscape-0.38.1-orig/src/livarot/Ligne.h inkscape-0.38.1/src/livarot/Ligne.h --- inkscape-0.38.1-orig/src/livarot/Ligne.h 2004-02-29 02:14:00.000000000 +0000 +++ inkscape-0.38.1/src/livarot/Ligne.h 2004-07-01 00:36:52.770590000 +0100 @@ -12,7 +12,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> #include "LivarotDefs.h" diff -ur inkscape-0.38.1-orig/src/livarot/LivarotDefs.h inkscape-0.38.1/src/livarot/LivarotDefs.h --- inkscape-0.38.1-orig/src/livarot/LivarotDefs.h 2004-03-06 02:49:27.000000000 +0000 +++ inkscape-0.38.1/src/livarot/LivarotDefs.h 2004-06-30 23:28:15.682110000 +0100 @@ -8,7 +8,7 @@ #ifndef my_defs #define my_defs -#include <stdint.h> +#include <inttypes.h> // error codes (mostly obsolete) enum diff -ur inkscape-0.38.1-orig/src/livarot/MyMath.h inkscape-0.38.1/src/livarot/MyMath.h --- inkscape-0.38.1-orig/src/livarot/MyMath.h 2004-01-15 07:03:32.000000000 +0000 +++ inkscape-0.38.1/src/livarot/MyMath.h 2004-07-01 00:36:27.554185000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/livarot/Path.h inkscape-0.38.1/src/livarot/Path.h --- inkscape-0.38.1-orig/src/livarot/Path.h 2004-04-07 07:14:57.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Path.h 2004-06-30 23:47:04.328875000 +0100 @@ -389,7 +389,10 @@ } outline_callback_data; - typedef void (outlineCallback) (outline_callback_data * data, double tol, double width); + typedef void (outlineCallback) (outline_callback_data * data, double tol, double width); + + struct outline_callbacks; + friend struct outline_callbacks; typedef struct outline_callbacks { outlineCallback *cubicto; diff -ur inkscape-0.38.1-orig/src/livarot/PathConversion.cpp inkscape-0.38.1/src/livarot/PathConversion.cpp --- inkscape-0.38.1-orig/src/livarot/PathConversion.cpp 2004-03-10 12:16:57.000000000 +0000 +++ inkscape-0.38.1/src/livarot/PathConversion.cpp 2004-07-01 21:51:05.908913000 +0100 @@ -730,7 +730,7 @@ } } -const NR::Point Path::PrevPoint(int i) const +const NR::Point Path::PrevPoint(const int i) const { /* TODO: I suspect this should assert `(unsigned) i < descr_nb'. We can probably change the argument to unsigned. descr_nb should probably be changed to unsigned too. */ @@ -809,7 +809,7 @@ { NR::Point se = iE-iS; NR::Point ca(cos(angle),sin(angle)); - NR::Point cse(dot(se,ca),cross(se,ca)); + NR::Point cse(NR::dot(se,ca),cross(se,ca)); cse[0] /= rx; cse[1] /= ry; double const lensq = dot(cse,cse); diff -ur inkscape-0.38.1-orig/src/livarot/PathOutline.cpp inkscape-0.38.1/src/livarot/PathOutline.cpp --- inkscape-0.38.1-orig/src/livarot/PathOutline.cpp 2004-03-10 01:10:30.000000000 +0000 +++ inkscape-0.38.1/src/livarot/PathOutline.cpp 2004-07-01 02:19:45.761346000 +0100 @@ -8,9 +8,11 @@ #include "Path.h" //#include "MyMath.h" -#include <math.h> +#include "../floatmaths.h" #include <libnr/nr-point-fns.h> +#define MAX(a, b) ((a) > (b) ? (a) : (b)) + /* * the "outliner" * takes a sequence of path commands and produces a set of commands that approximates the offset @@ -955,7 +957,7 @@ double l = csex * csex + csey * csey; if (l >= 4) return; - const double d = sqrt(std::max(1 - l / 4, 0.0)); + const double d = sqrt(MAX(1 - l / 4, 0.0)); double csdx = csey, csdy = -csex; l = sqrt (l); csdx /= l; @@ -1234,7 +1236,7 @@ biss /= lb; const double angCo = dot (biss, enNor); const double l = width / angCo; - miter = std::max(miter, 0.5 * lb); + miter = MAX(miter, 0.5 * lb); if (l > miter) { const double angSi = cross (biss, stNor); const double r = (l - miter) * angCo / angSi; diff -ur inkscape-0.38.1-orig/src/livarot/Shape.h inkscape-0.38.1/src/livarot/Shape.h --- inkscape-0.38.1-orig/src/livarot/Shape.h 2004-04-01 09:37:50.000000000 +0100 +++ inkscape-0.38.1/src/livarot/Shape.h 2004-07-01 22:00:02.834524000 +0100 @@ -12,7 +12,7 @@ #include <math.h> #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> @@ -398,8 +398,8 @@ // the result is NOT a polygon; you need a subsequent call to ConvertToShape to get a real polygon int MakeOffset (Shape * of, double dec, JoinType join, double miter); - bool DistanceLE(NR::Point thePt, double const max_dist); - double Distance(NR::Point thePt); + bool DistanceLE(NR::Point const thePt, double const max_dist); + double Distance(NR::Point const thePt); int PtWinding (const NR::Point px) const ; // plus rapide int Winding (const NR::Point px) const ; diff -ur inkscape-0.38.1-orig/src/livarot/ShapeMisc.cpp inkscape-0.38.1/src/livarot/ShapeMisc.cpp --- inkscape-0.38.1-orig/src/livarot/ShapeMisc.cpp 2004-03-09 09:18:23.000000000 +0000 +++ inkscape-0.38.1/src/livarot/ShapeMisc.cpp 2004-07-01 02:19:55.246551000 +0100 @@ -7,10 +7,11 @@ */ #include "Shape.h" +#include "Path.h" +//#include "MyMath.h" +#include "../floatmaths.h" #include <libnr/nr-point.h> #include <libnr/nr-point-fns.h> -//#include "MyMath.h" -#include "Path.h" #include <glib.h> /* diff -ur inkscape-0.38.1-orig/src/livarot/ShapeUtils.h inkscape-0.38.1/src/livarot/ShapeUtils.h --- inkscape-0.38.1-orig/src/livarot/ShapeUtils.h 2004-02-29 02:14:05.000000000 +0000 +++ inkscape-0.38.1/src/livarot/ShapeUtils.h 2004-06-30 23:47:49.239888000 +0100 @@ -11,7 +11,7 @@ #include <stdio.h> #include <stdlib.h> -#include <stdint.h> +#include <inttypes.h> #include <string.h> //#include <iostream.h> diff -ur inkscape-0.38.1-orig/src/main.cpp inkscape-0.38.1/src/main.cpp --- inkscape-0.38.1-orig/src/main.cpp 2004-04-06 06:39:41.000000000 +0100 +++ inkscape-0.38.1/src/main.cpp 2004-07-01 14:13:24.744295000 +0100 @@ -27,6 +27,7 @@ #ifdef HAVE_FPSETMASK #include <ieeefp.h> +#include "floatmaths.h" #endif #include <string.h> #include <locale.h> diff -ur inkscape-0.38.1-orig/src/marker-status.h inkscape-0.38.1/src/marker-status.h --- inkscape-0.38.1-orig/src/marker-status.h 2004-02-26 09:49:05.000000000 +0000 +++ inkscape-0.38.1/src/marker-status.h 2004-07-01 03:12:56.175157000 +0100 @@ -1,6 +1,10 @@ #ifndef SEEN_MARKER_DEBUG_H #define SEEN_MARKER_DEBUG_H +#ifndef __GNUC__ +#define __attribute__(x) +#endif + void marker_status(char const *format, ...) __attribute__((format(__printf__, 1, 2))); #endif /* !SEEN_MARKER_DEBUG_H */ diff -ur inkscape-0.38.1-orig/src/nodepath.cpp inkscape-0.38.1/src/nodepath.cpp --- inkscape-0.38.1-orig/src/nodepath.cpp 2004-04-08 06:00:40.000000000 +0100 +++ inkscape-0.38.1/src/nodepath.cpp 2004-07-01 17:32:09.340350000 +0100 @@ -2361,7 +2361,7 @@ node_scale (n, grow / SP_DESKTOP_ZOOM (n->subpath->nodepath->desktop), which); } -void sp_nodepath_selected_nodes_scale(Path::Path *nodepath, gdouble const grow, int which) +void sp_nodepath_selected_nodes_scale(Path::Path *nodepath, gdouble grow, int which) { if (!nodepath) return; @@ -2375,7 +2375,7 @@ update_repr (nodepath); } -void sp_nodepath_selected_nodes_scale_screen (Path::Path *nodepath, gdouble const grow, int which) +void sp_nodepath_selected_nodes_scale_screen (Path::Path *nodepath, gdouble grow, int which) { if (!nodepath) return; diff -ur inkscape-0.38.1-orig/src/object-edit.cpp inkscape-0.38.1/src/object-edit.cpp --- inkscape-0.38.1-orig/src/object-edit.cpp 2004-03-08 00:19:04.000000000 +0000 +++ inkscape-0.38.1/src/object-edit.cpp 2004-07-01 03:16:42.079755000 +0100 @@ -320,7 +320,7 @@ && ( snaps != 0 ) ) { gdouble arg = 2.0*M_PI*spiral->revo*spiral->t0 + spiral->arg; - spiral->t0 = (round(arg/(M_PI/snaps))*(M_PI/snaps) - spiral->arg)/(2.0*M_PI*spiral->revo); + spiral->t0 = (rint(arg/(M_PI/snaps))*(M_PI/snaps) - spiral->arg)/(2.0*M_PI*spiral->revo); } spiral->t0 = CLAMP (spiral->t0, 0.0, 0.999); @@ -350,7 +350,7 @@ if ( ( state & GDK_CONTROL_MASK ) && snaps ) { - spiral->arg = round (spiral->arg/(M_PI/snaps))*(M_PI/snaps); + spiral->arg = rint (spiral->arg/(M_PI/snaps))*(M_PI/snaps); } sp_object_request_update ((SPObject *) spiral, SP_OBJECT_MODIFIED_FLAG); diff -ur inkscape-0.38.1-orig/src/remove-last.h inkscape-0.38.1/src/remove-last.h --- inkscape-0.38.1-orig/src/remove-last.h 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/remove-last.h 2004-07-01 03:34:45.916484000 +0100 @@ -9,7 +9,7 @@ { using std::vector; - typename vector<T>::reverse_iterator i(find(seq.rbegin(), seq.rend(), elem)); + typename vector<T>::reverse_iterator i(std::find(seq.rbegin(), seq.rend(), elem)); g_assert( i != seq.rend() ); typename vector<T>::iterator ii(&*i); seq.erase(ii); diff -ur inkscape-0.38.1-orig/src/sp-guide.cpp inkscape-0.38.1/src/sp-guide.cpp --- inkscape-0.38.1-orig/src/sp-guide.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/sp-guide.cpp 2004-07-01 16:50:39.372934000 +0100 @@ -264,7 +264,7 @@ * true indicates a "committing" version: in response to button release event after * dragging a guideline, or clicking OK in guide editing dialog. */ -void sp_guide_moveto(SPGuide const &guide, gdouble const position, bool const commit) +void sp_guide_moveto(SPGuide const &guide, double const position, bool const commit) { g_assert(SP_IS_GUIDE(&guide)); diff -ur inkscape-0.38.1-orig/src/sp-item-notify-moveto.cpp inkscape-0.38.1/src/sp-item-notify-moveto.cpp --- inkscape-0.38.1-orig/src/sp-item-notify-moveto.cpp 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-notify-moveto.cpp 2004-07-01 03:37:43.324260000 +0100 @@ -20,7 +20,7 @@ g_return_if_fail(SP_IS_ITEM(&item)); g_return_if_fail( unsigned(snappoint_ix) < 8 ); NR::Point const dir( mv_g.normal ); - double const dir_lensq(dot(dir, dir)); + double const dir_lensq(NR::dot(dir, dir)); g_return_if_fail( dir_lensq != 0 ); NR::Point snappoints[8]; diff -ur inkscape-0.38.1-orig/src/sp-item-notify-moveto.h inkscape-0.38.1/src/sp-item-notify-moveto.h --- inkscape-0.38.1-orig/src/sp-item-notify-moveto.h 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-notify-moveto.h 2004-07-01 16:50:18.068479000 +0100 @@ -4,7 +4,7 @@ #include <forward.h> void sp_item_notify_moveto(SPItem &item, SPGuide const &g, int const snappoint_ix, - double position, bool const commit); + double const position, bool const commit); #endif /* !__SP_ITEM_NOTIFY_MOVETO_H__ */ diff -ur inkscape-0.38.1-orig/src/sp-item-update-cns.cpp inkscape-0.38.1/src/sp-item-update-cns.cpp --- inkscape-0.38.1-orig/src/sp-item-update-cns.cpp 2004-02-26 09:23:56.000000000 +0000 +++ inkscape-0.38.1/src/sp-item-update-cns.cpp 2004-07-01 03:38:14.732900000 +0100 @@ -27,7 +27,7 @@ fi != fiEnd; ++fi) { SPGuideConstraint const &cn = *fi; - if ( find(item.constraints.begin(), + if ( std::find(item.constraints.begin(), item.constraints.end(), cn) == item.constraints.end() ) diff -ur inkscape-0.38.1-orig/src/sp-object.cpp inkscape-0.38.1/src/sp-object.cpp --- inkscape-0.38.1-orig/src/sp-object.cpp 2004-03-15 04:02:46.000000000 +0000 +++ inkscape-0.38.1/src/sp-object.cpp 2004-07-01 03:43:19.909472000 +0100 @@ -993,7 +993,7 @@ style = sp_repr_attr (object->repr, "style"); if (style) { - gchar *p; + const gchar *p; gint len; len = strlen (key); for (p = strstr (style, key); p; p = strstr (style, key)) { diff -ur inkscape-0.38.1-orig/src/sp-shape.cpp inkscape-0.38.1/src/sp-shape.cpp --- inkscape-0.38.1-orig/src/sp-shape.cpp 2004-04-08 06:00:43.000000000 +0100 +++ inkscape-0.38.1/src/sp-shape.cpp 2004-07-01 03:46:17.796590000 +0100 @@ -36,6 +36,7 @@ #include "sp-root.h" #include "sp-marker.h" #include "sp-shape.h" +#include "floatmaths.h" #define noSHAPE_VERBOSE diff -ur inkscape-0.38.1-orig/src/sp-spiral.cpp inkscape-0.38.1/src/sp-spiral.cpp --- inkscape-0.38.1-orig/src/sp-spiral.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/sp-spiral.cpp 2004-07-01 03:51:25.843598000 +0100 @@ -444,7 +444,7 @@ g_assert (t >= 0.0); /* Any callers passing -ve t will have a bug for non-integral values of exp. */ - double const rad = spiral->rad * pow(t, spiral->exp); + double const rad = spiral->rad * pow(t, (double)spiral->exp); double const arg = 2.0 * M_PI * spiral->revo * t + spiral->arg; return NR::Point(rad * cos (arg) + spiral->cx, @@ -522,7 +522,7 @@ g_return_if_fail (SP_IS_SPIRAL(spiral)); if (rad) - *rad = spiral->rad * pow(t, spiral->exp); + *rad = spiral->rad * pow(t, (double)spiral->exp); if (arg) *arg = 2.0 * M_PI * spiral->revo * t + spiral->arg; } diff -ur inkscape-0.38.1-orig/src/spiral-context.cpp inkscape-0.38.1/src/spiral-context.cpp --- inkscape-0.38.1-orig/src/spiral-context.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/spiral-context.cpp 2004-07-01 03:35:10.237506000 +0100 @@ -437,7 +437,7 @@ gdouble arg = NR::atan2 (delta) - 2.0*M_PI*spiral->revo; if (state & GDK_CONTROL_MASK) { - arg = round (arg/(M_PI/snaps))*(M_PI/snaps); + arg = rint (arg/(M_PI/snaps))*(M_PI/snaps); } /* Fixme: these parameters should be got from dialog box */ diff -ur inkscape-0.38.1-orig/src/splivarot.cpp inkscape-0.38.1/src/splivarot.cpp --- inkscape-0.38.1-orig/src/splivarot.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/splivarot.cpp 2004-07-01 03:41:48.518466000 +0100 @@ -186,8 +186,8 @@ // extract the livarot Paths from the source objects // also get the winding rule specified in the style int nbOriginaux = g_slist_length (il); - Path *originaux[nbOriginaux]; - FillRule origWind[nbOriginaux]; + Path **originaux = (Path **)alloca(nbOriginaux * sizeof(Path *)); + FillRule *origWind = (FillRule *)alloca(nbOriginaux * sizeof(FillRule)); int curOrig; { curOrig = 0; diff -ur inkscape-0.38.1-orig/src/star-context.cpp inkscape-0.38.1/src/star-context.cpp --- inkscape-0.38.1-orig/src/star-context.cpp 2004-04-01 09:37:48.000000000 +0100 +++ inkscape-0.38.1/src/star-context.cpp 2004-07-01 03:53:01.003400000 +0100 @@ -435,7 +435,7 @@ gdouble r1 = NR::L2 (d); gdouble arg1 = atan2 (d); if (state & GDK_CONTROL_MASK) { - arg1 = round (arg1/(M_PI/snaps))*(M_PI/snaps); + arg1 = rint (arg1/(M_PI/snaps))*(M_PI/snaps); } bool isflat = sc->isflatsided; sp_star_position_set (star, sc->magnitude, p0, r1, r1 * sc->proportion, arg1, arg1 + M_PI / sides, isflat); diff -ur inkscape-0.38.1-orig/src/stl_hash_functions.h inkscape-0.38.1/src/stl_hash_functions.h --- inkscape-0.38.1-orig/src/stl_hash_functions.h 2004-07-02 01:53:30.333724000 +0100 +++ inkscape-0.38.1/src/stl_hash_functions.h 2004-07-01 04:19:40.215269000 +0100 @@ -0,0 +1,123 @@ +/*! \file stl_hash_functions.h + * \brief This header provides the definitions and declaration of hash functions used in hash_map. + + * \author Christian Boesgaard <pink@...432...> and Jacob C. Poulsen <ja7@...432...>. + */ + + +#ifndef __STL_HASH_FUNCTIONS_H__ +#define __STL_HASH_FUNCTIONS_H__ + +#include <string> + +typedef unsigned int uint; +typedef unsigned char byte; + +class hash_jyrki { +public: + hash_jyrki(uint s = 0) { + srand(s); + for (int i = 0; i < 1024; ++i) { + T[i] = (uint)rand(); + } + } + uint operator() (char const* s) { + uint t = 0; + byte* p = (byte*)s; + uint i = 0; + for (; *p != 0; ++i) { + t ^= T[((0x3 & i) << 8) + *p++]; + } + t ^= T[i]; + return t; + } + +private: + uint T[1024]; +}; + +template <class t> +struct hash_stl { + long operator() (const t& s); +}; + +template<> +struct hash_stl<const char*> { + long operator() (const char * s) { + uint t = 0; + while (*s != 0) { + t = 5 * t + *s++; + } + return t; + } +}; + +template<> +struct hash_stl<std::string> { + long operator() (const std::string& ss) { + const char* s=ss.c_str(); + uint t = 0; + while (*s != 0) { + t = 5 * t + *s++; + } + return t; + }; +}; + + + +class hash_crypto { +#define mix(a, b, c) { \ +a -= b; a -= c; a ^= (c >>13); \ +b -= c; b -= a; b ^= (a <<8); \ +c -= a; c -= b; c ^= (b >>13); \ +a -= b; a -= c; a ^= (c >>12); \ +b -= c; b -= a; b ^= (a <<16); \ +c -= a; c -= b; c ^= (b >>5); \ +a -= b; a -= c; a ^= (c >>3); \ +b -= c; b -= a; b ^= (a <<10); \ +c -= a; c -= b; c ^= (b >>15); \ +} + +public: + uint operator() (char const* k); +}; + +uint hash_crypto::operator() (char const* k) { + uint length = 0; + while (*k++) {++length;} + uint len = length; + uint a = 0x9e3779b9; + uint b = 0x9e3779b9; + uint c = 0x8f256195; + + while (len >= 12) { + a += (k[0] + (uint(k[1])<<8) + (uint(k[2])<<16) + (uint(k[3])<<24)); + b += (k[4] + (uint(k[5])<<8) + (uint(k[6])<<16) + (uint(k[7])<<24)); + c += (k[8] + (uint(k[9])<<8) + (uint(k[10])<<16) + (uint(k[11])<<24)); + mix(a, b, c); + k += 12; len -= 12; + } + + c += length; + switch (len) { + case 11: c+=(uint(k[10])<<24); + case 10: c+=(uint(k[9])<<16); + case 9 : c+=(uint(k[8])<<8); + + case 8: b+=(uint(k[7])<<24); + case 7: b+=(uint(k[6])<<16); + case 6: b+=(uint(k[5])<<8); + case 5: b+=k[4]; + + case 4: a+=(uint(k[3])<<24); + case 3: a+=(uint(k[2])<<16); + case 2: a+=(uint(k[1])<<8); + + case 1: a+=k[0]; + } + mix(a, b, c); + return c; +} + +#endif diff -ur inkscape-0.38.1-orig/src/streams-jar.cpp inkscape-0.38.1/src/streams-jar.cpp --- inkscape-0.38.1-orig/src/streams-jar.cpp 2004-03-17 17:28:20.000000000 +0000 +++ inkscape-0.38.1/src/streams-jar.cpp 2004-07-01 03:55:56.402454000 +0100 @@ -30,7 +30,7 @@ #endif //guint32 crc = check_crc(data, flags); - gchar filename[filename_length+1]; + gchar *filename = (gchar *)alloca(filename_length+1); _urihandle->read(filename, filename_length); filename[filename_length] = '\0'; @@ -92,7 +92,7 @@ int ret; if ((ret = do_consume_and_inflate(nbytes)) == EOF && eflen > 0) { - guint8 efbuf[eflen]; + guint8 *efbuf = (guint8 *)alloca(eflen); _urihandle->read(efbuf, eflen); return 1; } @@ -102,7 +102,7 @@ int JarBuffer::consume_uncompressed(int nbytes) { - guint8 data[nbytes]; + guint8 *data = (guint8 *)alloca(nbytes); if (consume(data, nbytes) == EOF) return EOF; diff -ur inkscape-0.38.1-orig/src/streams-zlib.cpp inkscape-0.38.1/src/streams-zlib.cpp --- inkscape-0.38.1-orig/src/streams-zlib.cpp 2004-03-17 17:28:20.000000000 +0000 +++ inkscape-0.38.1/src/streams-zlib.cpp 2004-07-01 03:53:58.994511000 +0100 @@ -105,7 +105,7 @@ int ZlibBuffer::do_consume_and_inflate(int nbytes) { - guint8 buf[nbytes]; + guint8 *buf = (guint8 *)alloca(nbytes); if (consume(buf, nbytes) == EOF) return EOF; diff -ur inkscape-0.38.1-orig/src/svg/ftos.cpp inkscape-0.38.1/src/svg/ftos.cpp --- inkscape-0.38.1-orig/src/svg/ftos.cpp 2004-04-09 07:16:17.000000000 +0100 +++ inkscape-0.38.1/src/svg/ftos.cpp 2004-07-01 01:40:57.875356000 +0100 @@ -275,10 +275,12 @@ int decimal=0; #ifdef HAS_ECVT - char *p = ecvt(val, count, &decimal, &sign); + char *p = ecvt(val, count, &decimal, &sign); #else - char *p; - asprintf(&p, "%.0f", val); + char *p, tmp[256]; + snprintf(tmp, 256, "%.0f", val); + p = (char *)malloc(strlen(tmp) + 1); + strcpy(p, tmp); #endif #ifdef DEBUG diff -ur inkscape-0.38.1-orig/src/svg/round.cpp inkscape-0.38.1/src/svg/round.cpp --- inkscape-0.38.1-orig/src/svg/round.cpp 2004-04-08 04:36:35.000000000 +0100 +++ inkscape-0.38.1/src/svg/round.cpp 2004-07-01 01:33:20.035147000 +0100 @@ -42,6 +42,6 @@ double rround(double x, int k) { if (k==0) return rround(x); - else return rround(x*pow(10,k)) / pow(10,k); + else return rround(x*pow(10.0, k)) / pow(10.0, k); } diff -ur inkscape-0.38.1-orig/src/svg/svg-path.cpp inkscape-0.38.1/src/svg/svg-path.cpp --- inkscape-0.38.1-orig/src/svg/svg-path.cpp 2004-03-18 19:48:25.000000000 +0000 +++ inkscape-0.38.1/src/svg/svg-path.cpp 2004-07-01 01:32:39.876558000 +0100 @@ -520,7 +520,7 @@ { /* end of number */ - val *= sign * pow (10, exp_sign * exp); + val *= sign * pow (10.0, exp_sign * exp); if (ctx->rel) { /* Handle relative coordinates. This switch statement attempts diff -ur inkscape-0.38.1-orig/src/verbs.cpp inkscape-0.38.1/src/verbs.cpp --- inkscape-0.38.1-orig/src/verbs.cpp 2004-04-07 07:14:55.000000000 +0100 +++ inkscape-0.38.1/src/verbs.cpp 2004-07-01 20:02:43.504293000 +0100 @@ -70,19 +70,33 @@ /* FIXME !!! we should probably go ahead and use GHashTables, actually -- more portable */ +#include <functional> + #if defined(__GNUG__) && (__GNUG__ >= 3) # include <ext/hash_map> using __gnu_cxx::hash_map; #else -# include <hash_map.h> +# include "hash_map.h" +using cphstl::hash_map; #endif #if defined(__GNUG__) && (__GNUG__ >= 3) namespace __gnu_cxx { #endif +template <typename T> class my_hash; + +template <> +class my_hash<sp_verb_t> { + typedef sp_verb_t T; +public: + size_t operator()(const T& x) { + return (size_t)g_int_hash((gpointer)&x); + } +}; + template <> -class hash<SPView *> { +class my_hash<SPView *> { typedef SPView *T; public: size_t operator()(const T& x) const { @@ -94,9 +108,9 @@ }; /* namespace __gnu_cxx */ #endif -typedef hash_map<sp_verb_t, SPAction *> ActionTable; -typedef hash_map<SPView *, ActionTable *> VerbTable; -typedef hash_map<sp_verb_t, SPVerbActionFactory *> FactoryTable; +typedef hash_map<sp_verb_t, SPAction *, my_hash<sp_verb_t>, std::equal_to<sp_verb_t> > ActionTable; +typedef hash_map<SPView *, ActionTable *, my_hash<SPView *>, std::equal_to<SPView *> > VerbTable; +typedef hash_map<sp_verb_t, SPVerbActionFactory *, my_hash<sp_verb_t>, std::equal_to<sp_verb_t> > FactoryTable; static VerbTable verb_tables; static FactoryTable factories;

6 6

compile notes
by bulia byak 16 Dec '04

16 Dec '04

Some random notes on compilation: - To compile the latest CVS I had to install libpython-devel and libxslt-devel (on Mandrake 9.2) - The stripped executable size went from approx 3Mb to 4Mb (!) - The warnings I saw: *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against the *** static library /usr/lib/perl5/5.8.1/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a is not portable! *** Warning: Linking the shared library extension/plugin/libgimpgrad.la against the *** static library /usr/lib/python2.3/config/libpython2.3.a is not portable! and /usr/lib/python2.3/config/libpython2.3.a(posixmodule.o)(.text+0x43de): In function `posix_tmpnam': Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp' /usr/lib/python2.3/config/libpython2.3.a(posixmodule.o)(.text+0x4306): In function `posix_tempnam': Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp'

1 0

Re: gtkmm style clean-up, take 2
by Bryce Harrington 16 Dec '04

16 Dec '04

Cool. There was no patch attached, but go ahead and commit directly to the codebase. Your last patch looked fine and from what you describe this one sounds good too. Talk to you tomorrow! Bryce On Thu, 16 Dec 2004, Derek P. Moore wrote: > Hey, > > I did a second-over on the files in the gtkmm codebase, to double check my work > and fix all the switch statements. > > While going through the second time, I also found a few things I missed the > first time. > > The only changes I made where: > > *, &, and type modifiers in their proper place > > made the WIDGET header #defines like the DIALOG header defines > > cleaned-up spacing in places where it made sense > >

1 0

Re: Inkscape .40
by Jon Phillips 16 Dec '04

16 Dec '04

On Fri, 2004-12-10 at 02:56 -0800, Jiaxiang wrote: > Good day, Jon. > > You guys are doing great work on Inkscape. I keep > dipping my toes into it and I'm thinking of taking the > plunge, that is, doing all my SVG-based graphics in > Inkscape and putting all of my little Sodipodi > "evangelism" (video tutorials, word-of-mouth > advertising, donations) to work for Inkscape. We would like this very much. I think that your contributions to Inkscape would be much more widely seen than generating this type of content for sodipodi. > Just curious: What has been the typical opinion of > Inkscape's interface? > > Do most users like it or dislike it? Yes, most people love the new interface. There is only a hand full that don't. > Would you and the other Inkscape developers ever > release a version with a tool box similar to > Sodipodi's to see what the reaction might be? (I > remember reading that the Inkscape interface wasn't > permanent.) > > If the tools collected in one place, with both > collapsible segments and detachable segements (with > special features accessible through the main menus > along the top just like it is now), Inkscape would be > just a delight to use. Well, in the current state you can detach in a similar manner to SODI. We have talked about developing a detachable toolbar approach similar to the gimp in the future using GTKMM. Using this, what you seek might be within closer reach. Jon > > __________________________________ > Do you Yahoo!? > Send holiday email and support a worthy cause. Do good. > http://celebrity.mail.yahoo.com > -- Jon Phillips 1528 Alice St. Apt. #4 Oakland, CA, USA 94612-5004 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 1

src/extension/script Makefiles
by Bob Jamison 16 Dec '04

16 Dec '04

Hi, all. Finally got my work email fixed again. Ok.. I finally hooked up the Makefile_insert and makefile.in in src/extension/script to the rest of the automake tree. So Inkscape is now compiling and linking with Perl and Python. Please try updating and building, when it is convenient. We will likely need to tweak it to make sure that the build works on everyone's machine. Now we need to make a dialog to load and execute scripts in either Perl or Python. Would there maybe be a user who is interested in GUIs, who would like to draw a mockup of what such a dialog might look like? (that's a lot of subjunctives in one sentence ;-) Bob

5 8

Winlibre and Upping our point release numbers
by jon 15 Dec '04

15 Dec '04

Man, reading these comments is fun. Did you all see that we are being included in this interesting collection of apps for windows users? http://www.winlibre.com/en/Versions.php Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now) I am making the official push that our 1.0 of Inkscape is full 1.2 SVG compliance. By this, I mean we can accept and render a SVG 1.2 file. I think that developing the editing around this is important, but it is more important that we handle SVG 1.2. Maybe though someone can argue for Inkscape 1.0 being able to both render and edit an SVG 1.2 file. However, our system works currently, so why change it, right? I do think though that we need to get a supa-advanced version of Inkscape out the gate as Microsoft is going to drop their WVG (their SVG makeover) soon, and then we know what that means... I keep seeing in comments people saying how our app is very well developed for such an early release thus implying that the app is new. The public perceives an app through maturity on many levels. What do you all think?

12 30

inkscape static build
by herve couvelard 15 Dec '04

15 Dec '04

Hello. euh.. let's make it simple. We use inkscape since the beginning of the project (we were on sodipodi and moved with the fork - a svg compliance choice). we decided to upgrade to inkscape 0.40 yesterday on some machines FedoraCore1. we grab the static package. it claimed for a gtk2-2.4 (we grab a GTK2-2.4.0) (was for fedora core 2) and a atk 1.6 and pango 1.4.0 ok was it was a bad idea fedora core 2. we rpm -uvh everything without warning and inkscape started and workd fine. but when we restarted X wouldn' start : a X server already started on 0: and /var/log/messages says : __________ init : open (dev/pts/0) : no such file or directory modeprob : modeprobe can't locate module fb0 / fb1/ fb2 etc... _______________________ we google-ed a little and it appears to be a "kernel' stuf ? (taking fc2 rpm for a fc1 was really a bad choice ! !) So what we can do is 1) to go back to previous state (gtk2-2.2). but that means no inkscape 0.40 2) upgrade to FC2/3 (we do not have time to do it now) 3 ) ask for help here, there are so much competence, maybe a ln -s could solve the probleme. (linking dev/pts/O to something could work ?) thanks

6 11

[patch] compile errors in nodepath.cpp
by Derek P. Moore 15 Dec '04

15 Dec '04

Howdy, I grabbed Inkscape 0.40 last night. I've been enjoyin' Inkscape for a little bit now, tryin' to hack a few things into the code (selectable ruler metrics, etc.). I figured it was time to port what modifications I'd been working on to the 0.40 tree. I'm using GCC (g++/libstdc++) 3.4.3 and Fedora Rawhide (post Core 3). In nodepath.cpp, I was getting the following compile errors: nodepath.cpp: In function `void node_ctrl_grabbed(SPKnot*, guint, void*)': nodepath.cpp:2220: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) nodepath.cpp:2222: error: no matching function for call to Radial::Radial(Radial)' nodepath.h:38: note: candidates are: Radial::Radial(const NR::Point&) nodepath.h:34: note: Radial::Radial(Radial&) make[2]: *** [nodepath.o] Error 1 In examining the code, the problem was with a few anonymous objects when calculating the origin of the grabbed control. The offensive code is: // remember the origin of the control if (n->p.knot == knot) { n->p.origin = Radial(n->p.pos - n->pos); } else if (n->n.knot == knot) { n->n.origin = Radial(n->n.pos - n->pos); } else { g_assert_not_reached(); } n->p.origin is of type Radial; and n->p.pos, n->n.pos, and n->pos are of type NR::Point. The creation of the anonymous Radial object with the subtraction of Points as the constructor argument seems to be working... The problem seems to be with the assignment of the resulting anonymous Radial object to n->{p,n}.origin. Translating the current code to pseudo-constructor-syntax (which is more along the lines of what the compiler actually compiles) results in: Radial origin(Radial(Point pos1 - Point pos2)) But since the Radial class has Radial::Radial(NR::Point const &), the following should suffice: Radial origin(Point pos1 - Point pos2) ... thus dropping the superfluous anonymous Radial. There are two solutions: A) create a pass-by-value Radial constructor, so we can properly pass the anonymous Radial, or B) drop the superfluous anonymous Radial in favor of the assignment being translated into the Radial::Radial(NR::Point const &) constructor. Attached is a patch that drops the anonymous Radial object in favor of C++ assignment/constructor magic. Now Inkscape 0.40 compiles and functions without complaint on my system.

2 1

Shortcut key translation
by Lucas Vieites 14 Dec '04

14 Dec '04

Hi, I was contacted the other day by J. Ramón Palacios, who translated the basic tutorial to spanish (I'll sent it in as soon as I do a quick revision). He asked me a question I had no answer for: in the inkscape menus the names of theshortcut keys are not translated. On the attached screenshot you'll see the spanish 'Object' menu (red underlining is mine). The shortcut keys are named 'PgUp', 'PgDn', etc. when they should be named 'Repág', 'Avpág', etc. Are these strings supposed to be in the .po file? If not, where are they supposed to be translated? Thanks for your time, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 2

Re: [Inkscape-devel] Shortcut key translation
by Kees Cook 14 Dec '04

14 Dec '04

On Tue, Dec 14, 2004 at 04:49:04PM +0100, Lucas Vieites wrote: > > This seems to be common to all Gtk applications, but I can't believe > > it's intended. If I run other tools (like gnumeric), I get the same > > results. > > > That's strange, because I don't. Before posting the origianl message I > checked Gnumeric and Evolution, and both show the correct key names, > that's why I asked. > Any other comments, anyone? Hm. Then I wonder if it's the locale of the Gnome instance itself? I use the "C" locale for my system by default, so when I start X, everything is in English. If I force inkscape (or gnumeric, etc) into another locale ("LC_ALL=fr_FR inkscape"), I get the localized menu names, but not shortcuts. Weird. I wonder if inkscape is missing some kind of localization initialization call? I know there is the main one at the start. Don't know. I guess file a bug so we can track this. -- Kees Cook @outflux.net

2 1

API for extensions?
by Ben Crowell 14 Dec '04

14 Dec '04

Bulia tells me there will soon be an extensions menu. I'm interested in writing some extensions in Perl. My motivation is to scratch my own itch, but some of the stuff I write might be of interest to other users as well. So far I've just been writing Perl scripts to manipulate SVG files, and running them from the command line. Is there an API for extensions yet? The simplest thing would probably be to do it through a shell, and provide a way to hook the command-line options and arguments up to a dialog box in the GUI. There would need to be provisions for internationalization, and for error reporting (including errors resulting from not having the right Perl modules installed). However, since Inkscape runs on Windows, running it in a shell might not work. Is the Extensions menu envisioned as a Unix-only feature? It seems like it would be quite complicated to implement such a thing on a cross-platform basis. It's easy to write the scripts to be platform-independent, but, e.g., most Windows users aren't going to have Active State Perl installed, and even if you embedded a Perl interpreter in Inkscape, that would only work for Perl, and there would still be the issue of libraries. Even if you told Windows users they were required to install Perl and a certain set of libraries, it would also be complex to try to write the glue between Inkscape and Perl in a platform-independent way. And my experience from writing a cross-platform Perl app is that it's a lot of work in terms of testing and code maintenance, much more than writing a Unix-only app.

3 2

[pjc@...609...: Re: [Inkscape-devel] OpenCD]
by Kees Cook 14 Dec '04

14 Dec '04

----- Forwarded message from Pierre-Jean Coudert <pjc@...609...> ----- Hello, I am Pierre-Jean Coudert from the WinLibre project ( http://www.winlibre.com/en/ ). WinLibre is a free software distribution for Windows aimed at popularizing free/open source software. We are including Inkscape since the WinLibre 0.2 release. (actually Inkscape 0.39 ) I want first to thank you for your great and impressive work. We have actually a problem with the 0.40 version. When we install it over the 0.39, it's impossible to open a file with the menu or the icon command (Inkscape crashes). Any idea for correcting this ? We would like to include the 0.40 version in the next WinLibre release. TIA Best regards, Pierre-Jean Coudert, WinLibre. ----- End forwarded message ----- -- Kees Cook @outflux.net

1 0

script for embedding raster images
by Ben Crowell 13 Dec '04

13 Dec '04

>> and I'm going to need to write >> various scripts anyway for my own use (e.g., I'm going to need >> something to gamma-correct svg files). Is there an API for >> extensions? >Hmmm... >Sounds perhaps like you might need to do more than just base gamma-correction. >There are many issues on color in general that need to be addressed. What >exactly are your needs for gamma-correction, and have you skimmed any of the >wiki pages on color? Ah, thanks for pointing me to the wiki -- lots of cool information there! I have a set of textbooks that was originally done on a Mac in PageMaker and Illustrator, and which I'm now in the process of converting to LaTeX and Inkscape on Linux. I'm actually producing the printed books in black and white, so CMYK issues aren't important to me. But as I move the books from Mac to Linux, I've been switching to the appropriate PC gamma correction. This makes them look right to me on the screen, and to users on Windows. (I give the PDFs away for free on my web site, and also sell them in print. Having them look good to professors who might adopt them is important.) Up until now, I'd just been gamma-correcting the EPS output from Illustrator using a kludgy Perl script. Now that I'm actually getting set up to *edit* the files on Linux using Inkscape, I'm planning to write software to gamma-correct the svg source files themselves.

1 0

Re: [Inkscape-user] Re: script for embedding raster images
by bulia byak 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote: > Up spake Ben Crowell: > > I don't know if AI's output is standards-compliant in this situation > > or not. If omitting the type is legal according to the SVG standard, > > then maybe Inkscape should allow it on input. > > Inkscape should probably allow it regardless, since being compatible > with AI is nearly as important as being compatible with the spec. > We don't have the clout to force AI to fix its mistakes, yet :-) I have to agree with that, though upon reading the RFC it's clear that the missing mimetype is interpreted as text/plain by default. So I think Inkscape is correct in its ignoring such images because technically, they're not images but texts. I'm not sure how to "fix" this because we probably use some library call to retrieve images from URIs.

1 0

script for embedding raster images
by Ben Crowell 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 20:31:29 +1100, Trent Buck <fubarbaz@...405...> wrote: > Up spake Ben Crowell: > > I don't know if AI's output is standards-compliant in this situation > > or not. If omitting the type is legal according to the SVG standard, > > then maybe Inkscape should allow it on input. > > Inkscape should probably allow it regardless, since being compatible > with AI is nearly as important as being compatible with the spec. > We don't have the clout to force AI to fix its mistakes, yet :-) Yep. If Inkscape allows the user to read noncompliant AI SVG output, and change it into standards-compliant Inkscape SVG, then that's a win for standards. If Inkscape won't let the user do that, then the user has no way of switching to a standards-compliant format. It's not like the situation with browsers, where bug-for-bug compatibility arguably just encourages web sites to use nonstandard HTML. Visiting a broken site with my standards-compliant browser doesn't fix the broken site :-) >I have to agree with that, though upon reading the RFC it's clear that >the missing mimetype is interpreted as text/plain by default. So I >think Inkscape is correct in its ignoring such images because >technically, they're not images but texts. I'm not sure how to "fix" >this because we probably use some library call to retrieve images from >URIs. Should just be a question of reading the first four bytes of the file to find out the magic number, and then closing it and calling the appropriate library for that type of file. Does anyone know where in the source code I should look? This is something I'm motivated to try to fix, since I have 660 AI SVG files I'm trying to get working with Inkscape, and many of them have this problem.

1 0

Re: [Inkscape-user] Re: script for embedding raster images
by bulia byak 13 Dec '04

13 Dec '04

> I've fixed the script to write it the way Inkscape wants it: > http://www.lightandmatter.com/embed_raster_in_svg Excellent, thanks! I tested it and it works when I run it on a file in the current dir, but when I tried to give it a file in a subdir tt/, I got this error: $ ./embed_raster_in_svg.pl tt/a.svg embedded raster file New_document_1-path1061-4294967076.png, image/png error renaming file tt/a.svg to tt/a.svg.bak, No such file or directory at ./embed_raster_in_svg.pl line 114. > I don't know if AI's output is standards-compliant in this situation > or not. Consult http://www.faqs.org/rfcs/rfc2397.html to find out who is compliant and who's not > >P.S. If you plan to keep contributing to Inkscape I can give you > >developer access > That would be nice, thanks! Given my weak C++ skills and lack of > familiarity with Inkscape's codebase, I probably wouldn't dare > to committ changes to the C++ code on my own, except maybe after > getting comments on them. But if the plan is to have an Extensions > menu that can call various Perl scripts, then it might be nice for > me to be able to contribute directly to that. My Perl skills are > a lot better than my C++ skills, and I'm going to need to write > various scripts anyway for my own use (e.g., I'm going to need > something to gamma-correct svg files). Good, I added bcrowell to the project > Is there an API for > extensions? I know we're moving towards it, Ted Gould will probably be able to give you more specific info. If you can help him to work on the extensions system for the next version, this would be fantastic. Also we have the ill2svg perl script that is used for importing illustrator files. I believe there were some issues with it that needed fixing (look up the bug tracker and list archives). In any case, since you're working with AI files and know Perl, you seem to be the ideal person to systematically test this script and write at least some documentation for it (what AI versions and what features are supported and what not, how to best prepare your files for import, etc). It might also make sense to incorporate the embed/outbed images functionality into it as an option.

1 0

Problems with EPS export and printing of markers
by Per Bjornsson 13 Dec '04

13 Dec '04

Hi, I'm seeing some problems with markers in Inkscape 0.40 and current CVS: They simply don't print or get exported in exported EPS files. (They are also all black instead of the line color, but that's known to be an unimplemented feature: http://sourceforge.net/tracker/index.php?func=detail&aid=995815&group_id=93… .) I couldn't find anything about them not getting printed or exported though so I figured that I'd check if it's just my build. Also, when building Inkscape with gnome-print support ('./configure --with-gnome-print') I don't get any print dialog at all, the print job is just dumped immediately on the default printer. Is this supposed to happen or should I actually be getting the regular gnome- print dialog? I noticed that the statically linked RPMs on the SF download site are built without gnome-print support, is that because gnome-print support is actually broken? My platform is Fedora Core 3, with GNOME 2.8 (for libgnomeprint), GTK 2.4 and my compiler is GCC 3.4. If this is specific to my setup I'll be ahppy to try to dig into what's going on; if it's universal maybe I can try to hack a solution, although although C++ might not be my most fuelnt language so I can't make any promises as to how far I'll get... Cheers, Per

1 0

compile problem, ar: libnr/have_mmx.o: No such file or directory
by Ben Crowell 12 Dec '04

12 Dec '04

I'm trying to compile the latest CVS version on my Debian box, and am getting the error message shown at the end of this mail. I have previously compiled 0.40 on this machine successfully. Can anyone suggest how to fix this problem? This is on Debian-testing, pretty standard setup except that I had to install automake 1.9 from source, since Debian only has 1.4 in unstable. TIA! ============== tail end of compiler output ============== gcc -g -O2 -c libnr/have_mmx.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.S rm -f libnr/libnr.a ar cru libnr/libnr.a libnr/nr-blit.o libnr/nr-compose-transform.o libnr/nr-compose.o libnr/nr-gradient.o libnr/nr-matrix-div.o libnr/nr-matrix-fns.o libnr/nr-matrix-rotate-ops.o libnr/nr-matrix-scale-ops.o libnr/nr-matrix-translate-ops.o libnr/nr-matrix.o libnr/nr-object.o libnr/nr-path.o libnr/nr-pixblock-line.o libnr/nr-pixblock-pattern.o libnr/nr-pixblock-pixel.o libnr/nr-pixblock.o libnr/nr-point-fns.o libnr/nr-rect-l.o libnr/nr-rect.o libnr/nr-rotate-fns.o libnr/nr-rotate-matrix-ops.o libnr/nr-scale-matrix-ops.o libnr/nr-scale-translate-ops.o libnr/nr-svp-render.o libnr/nr-svp.o libnr/nr-translate-matrix-ops.o libnr/nr-translate-scale-ops.o libnr/nr-translate-rotate-ops.o libnr/nr-types.o libnr/nr-values.o libnr/have_mmx.o libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.o libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.o ar: libnr/have_mmx.o: No such file or directory make[2]: *** [libnr/libnr.a] Error 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2

2 1

Mention in this months Linux Format
by John Cliff 12 Dec '04

12 Dec '04

Hi guys, First up, sorry about the empty mail, stupid ie on my parents computer :) Just thought I'd let you all know that we're mentioned very briefly in the news section of the xmas edition of linux format, just a they've released a new version with improved text features etc blurb, with the GO! screenshot above it. Didnt buy the mag as i dont use linux and didnt want to spend $10 on a magazine for 1 paragraph. Cheers John __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

2 1

Mention in this months Linux Format
by John Cliff 11 Dec '04

11 Dec '04

Hi guys, __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Mention in this months Linux Format
by John Cliff 11 Dec '04

11 Dec '04

Hi guys, __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Article to introduce Inkscape 0.40
by Bryce Harrington 11 Dec '04

11 Dec '04

I've started sketching out a PR piece about Inkscape 0.40, with the intent of writing up something lengthy that both discusses the new capabilities of the project and encourages people to chip in help at improving things. http://inkscape.org/cgi-bin/wiki.pl?ArticleIntroducingInkscape0_40 I've identified a few areas that definitely need more fleshing out; help on those areas would be quite valuable. Also, example images are needed to show off the capabilities; I'm sure I could rough something together but am betting that folks who actually have artistic talent could do a much better job than I. :-) So help would be much appreciated there as well. I haven't thought about where to publish it; Footsteps perhaps. This is also a rough "off the cuff" writing, so needs some editing and wordsmithing, as it's probably too wordy at this point. I haven't even spell checked it, so there's probably seplling and that grammer problem too. Bryce

4 6

OpenCD
by Kees Cook 11 Dec '04

11 Dec '04

These folks are creating a Windows-only OSS CD: http://theopencd.sunsite.dk/ They've had some discussions about possibly including Inkscape, and I'm worried about some of their impressions. I'm not sure how to address their concerns. "Too much flux" and "Development has slowed" wtf!? I wish they had contacted us, we could have made the v2.0 cut... http://theopencd.sunsite.dk/forum/viewtopic.php?t=540&highlight=inkscape http://theopencd.sunsite.dk/forum/viewtopic.php?t=717&highlight=inkscape -- Kees Cook @outflux.net

2 1

Static build portability warning
by Mike Hearn 11 Dec '04

11 Dec '04

Good day gentlemen, Statically linking libgc is a good idea, because not many people have this library and it's small enough that doing so isn't a big deal. Unfortunately due to the general brokenness of glibc, this will fail on some systems with the following error: inkscape: relocation error: inkscape: symbol __libc_stack_end, version GLIBC_2.1 not defined in file ld-linux.so.2 with link time reference This is because at some point, __libc_stack_end was changed from being public to private. It seems there's been some to-and-fro on this issue: on a Debian unstable system I have access (glibc 2.3.2) to __libc_stack_end is exported but marked as private, eg you can still build against it and it'll work but may break at any moment. On my inkscape nightly build system (glibc 2.3.4) and on my Fedora Core 3 system it's public (@@GLIBC_2.1). It appears that this symbol was originally public, made private then it was discovered that it was required for some of the non-exec stack work and made public again. The net result is that anything attempting to use this symbol is going to be screwed by the symbol versioning mechanism. Boehm GC attempts to weak link against this symbol, but due to the dubious design of weak linkage on GNU systems it fails because glibc does not export this symbol as weak. I will apply a patch to the autopackage copy of libgc soon to make it always fall back to parsing /proc, ask for an explanation of this mess from the glibc developers (I will probably be ignored) and post the patch to upstream libgc to use dlsym to retrieve this symbol, which should bypass symbol versioning. If anybody sees this message then, now you know what it means (kinda). thanks -mike

3 4

Re: [Inkscape-user] Grid and adjustment
by Felix Rabe 10 Dec '04

10 Dec '04

Hi, Batista, Facundo wrote: > Now, with "#" the only thing that goes on and off is the grid, but not > the "adjustment" (it adjusts to nothing, because the grid is not drew, > but it still adjusts). This is very annoying to me, because to be able > to work freely and back, and need to go the config, change the settings, > and then again to go back. I also strongly dislike this behavior of the recent Inkscape versions. (I can only apologize not to have mentioned it before here or in Bugzilla - I hoped it would resolve "automagically" sooner or later... very old very bad user attitude of mine (; ) My "workaround" is to keep a "Document Preferences (Shift+Ctrl+D)" window open most of the time - but just when I need it to switch the grid and the snapping (that's probably meant by "adjustment") on and off "together", it's not there... :o/ Maybe the solution might be to make a couple of checkboxes to define '#' / '|' key behavior, for example: -------------------------------------------- | Pressing the <#> key toggles: | [ ] Grid visibility // equiv. to "Show grid" | [ ] Snapping bounding boxes to grid // equiv. to "Snap bboxes 2 grid" | [ ] Snapping points to grid // equiv. to "Snap points 2 grid" -------------------------------------------- They are actually equivalent to those already in the Doc.Pref. window. OR, it could be solved like this: -------------------------------------------- | [ ] Show grid [ ] Toggled by pressing <#>? | [ ] Snap bounding boxes to grid [ ] Toggled by pressing <#>? | [ ] Snap points to grid [ ] Toggled by pressing <#>? -------------------------------------------- Hope to have provided some useful ideas, Felix PS: Thanks bulia for the fast bug fixing :)

1 0

[Bug 73619] Inkscape crashes with GLib problem when trying to print (fwd)
by Bryce Harrington 10 Dec '04

10 Dec '04

---------- Forwarded message ---------- Date: Fri, 10 Dec 2004 01:53:44 +0000 From: bugzilla-daemon@...599... To: bryce@...260... Subject: [Bug 73619] Inkscape crashes with GLib problem when trying to print http://bugs.gentoo.org/show_bug.cgi?id=73619 ------- Additional Comments From xanderhsia@...210... 2004-12-09 17:53 PST ------- OK. I following the instructions on running gdb and got a backtrace. Note that I do not have USE="debug" flag turned on. If this report doesn't have the right info , I can recompile and rerun gdb. Bear with me, this is first time I have run gdb, so I'm not really sure what I am looking for. ender@...600... ~/home $ gdb inkscape GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /usr/bin/inkscape (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread -1220237632 (LWP 31494)] (inkscape:31494): GLib-CRITICAL **: file gthreadpool.c: line 284 (g_thread_pool_new): assertion `g_thread_supported ()' failed GLib-ERROR **: The thread system is not yet initialized. aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1220237632 (LWP 31494)] 0xffffe410 in ?? () ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

2 1

Inkscape-Deps (Problem in Gentoo)
by Carsten Niehaus 09 Dec '04

09 Dec '04

Hi As some of you might know Inkscape is outdated in Gentoo. Version 0.37 is marked as stable, 0.38, 0.39 and 0.40 are marked unstable (~ARCH) [1]. The reasons are that Inkscape is "known" to crash an startup for some people (see e.g. [2]). I am using 0.39 since it it released with the ebuild Gentoo provides as "unstable" and had _no_ problems at all. For Inkscape 0.40 there is the problems of new deps, esp. libboehm and gtmmm. See [3] for it. Furthermore there have been a lot reports about GLIB-crashes I never could reproduce. See [4] for a glib-crash in 0.40. I hope that some of you could add comments to these 4 bugreports to help the gentoo-ebuild-writer. Gentoo is probably the only distro without a uptodate Inkscape and that is a shame. If you don't want to do it yourself write me a mail and I will add the comments. Thanks in advance, Carsten [1] http://packages.gentoo.org/search/?sstring=inkscape [2] http://bugs.gentoo.org/show_bug.cgi?id=73743 [3] http://bugs.gentoo.org/show_bug.cgi?id=71017 [4] http://bugs.gentoo.org/show_bug.cgi?id=73619 -- The rule on staying alive as a forecaster is to give 'em a number or give 'em a date, but never give 'em both at once. -- Jane Bryant Quinn

5 8

Inkscape 0.40 - error importing AI files
by unknown＠example.com 09 Dec '04

09 Dec '04

When I am importing .AI files this error message appears: ** (inkscape:9542): CRITICAL **: file document.cpp: line 511 (void sp_document_set_uri(SPDocument*, const gchar*)): assertion `document != NULL' failed Pleas help, how can I solve it? I have thousand .AI files which I could open in 0.39. Is downgrade only one solution? (OS: Gentoo unstable, same expirience with self compiled inkscape 0.40cvs and 0.40 stable in Slackware current) Thanks Martin Grohman

2 1

libXSLT dependency
by Bob Jamison 08 Dec '04

08 Dec '04

I have been asking around if anyone would mind adding libxslt as a dependency for this cycle. So far, I have had no complaints. This would allow not only us but also the average user to write input and output filters. Bryce mentioned that the requirement should not be bleeding edge. So I found this pkg-config file, libxslt.pc, on RH7.3, which seems good enough, so requiring libxslt >=1.0 should be sufficient. Could someone add this dep to configure.ac, if it is OK with everyone? ========= SNIP ============== prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libxslt Version: 1.0.15 Description: XSLT library version 2. Requires: Libs: -L${libdir} -lxslt -L/usr/lib -lxml2 -lz -lm -lm Cflags: -I${includedir}

3 5

Firefox 1.0 Linux on Gentoo has SVG plugin installed by default!!!!!!!!
by Jon Phillips 08 Dec '04

08 Dec '04

Hello all, I just opened an svg file by accident in Firefox 1.0 just to find that it displayed properly in my browser!!! Upon closer inspection I thought that I had setup svg to display in inkview, but no, I looked in the MozillaFirefox plugin folder and found these: -rw-r--r-- 1 root root 5632 Nov 18 04:20 libmozsvgdec.a -rwxr-xr-x 1 root root 1368 Nov 18 04:20 libmozsvgdec.la -rwxr-xr-x 1 root root 8536 Nov 18 04:20 libmozsvgdec.so Thus, could you all check to see if the Mozilla SVG is provided with your Firefox 1.0 install? I am ecstatic with joy if this is installed by default on all Firefox 1.0 browsers, because that means we now have penetration into the world with SVG. I have just ruled out that I built my Gentoo install of Firefox with SVG, as it is not an option. Thus, the gentoo ebuild builds the SVG plugin by default. Hmmm...if you all could report if you have the SVG plugin on your install, it would be great to know to promote via our website. In the end, we have to consider that our app's usefulness will scale dramatically if SVG is adopted by more user's. As of now we are using more as a meta-format not much unlike Illustrator using AI as a default format for creating illustrations. With viewing of SVG files on the web, so much more will be possible. Jon -- Jon Phillips (NEW) 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)

4 8

RE: [Inkscape-devel] SVG Linking
by NAGY Endre 08 Dec '04

08 Dec '04

Jon Thanks for responding and apologies for the delay in getting back My initial enquiry concerning linking related to a requirement to be able to edit attributes in the users namespace. See Feature Request No 1070754 and the mail in Inkscape-Devel on the subject "what do you _really_ want". I assumed that "SVG linking" might be able to help because Ch 17 of the SVG spec mentioned that I could use an URI specified by an Xlink to access a program. In retrospect I think I was grasping at a rather short straw. I can only guess at how I thought I was going to open an application in a browser to edit attribute values and then get those values back into the SVG content. As Peter Moulder points out in in his responses to my feature request, what I really need is a user friendly version of the XML editor that I can constrain to a specific set of attributes. My best hope here appears to be to make use of the plugin architecture. Peter suggested that I speak to Ted about this. I need this feature in Inkscape proper rather than a viewer because its all part of my editing process. If you think I'm still confused please feel free to respond Regards Endre -----Original Message----- From: Jon Phillips [mailto:jon@...235...] Sent: Wednesday, 1 December 2004 5:32 AM To: bulia byak Cc: NAGY Endre; inkscape Subject: Re: [Inkscape-devel] SVG Linking On Mon, 2004-11-22 at 19:25 -0500, bulia byak wrote: > > When invoking the example in InternetExplorer, the affect of clicking on the > > ellipse is to bring up W3's web page. > > I have not found a way of achieving this in inkscape. > > What, Inkscape did not show you the web page?! :) > > Seriously, it would be nice to run a browser by clicking a link. In > theory. In practice, Inkscape is not so much of a "user agent" as it > is an SVG creating application. In particular, following link on click > will badly get in the way of editing. Clicking something in Inkscape > has lots of editing functions. So, while we can create links, I think > we can be excused for not following them. > > This of course applies to inkscape proper. For inkview, following > links by calling a browser is a must. I think we already have an RFE > on that; search in the tracker and add your comments. Yes, I have been working on this behind the scenes. There are a few RFE's about linking. We (inkscape developers) have discussed having a preview mode like in Macromedia Flash whereby any animations/scripting/linking can be tested. Yes, Inkview should be a runtime/player of SVG content. And, yes, linking should work the way you are describing. My understanding of the spec though would allow you to in Inkview click on a link and if it is local and an SVG, then it is opened in Inkview. If it is a URL, to the SVG file, then that is viewed as well. If the file is not SVG, then it would be dealt with as described in the spec. Ideally, html would be opened in one's default browser, and other media would be shuttled to where it needs to go. I'm trying to get this feature into the next release. I think inkview is a good app in its own right as a simple viewer. I'm trying to decide if I should make these features into an inkbrowse app that is similar to inkview, but for browsing the web and local svg files. What this looks like needs to be debated. Initially I would like a UI like a web browser but for SVG content only. Do you all agree with me that this should be a separate application or should it be rolled into inkview? I could make it so that Inkview accepts URLs and could have a browsing interface and a simple menu system that can be hidden. It would be good to allow Inkscape to open SVG files that are qualified URLs (and I remember that Inkscape used to be able to do this), and then enable this functionality in inkview to add web-based svg files to a presentation, and eventually, this will allow for SVG-based animations in inkview as a presentation. Thoughts? > > ------------------------------------------------------- > 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://productguide.itmanagersjournal.com/ > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > -- Jon Phillips (NEW) 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) IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

1 0

visible, printable and wxSVG
by Edouard TISSERANT 08 Dec '04

08 Dec '04

WxSVG (wxsvg.sf.net) is a young GPL project that as still never released files, since it as not reach beta stage. First commit should occur in January 2005. WxSVG let you "draw" GUI with Inkscape. Have a look to screenshots at http://sourceforge.net/project/screenshots.php?group_id=124832 It consist of a thin layer of python classes that derive from wxPython controls classes. It use SVG elements to layout controls such as buttons or panels and map them with some pieces of bitmap cut-out from one or two (on & off) bitmaps exported from Inkscape. SVG elements that are used to layout controls are <rect> and <g>. We were used to use the non-printable feature of Inkscape to let us draw layout rect's over the visible GUI design, and the export the GUI image without control rect's. We have upgraded to yesterday's CVS snapshot. No more non-printable feature... And invisible elements are exported in bitmaps. So we cannot work anymore in the same way... The only way I found is to set global transparency for the "Control" group to 0.0 when exporting bitmap, ant to 1.0 when working on. Non-printable object was a very nice feature. WxSVG is really need it. Is there any other solution ? Except guide-lines is there anything that Inkscape can show but not export ? Edouard.

4 6

[Fwd: Re: Cross-compiling GlibMM statically to Win32 with MinGW]
by Bob Jamison 08 Dec '04

08 Dec '04

See how cool it can be when Open Source projects help each other? ^^ Bob

1 0

E nderuara Kompani!
by unknown＠example.com 08 Dec '04

08 Dec '04

E nderuara Kompani! ITS Germany e cila operon prej vitesh ne fushen e telekomunikacionit dhe internetit, tashme deshiron te zgjeroje aktivitetin e saj edhe ne teritorin e Kosoves . Stafi yne i perbere nga inxhiniere, teknike, designer, analiste tregu, etj. Kane pergatitur www.kosova-informacion.de Ne kete portal mund te nxirren njoftime per shitblerje, qeradhenie e qeramarrje te pasurive te patundshme, automjeteve, pajisjeve, apo te sherbimeve te ndryshme si telekomunikacioni, hoteleri-turizmi, apo udhetimet, etj. Cdo njoftim mund te shoqerohet me 1-6 fotografi te objektit. Cmimi per njoftim varion ne varesi te kategorise se objektit, kohezgjatjes online te njoftimit dhe numrit te fotografive (cmim i cili do te vendoset bashke me ju). ITS Germany eshte duke kerkuar Perfaqesuesin / Distributorin e saj per Kosove i cili do te marre Eskluzivitetin e plote te www.kosova-informacion.de per te gjithe territorin e Kosoves. Marrja e Eskluzivitetit nenkupton fillimin dhe zhvillimin e gjithe aktivitetit komercial te ketij portali vetem nga nje Perfaqesues / Distributor pra vetem nga ju. Nderkohe ITS Germany merr persiper mirembajtjen dhe suportin teknik te portalit, si dhe mbeshtetjen e saj nepermjet konsulences se nevojshme ne cdo moment. Per cdo informacion apo interes tuajin, ju lutem te na kontaktoni nepermjet postes sone elektronike , ne ju mirepresim. Na lejoni tju urojme mireseardhjen ne kompanine tone, kompania me e madhe e telekomunikacionit dhe internetit ne Gjermani! Me respekt, A. Berzani Directorin Development office@...595...

1 0

E nderuara Kompani!
by unknown＠example.com 08 Dec '04

08 Dec '04

E nderuara Kompani! ITS Germany e cila operon prej vitesh ne fushen e telekomunikacionit dhe internetit, tashme deshiron te zgjeroje aktivitetin e saj edhe ne teritorin e Kosoves . Stafi yne i perbere nga inxhiniere, teknike, designer, analiste tregu, etj. Kane pergatitur www.kosova-informacion.de Ne kete portal mund te nxirren njoftime per shitblerje, qeradhenie e qeramarrje te pasurive te patundshme, automjeteve, pajisjeve, apo te sherbimeve te ndryshme si telekomunikacioni, hoteleri-turizmi, apo udhetimet, etj. Cdo njoftim mund te shoqerohet me 1-6 fotografi te objektit. Cmimi per njoftim varion ne varesi te kategorise se objektit, kohezgjatjes online te njoftimit dhe numrit te fotografive (cmim i cili do te vendoset bashke me ju). ITS Germany eshte duke kerkuar Perfaqesuesin / Distributorin e saj per Kosove i cili do te marre Eskluzivitetin e plote te www.kosova-informacion.de per te gjithe territorin e Kosoves. Marrja e Eskluzivitetit nenkupton fillimin dhe zhvillimin e gjithe aktivitetit komercial te ketij portali vetem nga nje Perfaqesues / Distributor pra vetem nga ju. Nderkohe ITS Germany merr persiper mirembajtjen dhe suportin teknik te portalit, si dhe mbeshtetjen e saj nepermjet konsulences se nevojshme ne cdo moment. Per cdo informacion apo interes tuajin, ju lutem te na kontaktoni nepermjet postes sone elektronike , ne ju mirepresim. Na lejoni tju urojme mireseardhjen ne kompanine tone, kompania me e madhe e telekomunikacionit dhe internetit ne Gjermani! Me respekt, A. Berzani Directorin Development office@...595...

1 0

Updating gtk.zip for this release
by Bob Jamison 08 Dec '04

08 Dec '04

Now that we are at the beginning of a cycle again, it is time again to start updating the gtk24.zip file with new stuff. I made a first try at a new bundle here: http://troi.hous.es3.titan.com/~rjamison/inkscape , ...at the bottom of the page. It is very large, but only because we will need to discover from development and usage what is needed from the Perl and Python libraries. It will of course get smaller with time. And I changed the name, since it is not just Gtk stuff anymore. Bob

1 0

Inkscape 0.40 - error importing AI files
by Martin Grohman 08 Dec '04

08 Dec '04

When I am importing .AI files this error message appears: ** (inkscape:9542): CRITICAL **: file document.cpp: line 511 (void sp_document_set_uri(SPDocument*, const gchar*)): assertion `document != NULL' failed Pleas help, how can I solve it? I have thousand .AI files which I could open in 0.39. Is downgrade only one solution? (OS: Gentoo unstable, same expirience with self compiled inkscape 0.40cvs and 0.40 stable in Slackware current) Thanks Martin Grohman

1 0

Suggestion: Dim-able layers.
by Jakob Ilves 08 Dec '04

08 Dec '04

Hello! I had a very brief test of inkscape 0.40 and of course had a shot at using the layers feature and I liked it, especially that one could easily temporarely hide layers. One feature I would really appreciate is an additional option for a layer, in addition to locking and hiding: dimming (or whatever to call it). That is, one can set a layer to have a opacity lower than 1 to make it semi-transparent by using some convenient GUI widget. I know, one can do that today by entering the XML-editor (we all love it, don't we?) and once there, select the group the layer consists of and add "opacity: 0.5" (or whatever) to the group's style property. So it's already available but you know, a GUI isn't bad either. Thanks for a great tool! It is getting better and better! Best regards /IlvJa PS. I know, "Dim-able layers" might sound a bit corny but I could not make up any other term. (not a native English speaker, living in Sweden).

2 1

NEW: Tile clones
by bulia byak 08 Dec '04

08 Dec '04

Before getting deep into the boring stuff planned for 0.41, I decided to do some eye candy... http://inkscape.org/screenshots/gallery/inkscape-0.41-CVS-linux-tiles1.png http://inkscape.org/screenshots/gallery/inkscape-0.41-CVS-linux-tiles2.png * The new powerful "Tile clones" dialog implements all 17 plane symmetry groups, allowing you to easily create all sorts of symmetric patterns, Escher-like tesselations, ornaments, etc. Since the pattern is made out of clones, you can freely edit the original tile and the entire pattern is updated live. This feature puts Inkscape into competition with software such as the free Arabeske or commercial SymmetryWorks. ** Apart from selecting the symmetry (and uniquely to Inkscape), you can also set the shift, scale, rotation, and opacity of the clones in the pattern, per row and/or per column. Any of these parameters can also be randomized to any degree. This produces "object fields" that can be arbitrarily distorted, skewed, slanted, "faded out," or "magnetized" like iron particles in a magnetic field. ** To create a clone pattern, simply select something, set the number of rows and columns, and click Create. You can then change some parameters in the dialog and click Create again; this will remove any existing tiled clones of the selected object and recreate the pattern anew. Or, you can just remove the old pattern by clicking Remove. To protect a pattern from deletion by this dialog, group it or move it to another layer. ** Initially, a pattern is created based on the bounding box of the selected object. For symmetries that involve rotation to an angle other than 180 degrees, the rotation point is usually in the middle of the right-hand side of the bbox. After the pattern is created, resizing the original tile does not move the clones away, so you can make the tiles overlap. Also, when the pattern is created, the current bbox of the original tile is remembered; later, if the "Use saved tile bbox" checkbox is on, the same bbox will be used when you click Create again, which means you can vary the pattern parameters without losing the overlapping of the tiles. ** It's best to use a group as the original object for tiling, because you can then enter this group (right-click, "Enter group") and draw inside it. Any changes or new objects added to the group will show in the pattern immediately.

5 7

pivot in scale mode
by PTT 07 Dec '04

07 Dec '04

I noticed from 0.39 on the pivotpoint (the cross that on which an object rotates, i think it's called pivot) is hidden in scale mode, so only visible in rotate mode. I find it quite usefull in scale mode too, (ie. while overlaying images you move the point to a place you want to keep, then scale so the whole image is as you wish). What is the reason it hides? And can it perhaps be turned into an option? PTT

4 4

inkscape memory leaks
by MenTaLguY 07 Dec '04

07 Dec '04

Hi, I was directed to recent traffic on the freebsd lists... I suspect the memory leaks you're experiencing aren't freebsd-specific, nor are they necessarily the result of bugs in libgc proper -- one of the recurring issues we've been having has been large leaks due to the way we bridged the refcounted and garbage-collected portions of the codebase. In a nutshell, some garbage-collected objects also have refcounts that can be used to pin them so they can be referenced by non-gc-aware objects. Since these objects are still traced by the collector, and are generally organized in the form of trees with parent pointers, a single leaked refcount will pin the entire tree of objects. [ It was one of those designs that seemed like a good idea at the time... ] In a profound irony, pretty much all of the leaks of gc-managed memory we've discovered so far have been due to refcount leaks in conventional code. :/ I thought we had found and fixed them all, but they can be pernicious and hard to nail down; I am noticing that we are still a little leaky on other platforms as well. There may be issues with libgc on freebsd as well, but I would look at refcount leaks if you've not already done so. Anyway, it sounds like you've been spending a good deal of time with debugging this; would you like to further compare notes in case we're duplicating effort? -mental

2 1

Difficulty with sizing imported EPS files...
by Daniel 07 Dec '04

07 Dec '04

[Please cc: me on replies] Hi, I'm using Inkscape 0.40 packaged for Debian unstable. If it's an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the 'file' utility, to be regular postscript, rather than encapsulated postscript). Any ideas? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I've given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

1 0

Fwd: [Inkscape-devel] Graphics-by banner
by Ana Saiz García 06 Dec '04

06 Dec '04

Hi again I'm sorry to bother you again, but I've realised that I hadn't convert the text to curves, in order to avoid problems with the fonts. Now I've corrected this problem, so maybe you can put the new svg in your page (the png hasn't changed). The link is: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg Sorry for the inconveniences and thank you again Ana -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

2 1

Re: [Inkscape-user] RPM build errors
by Bryce Harrington 06 Dec '04

06 Dec '04

On Sat, 4 Dec 2004, Jonathan Leighton [Turnip] wrote: > Okay. I took them all out, and tried to run inkscape, but nothing > happened. As in zero, zilch, nada. The cursor just sat there on the line > beneath the "inkscape" command. So I quit that, and put all the > extensions back in. I then took them out one by one, and when I took out > the one called "gimpgrad.inx", it again wouldn't do anything when I ran > the "inkscape" command. So I believe we have a culprit, although I'm not > entirely sure what I should do now. Hmm interesting, that wouldn't have been the one I'd have guessed. So to recap, you're getting a failure during Extension initialization where it complains about an improperly freed pointer, presumably a string, that appears related to the gimpgrad.inx extension. Ted can you help give some guidance on this? > Just out of interest, do you think this problem is specific to me, or > would it happen to anyone using the RPM I built? Because if it would > happen to anyone then I guess it's more serious. Aha, this is why you shanghai a couple friends into testing it. ;-) Go ahead and see if you can find someone to test it, and see if they get the same problem. That'll be good to know. Let's move this over to the inkscape-devel@ list, it's gotten a bit too nuts and bolts for the user list. Bryce

3 3

OT: Path to NURB
by Aaron Spike 06 Dec '04

06 Dec '04

First off congratulations and thank you for the 0.40 release. I'm telling everyone how much I love Inkscape. I was wondering if anyone could offer some advice or insight. I'm writing a little PHP script to convert a subset of SVG PathData (only M, C, L and z directives) drawn with Inkscape into DXF SPLINEs (NURBs) for use in QCad. I can do it successfully following the practical instructions at the bottom of this article about NURBs <http://www.mactech.com/articles/develop/issue_25/schneider.html>. To do this I write a separate SPLINE for each segment of a Path. I would prefer to write a single SPLINE for each continuous portion of a Path, but I can't get it right. So far I have just been guessing and guessing wrong. Any direction would be appreciated. Aaron Spike

3 4

Making rpm for Suse 9.2
by Jogchum Reitsma 05 Dec '04

05 Dec '04

Hi, On my Suse 9.2 box, I downloaded inkscape-0.40-1.src.rpm from sourceforge, solved a few dependancies and issued rpmbuild --rebuild inkscape-0.40-1.src.rpm to create a rpm-binary (not as root, but as normal user). It compiles OK, but bails out with the following message lines: Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/inkscape-0.40-root error: Installed (but unpackaged) file(s) found: /usr/lib/inkscape/plugins/libgimpgrad.a /usr/lib/inkscape/plugins/libgimpgrad.la /usr/lib/inkscape/plugins/libgimpgrad.so.0.0.0 The mentioned files do exist in /var/tmp/inkscape-0.40-root, and the names are stated in a file /tmp/rpmN24154 Also there exists a file /tmp/rpmF24155 with the same creation date and time, but empty. Anyone an idea what might be happening? Thanks, Jogchum

3 6

concerning layer selection - OpenOffice method works very well (fwd)
by Bryce Harrington 05 Dec '04

05 Dec '04

---------- Forwarded message ---------- Date: Wed, 1 Dec 2004 22:35:51 -0500 From: Phoenix <phoenixreads@...584...> To: bryce@...260... Subject: concerning layer selection - OpenOffice method works very well OpenOffice has a very effective system background graphics I have group 1 above background graphics. I have group 2 above group 1 if I double click on group 1 everything else grays out and now I have group 1 "ungrouped" and highlighted. I am now editing group 1 in context (that is behind group 2, above background). if I click the background, I return to the "edit document" stage. To move from group 1 editing to group 2 editing... I double click to get to the "edit document" stage, then double click to edit group 2. To make things more interesting the concept of layering applies so I can double click groups within groups and edit accordingly. Double-clicking outside the group moves one up in the order. Using version 0.37 for reference. As for Inkscape double-click item to change modes that should become double-click handlers. If I want to experiment, I have to move back and forth to object to change. Double-clicking handlers is more intuitive since that is what I want to change. I don't know enough about internals of Inkscape but a request that Inkscape develop into a vector drawing engine so programs like mind-mapping and Visio-like program are basically a GUI redesign and of course standardize on SVG. Excellent program, Phoenix

2 1

0.40 Build on Mac
by Gazal, Geraud (GE Healthcare) 04 Dec '04

04 Dec '04

Seen today on Linuxfr.org about Inkscape on apple MacOSX Hope it can help some of you (see translation below) Regards, Matiphas --- Bon, donc effectivement, inkscape 0.40 a des dependances assez contraignantes. Une mise a jour complete de tout ce qui est environnement de developpement de Apple (via l'ADC http://connect.apple.com/ est necessaire, et apres ca marche tout seul. Le bug de l'affichage des menus derriere les fenetres reste la. Dommage ----> Yes inkscape has some hard to solve dependancies. A complete update of development enverinment from apple (see ADC : http://connect.apple.com/ ) is required and then it works ok without any problem (Pity, the display bug (menus behind windows is still there)

2 1

Query: I/O cleanup, reorganization?
by Bob Jamison 03 Dec '04

03 Dec '04

Hi all, I am back from holidays today, and have been catching up on my email. I was wondering: would a good task for this cycle be a reorganization of our set of scattered, disparate I/O classes into a nice, clean heirarchy of its own, such as /src/io and the namespace Inkscape::IO? We have been talking about moving from filenames to URIs for months now, and changing slowly from FILE * to iostreams. Maybe now at the beginning of a release cycle would be a good time to bite the bullet. This would not be a roadmap thing, but a nice clean top-to-bottom refactoring that would finally take care of our recurring migraines with files and paths and localization. Consider it to be a big bugfix. If we could upgrade from char * ---to--->FILE * to a much cleaner URI ---to--->istream and URI ---to--->ostream ...with built-in support for localization, it would make things a LOT easier. I have been looking around the net a lot, and there already exists a wonderful 'gzstreams' lib for supporting .svgz without pipes. I experimented with it by recoding my copy of repr-io.cpp to use iostreams instead of FILE *, and it worked wonderfully. There is also a pair of iostream implementations I found, that provide printf() and scanf() style formatting, to alleviate the pain of conversion somewhat. This would be a lot like Java's "java.io.*" heirarchy, putting streams, files, URI/URL's and paths into one place. Any thoughts, opinions? This is just something I have been thinking about recently. Bob

5 15

Article: Introducing Inkscape 0.40
by Bryce Harrington 02 Dec '04

02 Dec '04

The article about Inkscape is now live on OS News: http://osnews.com/story.php?news_id=9049 Also, we got picked up on LWN: http://lwn.net/Articles/113513/ And Footnotes: http://gnomedesktop.org/node/2062 Bryce

3 2

please read webdevnews article before publication today
by Peter Moulder 02 Dec '04

02 Dec '04

An article about inksape 0.40 is to appear on http://webdevnews.com/ at 16:00 in Central US time (which I think means 22:00 UTC). Can pleple please check it and communicate any corrections etc. to SteamedPenguin, who will drop by on IRC some time before then? It isn't yet available to be read as I type this, but should appear at http://webdevnews.com/2004/12/02/open-source-svg-editor-inkscape-reaches-04… before being linked to from the front page. (Incidentally, it's possible that I wrongly guessed what sp meant by "tomorrow", in which case publication would be about 35hrs from this e-mail instead of about 11 hrs.) pjrm.

1 0

Re: C-based garbage collection for Inkscape
by Bryce Harrington 02 Dec '04

02 Dec '04

Thanks Keith, passing along to the crew... Bryce On Tue, 30 Nov 2004, Keith Packard wrote: > > I've been using a garbage collector in C for about twenty years which is > different from the Boehm system. > > advantages: > > 1) Completely portable -- no machine dependent code at all > 2) Integrates with malloc/free using code > 3) Precise pointer knowledge - the set of referenced objects is known, > not discovered. > > disadvantages: > > 1) Requires stylized function call/return macros both where the > allocator is used as well as in at least one place above all > allocation calls in the call graph. > > It's part of the nickle language implementation (http://nickle.org) and > has been used in several other projects to good effect. > > -keith > > >

3 4

Inkscape status 2004-12-01
by Bryce Harrington 02 Dec '04

02 Dec '04

Inkscape 0.40 has turned out to be a good solid release. We're already seeing a surge in downloads, and the response to our notices and article on OS News has been quite positive. There have been a few complaints about the bleeding-edge-ness of the deps; this wasn't a surprise, we knew this would be a tough release for folks to get installed. We should keep this in mind and be a bit more conservative for the next release or two. With 0.40 out the door I see both a collective sigh of relief at being done and ready for a break, plus an energy to start working on new stuff for 0.41. For the next month or so we're going to keep things low key, enjoy the holidays, and work on whatever seems most intriguing. Below I've listed out the stats for the past two months for direct comparison. (I swear, some day I'll graph this data so we can visualize it easier...) Note the big jump in Freshmeat subscribers; these all came the day we announced the new release. Our mailing list memberships are also growing nicely. I think the article in early Nov brought in a sizeable number of people. I suspect that for us to continue building our lists we need to seek out new communities and have articles published in new publications. For instance, we seem to get good coverage in foreign trade magazines; it'd be good to get published in some U.S. computer magazines too. Statistics Oct 15 Nov 1 Nov 15 Dec 1 ========== ====== ===== ====== ===== Lifetime Rank on SourceForge: 687 684 636 636 (95.2%) (95.2%) (95.6%) (95.6%) Max Week's Rank on SourceForge: 124 62 14 16 (99.3%) (99%) (100%) (99.9%) Total SF Page Views 1,339,114 1,487,659 1,758,321 1,921,981 Total SF Downloads 63,869 69,078 80,152 89,345 Total Freshmeat URL Hits 11,465 11,849 12,162 13,351 Total Freshmeat Subscriptions 124 125 126 141 Lines of Code in src/: 303,783 306,602 307,747 309,285 Code lines 216,027 217,198 217,982 218,803 Comment line 52,421 53,262 53,491 53,798 Blank 41,872 42,699 42,829 43,249 Lines of Docs in doc/: 16,841 16,841 16,974 17,901 Lines of content in website: 7,840 8,121 8,382 8,732 Size of the Inkscape wiki: 22,459 18,977 19,735 21,379 Bugs open/total: 135/653 104/683 102/733 119/774 Features open/total: 263/406 279/426 291/448 307/467 Patches open/total: 7/126 7/130 7/137 5/143 CVS Commits (as per inkscape-cvs) 7,860 8,279 8,613 8,878 Inkscape-devel membership: 109 108 117 120 Inkscape-announce membership: 98 113 124 137 Inkscape-user membership: 138 144 157 162 Num Translations: 33 33 33 33 Ave Translation Ratio: 35.0% 38.5 38.4 42.2 * - Statistics unavailable Bryce

1 0

Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)
by Bryce Harrington 02 Dec '04

02 Dec '04

---------- Forwarded message ---------- Date: Tue, 30 Nov 2004 19:01:37 -0500 From: Jonadab the Unsightly One <jonadab@...581...> To: clipart@...330... Subject: Re: [Clipart] Announcing Inkscape 0.40 Release Bryce Harrington <bryce@...260...> writes: > user's may encounter more trouble getting Inkscape installed on some > platforms than in previous releases. To help those who run into > this issue, we're also providing 'Static Binary' packages that > include these new libraries inside the package, and thus, the static > releases are very large. Very large? 8 Megs hasn't been a large size for an application download in *years*. There are *plugins* nearly twice that large. (For example, I've got a copy of j2re-1_4_2_05-linux-i586.rpm sitting around in my downloads directory weighing in at 14MB, and nobody apologised for that being large.) Honestly, I wish more applications would realease statically linked binaries like this. <rant intensity="50%"> However, I still have to chase down a dependency: gtk2. I have gtk2, of course, but apparently it's not the latest and greatest version. So I downloaded that, but now I need other stuff... error: Failed dependencies: libglib2.0 >= 2.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk libpango1.0 >= 1.4.0 is needed by libgtk+2.0_0-2.4.9-9mdk libgtk+-x11-2.0_0 = 2.4.9-9mdk is needed by libgtk+2.0_0-2.4.9-9mdk I need to do this anyway, since there's a new Gimp coming out that I'll want, but this underscores the single largest problem IMO in open-source today: excessive use of dynamic linking makes upgrades painful beyond the bounds of all reason. I can understand the desire to link inkscape dynamically against GTK, because *lots* of stuff links against GTK, and it makes sense to install one copy (of each major version). But I do NOT understand why GTK is linked dynamically against libglib and pango. Virtually nothing else besides GTK uses those libraries, so there's no good reason for the dynamic linking: root@...582... ~/download :) # rpm -q --whatrequires libpango1.0 libgtk+2.0_0-2.2.4-2mdk root@...582... ~/download :) # rpm -q --whatrequires libglib2.0 libgtk+2.0_0-2.2.4-2mdk libgtop2.0_0-2.0.5-1mdk root@...582... ~/download :) # rpm -q --whatrequires libgtk+-x11-2.0_0 gtk+2.0-2.2.4-2mdk libgtk+2.0_0-devel-2.2.4-2mdk root@...582... ~/download :) # Not only is GTK quite pointlessly dynamically linked against libglib and pango, but it *itself* is subdivided into two packages, for absolutely no good reason. This is why I only have time to upgrade stuff at home, and at work I'm still using Gnome 1.4 -- at work, I can't justify the time to chase down a hillion jillion dependencies. I shouldn't have to do it at home either. Nobody should. Hard drive sizes being what they are, it no longer makes sense to save a couple of measley megabytes by inflicting superfluous pain on the user. Inkscape is an application I use with some frequency: as such, it's welcome to a few megabytes of drive space. </rant> One can only imagine the trouble I'd have put myself through if I'd downloaded the non-statically-linked version of Inkscape. <<shudder>> The take-home message is this: Static linking is GOOD, and the world needs more of it. -- $;=sub{$/};(a);=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/ _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

4 5

Scene interpretation mentioned on Slashdot
by Bob Jamison 01 Dec '04

01 Dec '04

There is an article on Slashdot that mentions a "new photographic technique" with some concepts strikingly similar to how the Tracer works: http://science.slashdot.org/article.pl?sid=04/12/01/0238222&tid=152&tid=126… this is the quoted article: http://www.photo.net/learn/technology/mflash/merl-non-photo.html Notice the mention of a "canny edge detector." ;-) One thing that someone showed me, is how tracing the same image multiple times with different algorithms and/or parameters, and recombining the results, can often produce a fairly good rendition of the original. Here is a trivial example of the raytracer doing it with merely 3 different levels of brighness threshold: http://troi.hous.es3.titan.com/~rjamison/inkscape/files/clemens-traced.png So, hey, we are ahead of the curve on this one! ^^ Bob

2 2

Re: Announcing Inkscape 0.40 Release . www.inkscape.org (fwd)
by Bryce Harrington 01 Dec '04

01 Dec '04

---------- Forwarded message ---------- Date: Wed, 1 Dec 2004 18:00:49 +0100 From: Dave Neary <bolsh@...85...> To: Bryce Harrington <bryce@...1...> Subject: Re: Announcing Inkscape 0.40 Release . www.inkscape.org Hi Bryce, Congratulations on the release! Yet another huge step forward. Cheers, Dave. Quoting Bryce Harrington <bryce@...1...>: > Inkscape 0.40 > ============= > > Draw Freely. > > http://www.inkscape.org/ > > The Inkscape community is proud to announce release 0.40 of Inkscape, "A > Cross-Platform Open Source Vector Graphics (SVG) Drawing Tool." This > release includes three highly requested new capabilities: Layers, > Text-on-Path, and Bitmap tracing. In addition, several minor features > have made the cut along with a number of usability enhancements, three > new tutorials, and hundreds of bug fixes; this is by far the most > feature-packed release to date! > > The implementation of layers provides another means for organization of > compositions. Layers can be locked to not allow changes and their > visibility may be toggled on and off. This is great for sketching over a > bitmap image by using it as a template. However, one might skip this > technique altogether by using the new "Bitmap Tracing" which uses > Potrace to convert pixels/bitmaps into vector graphics. Normally this > function is not found in illustration programs, but now it is front and > center right on the canvas within Inkscape. > > Since our last release four months ago, we have added several new > dependencies such as the Boehm garbage collector and the stable Gtk 2.4 > libraries. Hence, installing Inkscape on some platforms might raise more > issues than as with previous releases, and we ask you to please post to > the bugtracker (http://inkscape.org/report_bugs.php) any issues > discovered. To help those who run into undocumented problems we're also > providing 'Static Binary' packages that include these new libraries. > > We celebrate this release from our community and hope to encourage > others to join our project by the simple act of contributing graphics, > tutorials, code, and translations. Inkscape recently became a one-year > old project. We are looking forward to another dynamic year of > development as we move Inkscape further from C to C++, approach SVG Tiny > compliance, and eventually full SVG 1.2 validation. Thank you for using > Inkscape. Draw Freely. > > Download your packages (Linux, Windows, Mac OSX): > > http://sourceforge.net/project/showfiles.php?group_id=93438 > > For many more details, see the Release Notes for 0.40: > > http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes040 > > Community submitted screenshots: > > http://www.inkscape.org/screenshots/ > > > _______________________________________________ > gnome-announce-list mailing list > gnome-announce-list@...45... > http://mail.gnome.org/mailman/listinfo/gnome-announce-list > -- Dave Neary Lyon, France bolsh@...85...

1 0

Re: [Clipart] Announcing Inkscape 0.40 Release (fwd)
by Bryce Harrington 01 Dec '04

01 Dec '04

---------- Forwarded message ---------- Date: Wed, 01 Dec 2004 08:48:44 -0500 From: Carl Worth <cworth@...573...> To: Jonadab the Unsightly One <jonadab@...581...> Cc: clipart@...330... Subject: Re: [Clipart] Announcing Inkscape 0.40 Release On Tue, 30 Nov 2004 19:01:37 -0500, "Jonadab the Unsightly One" wrote: > I'll want, but this underscores the single largest problem IMO in > open-source today: excessive use of dynamic linking makes upgrades > painful beyond the bounds of all reason. The problem of a single application upgrade requiring many libraries to also be upgraded has been solved in any number distributions with good package managers. If you're not yet using one, I would recommend you try one out. > The take-home message is this: Static linking is GOOD, and the world > needs more of it. No. Static linking leads to bug propagation. This is especially bad when there are security bugs in well-used libraries, (for example the zlib bug from some time ago). Widespread use of static linking makes it much harder to get security fixes out since it requires updating many applications. With dynamic linking, only the affected library need be updated. -Carl _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

1 0

Inkscape slides in spanish
by Lucas Vieites 01 Dec '04

01 Dec '04

Hi, A few months ago there was a presentation of Inkscape at the University of A Coruña. Now the slides used at that presentation have been made available. The slides are made in inkscape in order to provide a useable space on the right to do some demos as you speak. Find them at: http://www.gauss-fic.udc.es/Members/moebius/tutoriales/inkscape/inkscape-sl… And «kudos to the author»: Adrián Perez de Castro If an english translation is needed I'll be glad to provide one. Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

3 4

Re: [Inkscape-user] Inkscape Release 0.40 Now Available
by bulia byak 30 Nov '04

30 Nov '04

> > As soon as it's up, I'll post an announcement on deviantart (as a > > majority of users on their site are Win32 based)... I just uploaded the exe installer made by Sim. Please download and test: https://sourceforge.net/project/showfiles.php?group_id=93438

2 1

Wiki again
by Arpad Biro 30 Nov '04

30 Nov '04

Hi, Yet another spammer wants to be banned from the Wiki. See the recent changes for details (if you're strong enough for this kind of stuff). Arpad Biro __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

10 22

Announcing Inkscape 0.40 Release
by Bryce Harrington 30 Nov '04

30 Nov '04

= Inkscape 0.40 = 'Draw Freely' http://www.inkscape.org/ The Inkscape community is proud to announce the release 0.40 of Inkscape, "A Cross-platform Open Source Vector Graphics (SVG) Drawing Tool." This release includes three majorly requested new capabilities: Layers, Text-on-Path, and Bitmap tracing. In addition, there are many minor features, a number of usability enhancements, three new tutorials, and hundreds of bug fixes. This is by far the most feature-packed release the project has had. This is all due to the strong developers that have contributed countless hours on Inkscape 0.40. Following our last release four months ago, we have focused intensively on development, adding several new dependencies such as the Boehm garbage collector and the stable Gtk 2.4 libraries. Because of this, user's may encounter more trouble getting Inkscape installed on some platforms than in previous releases. To help those who run into this issue, we're also providing 'Static Binary' packages that include these new libraries inside the package, and thus, the static releases are very large. Download your packages: http://sourceforge.net/project/showfiles.php?group_id=93438 For many more details, see the Release Notes for 0.40: http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes040 Community submitted screenshots: http://www.inkscape.org/screenshots/

3 2

XMLifying of tutorials
by bulia byak 30 Nov '04

30 Nov '04

As you know, currently tutorials are written directly in SVG. This, among other things, prevents proper automated i18n - if a section changes, a translator will have to manually figure out what changed, manually find the matching text in his translation, and manually change it. Also, producing the tutorials in formats other than SVG is also pretty much manual work. In other words, it looks nice but is a nightmare to maintain. Our attempts to change that ran into difficulties: a script or stylesheet which might generate an SVG tutorial would have to combine text (from some source file, e.g. Docbook) with illustrations (from separate SVG files). To do so, it would need to know the dimensions of the pieces of texts and the illustrations, because everything in SVG is absolutely-positioned. And that was the problem. Now I got an idea: Why not use Inkscape itself for this? Here's how it might work: 1 Add a couple new command line switches to Inkscape that would force it to load the document, find the object with the specified id, and report on the command line the width or height of that object's bbox, then quit. 2 Write an XSLT stylesheet that, for each piece of text, would write a temporary SVG file with it (in flowtext, same as the finished tutorials would use), run Inkscape with these command line switches to figure out its dimensions, and then use these numbers to position it in the final SVG files it produces. Same thing is done with illustrations, except that no temporary files are needed - they are stored separately (and referenced from the master XML source) anyway. If this sounds like a mess, it's not. I've done XSLT running external processes before. It works, and it is even portable (though portability may depend on the processor you use). It will be rather slow but in our case it does not matter much, I guess. So, unless someone invents something still better, I can do 1 above (it will be useful for other things, too), and someone will need to do 2 (with my help if needed). Perhaps 2 can also be done in another language, but I vote for XSLT - it's a very nice and powerful language for XML processing, definitely worth learning.

3 4

Spiral bug
by Gazal, Geraud (GE Healthcare) 29 Nov '04

29 Nov '04

Hi, playing with the 29nov04 build on win2k, I got a very bad bug with spiral Here is the way to reproduce it : Start inkscape Draw a spiral, then set its divergence to 0.00 Select the spiral, and switch to node or spiral tool Try to modify the spiral with the mouse (inner or outer handle) -> crash with an error pop up : **Error**: file sp-spiral.cpp line 446 (NR::sp_spiral_get_xy(const SPSpiral*, gdouble)): assertion failed: (t>=0.0) aborting... I don't think it has been reported yet. By the way, I'm wondering about the toolbar: being in node tool, when selecting a shape (spiral, ellipse, rectangle, star), it displays node commands, that are not applicable to shapes. would it be possible to have it switch to the appropriate toolbar ? (example : selecting a rectangle -> rectangle tools, then selecting a path -> node tools, ...) Shall I submit a RFE for this ? Regards, Matiphas

7 7

End of freeze - back to regular development
by Bryce Harrington 29 Nov '04

29 Nov '04

With 0.40 tagged and branched, it's safe to go back into the water. Regular development can resume now. Thanks to everyone who worked at putting out this release, it is going smoothly, and we don't expect any issues. Presently the focus is on packaging, distributing, and PR. Going forward, the plan is to take a good long break for the month of December. If you're worn out from Inkscape development, please disappear and rejoin us when your batteries are recharged! If you're itching to do some coding, scratch away. I'm going to be working on the Gtkmmification stuff, and would welcome anyone wishing to join in on this; the code is in the experimental CVS module currently, and it'll be integrated into the main codebase in the coming weeks. (Note: Since we added several dependencies in the 0.40 release, it would probably be wise to hold off a bit on adding new ones until we see how these do. If you need to add a new dependency, please get a concensus with the other developers before doing so.) Bryce

1 0

Static builds (again)
by Kees Cook 29 Nov '04

29 Nov '04

Okay. We can take two approaches to the static linux compile: 1- requiring gtk 2.4 already be installed 2- requiring pango 1.0 already be installed Pango does not appear to allow itself to operate as a statically compiled library. As a result, it's use of glib creates dynamic lib deps. I'm going to try to solve that, but it will still require pango dynamic libs. I was shooting for only requiring pango, but this is getting harder and harder. My test-case is a redhat 9 box, and it really doesn't like me: /tmp/inkscape.strip: relocation error: /tmp/inkscape.strip: undefined symbol: g_type_class_add_private So, I'm going to continue working on pango, but I think we can make an operational "static" build that requires gtk 2.4, since that's the bulk of the static lib work I've been trying to make work. Getting gtkmm hasn't been very hard. libgc has some tricks up it's sleeve, but I think I solved those. I'm building an RPM now that basically requires gtk 2.4, but is actually my latest attempt at approach #2. I need someone with an RPM-based distro with gtk 2.4 to test it. All I have is gtk 2.0 on rh9. -- Kees Cook @outflux.net

2 1

Inkscape Release 0.40 Now Available
by Bryce Harrington 29 Nov '04

29 Nov '04

The official 0.40 tarball is now posted, and is available for download here: http://sourceforge.net/project/showfiles.php?group_id=93438 The Release Notes describing the changes are available here: http://inkscape.org/cgi-bin/wiki.pl?ReleaseNotes At this time we are requesting all packagers to create and post packages for the release. Formal announcements for the release will be delayed until Monday evening in order to give a little time for packages to be created and tested. We are also encouraging everyone to assist with the PR push to get word out about this release. If you're interested in writing an article on a topic related to Inkscape, this would be an excellent time to do so. Bryce

3 2

SVG version?
by MenTaLguY 29 Nov '04

29 Nov '04

While I'm thinking about it, what SVG version should we indicate in our output? If we are including SVG 1.2 features like the flow text stuff, don't we almost have to bump the version number to 1.2? -mental

6 17

Hard Freeze
by Bryce Harrington 28 Nov '04

28 Nov '04

We've held off on going into hard freeze for a few days, due to several troublesome bugs. However, I'd like to propose that we move ahead with the hard freeze. It's impossible to release a bug-free product. It's understandable and commendable that we hold such a high set of standards for bug-free-ness, but the fact is, we'll have more releases in the future, and we'll _always_ have "one more thing to do..." If for some people, 0.40 won't run, they can stick with 0.39, or wait for 0.41. We've done a large amount of research into the bugs that exist; we can provide a good, detailed 'known issue' list. Heck, maybe this'll give some others inspiration and a headstart on figuring those problems out in the coming weeks. 0.40 has been one of the most energy-intensive releases that Inkscape's done so far. We've integrated a number of new dependencies, added scores of new features, and fixed hundreds of bugs. I would bet folks are getting worn out! With Christmas coming up, we ought to get the release behind us, so folks can enjoy the time off without worrying about Inkscape issues. This is a great release and I think the community's going to really enjoy it. As far as the remaining bugs go, here are some thoughts. The infamous Windows open file and freeze error is the worst remaining bug, however the current working hypothesis is that it's an issue with libgc. It is entirely conceivable that the fix would go against libgc, not inkscape, so may be entirely orthogonal to our release. However, if indeed it is an inkscape problem, it is an intermittent bug, and doesn't occur on every Windows user's box. As well, the use case for it is on file open, rather than save or during work, so the chance of data loss is small. I think we could simply document the problem and ensure users are aware of it, and provide workarounds/solutions later as we find them. The 'windows gets stuck in loop' error is a similarly annoying problem, and does involve data loss. However, it sounds like it is even less reproduceable than the previous one. The other level 9 bugs do not sound very serious to me. Most appear to be issues for a particular user running on a specific configuration (e.g., with Japanese language encodings, or installing with the autopackage snapshot, or when compiled with a particular version of gcc, etc.) All of these need fixing, but I don't think they're critical enough to warrant delaying the release. I suggest we write the hypotheses for each level-9 bug, list them as 'known issues' in the release notes, and move forward with the hard freeze today. Bulia, Mental, Kees, Peter, Jon Cruz, Ishmal, Simarilius, and Ted, how do you feel about moving forward with the release at this time? Bryce

2 2

Updated Norwegian Nynorsk translation of Inkscape
by Karl Ove Hufthammer 28 Nov '04

28 Nov '04

Here's an updated Norwegian Nynorsk translation of Inkscape. Please commit it to CVS. Hope I'm not to late for 0.40! :) -- Regards, Karl Ove Hufthammer

2 1

Fwd: [Inkscape-devel] Graphics-by banner
by Ana Saiz García 28 Nov '04

28 Nov '04

I'm very proud to see it in your homepage :o) Only a remark, my first surname isn't García, but Saiz (you know, I'm spanish, so I have two surnames :o)) I'm glad you liked it, thanks for all Ana On Sun, 28 Nov 2004 12:57:03 +0100, Ana Saiz García <anasaiz@...400...> wrote: > thanks to you :o) > > On Sat, 27 Nov 2004 22:59:53 -0800 (PST), Bryce Harrington > > > <bryce@...260...> wrote: > > Thanks Ana, I've added it to our homepage, and stuck them in our images > > directory. :-) > > > > Bryce > > > > > > > > On Sun, 28 Nov 2004, [ISO-8859-1] Ana Saiz García wrote: > > > > > Hi all > > > > > > I've been searching for the typical "graphics-by" banner to put it in > > > a web and let all people know I've used Inkscape to make some of the > > > graphics on the web, but i didn't manage to find anything. I don't > > > know whether there is already something like that, but I've done one > > > on my own and I wanted to share it with you in case somebody else want > > > to use it. > > > > > > I don't know if I can send attachments to this list, so I give you two > > > links from where you can download it. > > > > > > Here is the svg: > > > > > > http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg > > > > > > And here is the png, with a more appropiate size for a banner: > > > > > > http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.png > > > > > > Hope you like it :o) > > > > > > Ana > > > > > > > -- > "El más baldío de todos los días > es aquél en que no hemos reído" > (de Chamfort) > > http://www.cosasdedos.net > http://ana.cosasdedos.net > -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

1 0

Graphics-by banner
by Ana Saiz García 28 Nov '04

28 Nov '04

Hi all I've been searching for the typical "graphics-by" banner to put it in a web and let all people know I've used Inkscape to make some of the graphics on the web, but i didn't manage to find anything. I don't know whether there is already something like that, but I've done one on my own and I wanted to share it with you in case somebody else want to use it. I don't know if I can send attachments to this list, so I give you two links from where you can download it. Here is the svg: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.svg And here is the png, with a more appropiate size for a banner: http://david.f.v.free.fr/ana/imagenes/gfx_by_inkscape.png Hope you like it :o) Ana -- "El más baldío de todos los días es aquél en que no hemos reído" (de Chamfort) http://www.cosasdedos.net http://ana.cosasdedos.net

2 1

Final release candidate for Inkscape 0.40
by Bryce Harrington 28 Nov '04

28 Nov '04

Hi All, Tonight we are entering the 'Hard Freeze', the very last phase before the final tagging and branching of 0.40, which is planned for tomorrow evening. Ted has created the final release candidate, 0.40pre5, which is now available from the website. Testing is essentially complete, however we're encouraging people to give the release a quick review. We're looking for silly mistakes like forgetting to update the version number, packaging problems, and major show-stopper bugs. But also add anything else you find to the bug tracker, and we can sort those issues out during the next development cycle. During this Hard Freeze phase, we're going to let the dust settle a bit, do a once-over, and then proceed with packaging and delivering the release. As with all prior releases, once it's cut we need to switch into marketing mode, in order to get the word out. This is where Inkscape users can make a big contribution. We want to get word out on all the major blogs, articles into relevant online magazines, and word of mouth to friends and family. Stay tuned. :-) Bryce

1 0

problems with sf cvs
by Adib Taraben 27 Nov '04

27 Nov '04

Hi, I am having following problems since yesterday: cvs -d :pserver:anonymous@...54...:/cvsroot/inkscape login Logging in to :pserver:anonymous@...54...:2401:/cvsroot/inkscape cvs [login aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused) ***** CVS exited normally with code 1 ***** I cannot connect to the cvs . Any hints, MANY THANKS; Adib.

3 3

Hard Freeze 11/26 ?
by Bryce Harrington 27 Nov '04

27 Nov '04

Hi all, Is anything remaining to be done, or are we ok to move into hard freeze tomorrow? If so, perhaps we can target having 0.40 tagged and branched by Friday evening? Bryce

8 16

new about screen modification
by Andy Fitzsimon 27 Nov '04

27 Nov '04

I'm not sure if this is better than the current about screen in CVS but i'll let Bulia decide.

1 0

test - ignore
by Kees Cook 26 Nov '04

26 Nov '04

Sorry, please ignore. Sourceforge has been acting up for me... -- Kees Cook @outflux.net

1 0

[Fwd: SourceForge.net Sitewide Update: Nov 23, 2004]
by Jon Phillips 26 Nov '04

26 Nov '04

We made Number 21 for the month on sourceforge!!! > 21. Inkscape > https://sourceforge.net/projects/inkscape > A Linux and Windows vector graphics editor (SVG format) featuring > transparency, gradients, node editing, pattern fills, PNG export, and > more. Aiming for capabilities similar to Illustrator, CorelDraw, Visio, > etc. Jon -- Jon Phillips (NEW) 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

Updated spanish po
by Lucas Vieites 26 Nov '04

26 Nov '04

Justo to have the max of strings translated before hard freeze, here's an update to the spanish po ;-) Cheers -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

2 1

Re: [Inkscape-devel] w32: Gtk24.zip with new xml.dll
by Jasper van de Gronde 26 Nov '04

26 Nov '04

Ted Gould wrote: > Well, that wouldn't be a bad thing, but the reason that svgz was done > this way in the first place was to test the scripting stuff. It seems > to have done that, and proven there is a problem on Win32. I'd like to > fix the problems with the scripting stuff on Win32 also... I think that > is also a 0.41 issue though. I'd say the following note from MSDN explains it all: --------------- Note The _popen function returns an invalid file handle, if used in a Windows program, that will cause the program to hang indefinitely. _popen works properly in a Console application. To create a Windows application that redirects input and output, read the section "Creating a Child Process with Redirected Input and Output" in the Win32 SDK. --------------- If you're interested in some code that does work with Win32 I'd be happy to provide it (I have some code lying around that would only need minimal changes).

1 0

Inkscape does not save to A:\ drive
by vellum 26 Nov '04

26 Nov '04

Inkscape build 041124 win32 2000 does not save to A:\. (31/2 " floppy). The dialog has PCINTERNET2 as the drive name. When you try and save to that drive you get an error message saying 'Could not mount PCINTERNET2 (A:\): This file system does not support mounting'. vellum kaver@...68...

1 0

RE: What do you _really_ want? [was RE: [Inkscape-devel] SVG Linking]
by NAGY Endre 26 Nov '04

26 Nov '04

Alan >and want to be able to add arbitrary name value pairs to >objects rather than using any namespaces in particularly? No. I have an XML Schema that conforms to "Topic 5 : Features" of the OPenGIS Abstract Specification. That is, it contains elements that are "geographic" (for which Inkscape provides a very convenient means of maintenance) as well as other domain-specific attributes that are associated with these geographies. These are ussually simple string types. When I proposed the capability of providing a form of name-value-pair maintenance capability I was envisaging a simple means of maintaining these attributes (in the hope of the availability of an imminent solution). If such capability were thought to be appropriate then of course the mechnism by which this would be achieved would be up to the Inkscape community. I have no intent in providing users with the ability to define arbitrary name-value pairs. >Why do I get the sneaking suspicion that you are using Inkscape for >diagramming >Inkscape is a vector graphics editor >Dia is for Diagrams http://gnome.org/projects/dia/ Rather than being concerned with identifying the (presumably mutually exclusive) domain of descriptive terms, I would prefer to deal with the more practical issue of which tool is most suited to my applications development problem. A brief examination of the capabilities of DIA indicated that it follows an "Object-Connector" paradigm. This does not suit my purpose of manipulating geographic entities. These are arranged and transformed spatially in a multitude of ways according to the desires of a user. I've been able to demonstrate the rich capabilities of Inkscape in achieving these spatial operations. I've not seen anything in DIA that comes close. The question is "will Inkscape support the maintenance of domain-specific attributes associted with geometries(while admitting that such capabilities may be rudimentary), or will shapes only ever be shapes" Regards Endre -----Original Message----- From: Alan Horkan [mailto:horkana@...44...] Sent: Wednesday, 24 November 2004 3:43 AM To: NAGY Endre Cc: Inkscape is a vector graphics editor Subject: What do you _really_ want? [was RE: [Inkscape-devel] SVG Linking] On Tue, 23 Nov 2004, NAGY Endre wrote: > Date: Tue, 23 Nov 2004 14:40:05 +1100 > From: NAGY Endre <Endre_NAGY@...561...> > To: bulia byak <buliabyak@...400...> > Cc: inkscape-devel(a)lists.sourceforge.net > Subject: RE: [Inkscape-devel] SVG Linking > > Bulia > > Thanks for responding > > I take your point about distinguishing "editing" from "viewing". I was > ignorant of the existance of inkview. > > To quote my original mail > >My purposes are not the rendering of HTML but rather the invocation of > >a program. Does inkscape support this and how. > My original post was grasping at a solution for my posted Feature > Request "1070754 - Maintaining Attributes in Users Namespace". In > essence, the request was for some capability that allowed for the > maintenance of the attributes of a shape that are defined in the > namespace of the user (e.g if a line represented a road then I would > like to define the name of that road). Why do I get the sneaking suspicion that you are using Inkscape for diagramming and want to be able to add arbitrary name value pairs to objects rather than using any namespaces in particularly? HTML was very clever in simple the way it did meta data tags, basically it provided a single tag and two attributes and from there users could create as many of their own name (Author) value (authorname) pairs as they would like by specifying new values for content and name everytime. <meta content="Author" name="authorname"> <meta content="desc" name="description"> (Dia users have been asking for the ability to tag objects with all kinds of information for ever and that has only confirmed my belief in the need for a meta data system that would be simple and extensible at the user level rather than requiring an extended predefined schema). You can see OpenOffice.org offers a similar ability to have an unending set of name value pairs http://books.evc-cit.info/ch02.php#meta-xml-section this screenshot shows it reasonably well the numbered labels are the names and the text entries are the corresponding values, and the popup shows they are arbitrary pairs. http://books.evc-cit.info/figures/ooo.ess.0203.png Let me use this opportunity to say that I hope parts of the Oasis standardized namespaces could be reused by Inkscape rather than creating more things in the inkscape: namespace. I hope to do more reading soon and recommend what custom tags and markup that it migth make sense to drop in favour of an open and standardised namespace shared by a variety of other applications. > From the perspective of the users of the application that I'm > developing, this activity is part of the process of "svg creation" not > of "svg use" (by which I mean, analogously, "editing" not "viewing"). Even if my guessing is way off a better less evasive description of what you are actually trying to do, the specific end result you are trying to achieve will better enable the developers to help you than specific example problems. If you are really lucky it might even allow them to indirectly help you by doing things they were planning on doing anyway at some point. > Any thoughts ? > > Endre Sincerely Alan Horkan Free SVG Clip Art http://OpenClipArt.org Dia is for Diagrams http://gnome.org/projects/dia/ Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

3 3

layer selector upate problem solve d
by MenTaLguY 26 Nov '04

26 Nov '04

Okay, finally nailed it down. It seems that sigc++ doesn't deal with reference parameters totally graciously; it was creating a copy of an SPObject & argument somewhere internally, causing equivalency tests further in to fail. Actually this would have been caught a long time ago if SPObject had been given a private copy constructor (or at least not left with an implicit public one). Rule of thumb with C++: if it's not a value class [a class in which binary copies of objects are interchangable], give it a private copy constructor like so: class Foo { public: Foo(); ... private: Foo(Foo const &); // no copy }; You needn't actually define the copy constructor once you've declared it, as in this case it shouldn't be used. If you don't do this, C++ will add a copy constructor for you that just does a binary copy, and all kinds of happy bugs like the one I just fixed can sneap up on youl. In rare cases where you do need to give such classes real copy constructorsm, make sure that they're either explicit, or not public. -mental

4 4

fullscreen mode
by Alexandre Prokoudine 25 Nov '04

25 Nov '04

Hi, I might be missing something, but there is no "fullscreen" menu item in Linux version of Inkscape for several weeks, though Windows version has it. Where has it gone and why? I have CVS from 22nd, November in both Linux/Win environment at the moment. Alexandre

1 0

layer naming dialog progress
by MenTaLguY 25 Nov '04

25 Nov '04

Well, I think I've done about all I can do on the layer naming dialog for this release. At least now it doesn't get confused about which desktop's layers it should be renaming (I removed the use of SP_ACTIVE_DESKTOP), it's modal, and it won't sit on desktop or layer refs after it's closed either. The remaining thing to do is to fix the updating of the layer selector widget. It is apparently my bug rather than Gtk's, thankfully, though I've not figured out 100% yet what is going wrong except that the tree model row corresponding to the layer isn't being found (so the row update stuff is never called). -mental

1 0

static library linking
by Kees Cook 25 Nov '04

25 Nov '04

Okay, I talked with Bob and I now understand what's going on. We're not doing a static binary (where ldd returns nothing), we're linking various libraries statically. The goal is to make certain weird ones static, and leave the more common stuff. Basic steps: compile libraries statically, link inkscape against those. I wrote up a quick Wiki how-to: http://www.inkscape.org/cgi-bin/wiki.pl?CompilingStatic and then modified the inkscape.spec file to allow static library linking. Unfortunately, I've got Debian, so my built RPMs are a little weird. :) I didn't want to "publish" my goofy RPM on Sourceforge, but Bulia wanted to see it, so here it is: http://outflux.net/inkscape-0.40cvs-CVS.i386.rpm (don't ask why it's named all weird... must be RPM magic.) Using "alien" anyone can easily convert this to a tarball, too. -- Kees Cook @outflux.net

1 0

snap to page border
by David Christian Berg 25 Nov '04

25 Nov '04

The first and often only guides, I create, are guides on the page border and guides that are within a 5 mm frame from the border. Now this makes me think if it wouldn't make sense to have a "snap to page border" in the documents prefs (page tab) as well as a "snap to margin" and then be able to define a top, left, right, bottom margin of the page. Should I file an RFE? David

3 5

Preferences Window wide open-bug
by kaver 24 Nov '04

24 Nov '04

build 041124 win32 2000 The Inkscape Preferences window opens up full size and I cannot resize it. It is full size or nothing. The Document Preferences window works fine. vellum

1 0

flow text
by David Christian Berg 24 Nov '04

24 Nov '04

Hi guys, I just worked with flow text for the first time and I really, really love it! You can't tell how much I'm looking forward to proper flow text editing... I mean it was kinda of a pain copying all those spans and stuff but wow, what a result! (see attached screenshot) This is a major step towards professional layouting, I must say. David

2 1

Typographic vocabulary
by Gazal, Geraud (GE Healthcare) 24 Nov '04

24 Nov '04

Hi Inkscapers, and especially translators, I've found a very usefull link for typographic translation (especially for those very specific words like kerning...): http://www.irisa.fr/faqtypo/lexique.html Will also post this link on the Wiki Hope it helps some of you, Matiphas

1 0

CVS status
by Gazal, Geraud (GE Healthcare) 24 Nov '04

24 Nov '04

The problems seems to be resolved now. For info, seen this morning on : http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352 -> ( 2004-11-23 08:07:38 - Project CVS Service ) On 2004-11-23 a disk failure on the anonymous CVS server for projects starting with the letters: e, h, i, j, o and v is causing anonymous CVS, ViewCVS and tarballs for these projects to be unavailable. We are currently working on this issue and do not have an ETA for resolution. Regards, Matiphas

1 0

0.40pre4 posted
by Ted Gould 24 Nov '04

24 Nov '04

Hey everyone, I've put up 0.40pre4. This will be the last pre-release assuming no surprises. There are some new tutorials and updates to the layers GUI elements in this release. Along with several bug fixes. As always, if you make a package please e-mail the list so that we can get it up on the file tracker for everyone to use. http://sourceforge.net/project/showfiles.php?group_id=93438&package_id=9911… --Ted

1 0

NEW: calligraphy and tracing tutorials
by bulia byak 24 Nov '04

24 Nov '04

Today two new tutorials were checked in: Calligraphy and Tracing (in Help > Tutorials). Calligraphy tutorial describes in detail the capabilities of the improved Calligraphy pen tool. A brief history of the art, parameters of the tool, useful tips, and many examples from simple strokes to complete lettering projects. Tracing tutorial explains all the options and parameters of the Potrace interface for bitmap tracing, with tips and examples.

1 0

Freehand drawing
by vellum 24 Nov '04

24 Nov '04

The Freehand tool seems much smoother in recent incarnations. vellum

7 16

SourceForge.net Sitewide Update: Nov 23, 2004 (fwd)
by Bryce Harrington 23 Nov '04

23 Nov '04

Hey hey, check it out, we finally made it to the SourceForge top 25 projects report: ---------- Forwarded message ---------- Date: Tue, 23 Nov 2004 14:29:56 -0800 (PST) From: SourceForge.net Team <noreply@...34...> To: bryce@...1... Subject: SourceForge.net Sitewide Update: Nov 23, 2004 (You have acquired this SF.net update because you requested to be on the ... 21. Inkscape https://sourceforge.net/projects/inkscape A Linux and Windows vector graphics editor (SVG format) featuring transparency, gradients, node editing, pattern fills, PNG export, and more. Aiming for capabilities similar to Illustrator, CorelDraw, Visio, etc. Bryce

1 0

Re: inkthing
by Jon Phillips 23 Nov '04

23 Nov '04

Hey Greg, Here is what looks like should install for OS X. It seems that the OS X installer does not exist, but ways to install it using two packaging systems on OS X do exist. Mac OS X using DarwinPorts: http://inkscape.darwinports.com/ Mac OS X using Fink (http://fink.sf.net/) There are current installer versions for windows here: http://prdownloads.sourceforge.net/inkscape/Inkscape-0.39-1.win32.exe?downl… and you can get other versions here: http://sourceforge.net/project/showfiles.php?group_id=93438 In terms of an easy to use DMG package for OS X, it appears that this does not exist currently. I am going on a hunt for this and am going to try and get one generated or do myself. This needs to exist for Mac OS X! Jon On Tue, 2004-11-23 at 09:20 -0800, Greg Niemeyer wrote: > Dear Jon, > > Please tell me wheer I can find more information about a compiled > version of Inkscape for OSX...Thanks, Greg > 050505: UC Berkeley Center for New Media Groundbreaking and Conference > (May 5, 2005) > -- Jon Phillips (NEW) 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 1

RE: [Inkscape-devel] SVG Linking
by NAGY Endre 23 Nov '04

23 Nov '04

Bulia Thanks for responding I take your point about distinguishing "editing" from "viewing". I was ignorant of the existance of inkview. To quote my original mail >My purposes are not the rendering of HTML but rather the invocation of a program. Does inkscape support this and how. My original post was grasping at a solution for my posted Feature Request "1070754 - Maintaining Attributes in Users Namespace". In essence, the request was for some capability that allowed for the maintenance of the attributes of a shape that are defined in the namespace of the user (e.g if a line represented a road then I would like to define the name of that road). >From the perspective of the users of the application that I'm developing, this activity is part of the process of "svg creation" not of "svg use" (by which I mean, analogously, "editing" not "viewing"). I had chosen a misleading example. 8^( Any thoughts ? Endre -----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: Tuesday, 23 November 2004 11:26 AM To: NAGY Endre Cc: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] SVG Linking > When invoking the example in InternetExplorer, the affect of clicking on the > ellipse is to bring up W3's web page. > I have not found a way of achieving this in inkscape. What, Inkscape did not show you the web page?! :) Seriously, it would be nice to run a browser by clicking a link. In theory. In practice, Inkscape is not so much of a "user agent" as it is an SVG creating application. In particular, following link on click will badly get in the way of editing. Clicking something in Inkscape has lots of editing functions. So, while we can create links, I think we can be excused for not following them. This of course applies to inkscape proper. For inkview, following links by calling a browser is a must. I think we already have an RFE on that; search in the tracker and add your comments. IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

2 1

layers behaviour
by vellum 23 Nov '04

23 Nov '04

Some immediate thots on layers. As I have not tried them before.Just downloaded 17 Nov build and playing with layers in Win32 2000. First thoughts are that the writing on the layer button is so small as to be almost illegible...and I'm using a 21 inch screen. When the little layer window opens there is a VERY small thingo above and to the left of the top layer. I cannot see what it is or does. It looks like (*001) and clicking it brings it up as a layer I think but the eyeball and padlock are then greyed out. I added five layers and the order appears was 2, 4, 5, 3, 1 from the top down. What is the logic behind this? It is easy to change layer positions but a bit disconcerting to see the order as it sets itself up. Reminds me of what happens with patterns. Flicking visibility and locking on and off for each layer is slow and awkward since only the active layer can be treated at one time. This makes changing the status of several windows a "clicky" business and will be a pain in the butt if say 50 layers were involved. I am more familiar with the CD, XaraX style where each layer has its own padlocks etc. It was not a surprise to find I could not select objects when the layer was locked. It was a surprise to find that I could rubber-band them. Very cool. I like that touch. And the rubber banding works across layers whether locked or not. But is that the way it is meant to work? I found it disconcerting to be able to draw on a locked layer. Now to chase that mail that asked us to look at specific things...if I can refind it. vellum

4 5

w32: Gtk24.zip with new xml.dll
by Bob Jamison 23 Nov '04

23 Nov '04

I made a new build with the replaced libxml2-2.dll, as indicated by John Cliff. Someone please give it a try, to make sure it: 1) Runs, without complaining about a missing DLL, or crashing. 2) Can load and save a .svgz on Windows If this works, I will upload the .zip to the server, and change the link. Bob

6 12

Re: [Inkscape-devel] w32: Gtk24.zip with new xml.dll
by Bob Jamison 23 Nov '04

23 Nov '04

Bob Jamison wrote: > Actually, Johan Ceuppens already made streams-zlib.cpp > for expanding .svgz's. All we need to do, maybe, is just > add methods for compressing. > > After the release, of course. > Also, I found a very nice iostreams wrapper of zlib here: http://www.cs.unc.edu/Research/compgeom/gzstream And the library is only comprised of two files: gzstream.h gzstream.C ...with no dependencies except stdc++ & zlib. It is nice clean code, and LGPL. We could just throw the two files into /src, and add them to Makefile_insert. Voila! And their tests compare their output with gzip. Just what we need. Bob Bob

1 0

w32: Gtk24.zip with new xml.dll
by Bob Jamison 23 Nov '04

23 Nov '04

Ok, I changed the links for gtk24.zip on http://troi.hous.es3.titan.com/~rjamison/inkscape ...to point to gtk24-041122.zip which has the replaced libxml2-2.dll Bob

1 0

pre4 requested
by bulia byak 23 Nov '04

23 Nov '04

The absolutely last feature, the "new layer" dialog, has been just checked in. Drawing on locked or invisible layers is disabled. So we are good to go into freeze as soon as pre4 is made (source and static binary). There are two layer bugs which I hope are easy to fix: - when renaming layer, the widget at the bottom is not updated until you move mouse over it - when creating new layer, if you press Enter in the dialog, the layer is created twice (clicking on "create" does it once as expected)

1 0

Freeze question & updated spanish po
by Lucas Vieites 23 Nov '04

23 Nov '04

Hi, I'm attaching an updated spanish po. Is the "feature freeze" is also a "string freeze"? If no new strings are added, I would like to do a full revision of the correctness of the strings in their context. For this I must agree with bulia in insisting on the creation of static builds. I'm having continuous failures trying to compile gtkmm on my system, which I can't afford to have unstable. Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

5 9

OPB: Linux Brings Oregon International Attention
by Bryce Harrington 23 Nov '04

23 Nov '04

This is terribly off topic but I thought it was cool - our local PBS station is running a piece about Open Source here in Oregon... http://www.publicbroadcasting.net/opb/news.newsmain?action=article&ARTICLE_… Bryce

1 0

SVG Linking
by NAGY Endre 23 Nov '04

23 Nov '04

Greeetings I attempted to invoke the example in S17.1 of the SVG 1.1 specification in inkscape. This deals with "Linking out" of SVG content.The relevent part of this is <a xlink:href="http://www.w3.org"> <ellipse cx="2.5" cy="1.5" rx="2" ry="1" fill="red" /> </a> When invoking the example in InternetExplorer, the affect of clicking on the ellipse is to bring up W3's web page. I have not found a way of achieving this in inkscape. The relevent parts of the spec are 1. "SVG 1.0 only requires that user agents support XLink's notion of simple links." 2. "By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources." 3. "If the above SVG file is viewed by a user agent that supports both SVG and HTML, then clicking on the ellipse will cause the current window or frame to be replaced by the W3C home page." WRT 1, does inkscape meet this requirement WRT 2, MouseClicking events in inkscape are trapped for the puposes of the selector tool (I dont know how to turn of all tools). How can I activate the link WRT 3, My purposes are not the rendering of HTML but rather the invocation of a program. Does inkscape support this and how. Regards Endre IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

2 1

caption for Layer - not readable
by Taraben, Adib 22 Nov '04

22 Nov '04

Hi, I extracted the last win32 snapshoot on my win2000 box. My problem I cann not read the caption on the layer-combo-box on the statusbar. The Font is to small or hiroglyphic ?? attached screenshot. HTH, Adib.

4 4

Spam again
by Gazal, Geraud (GE Healthcare) 22 Nov '04

22 Nov '04

Hi The wiki has been spammed once more. The spammer is registered as Durik... ( see revisions of spammed pages for more info) Regards, Matiphas

2 1