- Inkscape Devel - Inkscape Mailman

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3

Re: [Inkscape-devel] Re: [Inkscape-devel] BUG and solution in align dialog
by bulia byak 18 Jul '04

18 Jul '04

> My SF name is o__b Done, you can commit your code now. Welcome to the team! :) > > One idea I had is this: Imagine you have a path consisting of strict > > horizontal and vertical segments, and you want to distribute (some of > > the) vertical segments (not nodes!) equi-spacely. I think it's a > > pretty common situation, but distributing _nodes_ will break the > > verticality of segments. So I propose to add a (perhaps optional) > > rule: If two or more nodes are aligned vertically (within some > > tolerance), consider them one node and move them as a whole during > > horizontal distributions, and the same for horizontal > > alignment/vertical distributions. Makes sense? > > > Looks weird to me, and could be surprising for the user. But I understand the > need for such a functionality. If we generalize a bit, this would be > distributing groups of nodes. But this is hard in terms of UI. Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value). > > Another thing I always wanted to have is Random distribution. Maybe > > you can add it while you're working on that dialog, I think it should > > be easy enough? > > > > I'm not sure to understand what it means. Just throw each node on an random > position, or keeping the order and randomize the step size, or even > distribute against a distribution function (gaussian, poisson, etc.) ? In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle. 1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button. 2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again. Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy). Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers. Let me know what you think of this plan. > Done. I'm just wondering why so many enums are anonymous and you pass plain > ints as parameters ? No idea, maybe just Sodipodi legacy... > > > Yes. But as we will refactor all the dialogs, that should be > > > the right time to do it. The only thing needed is to make > > > each dialog inherit from a class. > > > > That's a good idea, as currently there's much shared code that can be > > moved to the parent class (delete/destroy handlers, etc.). Some of the > > shared code is already factored out into dialog-events but not all. > > > OK, I'll look at this. Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).

2 1

gtkmm 2.4
by MenTaLguY 18 Jul '04

18 Jul '04

Now that we've branched for the release, HEAD is unfrozen. I think my first bit of work will be to merge Aubanel's gtkmm 2.4 patch sometime in the next few days. If this will cause undue problems for anyone, please scream now. -mental

4 6

RPM packaging issue
by Bryce Harrington 18 Jul '04

18 Jul '04

Btw, there was one issue I found in the inkscape.spec file that other RPM packagers will need to look to as well: * Remove the following line from the spec file: %{_libdir}/inkscape/extensions/* We have consolodated extensions into the /usr/share/inkscape directory with the other data files. Bryce

2 2

Crash on editing a circle
by Mike Hearn 17 Jul '04

17 Jul '04

Hi, I have a reproducable crash on CVS from a few days ago, when doing the following: * Start Inkscape * Zoom in a bit on the blank canvas * Add a new circle (made whole) * Press ctrl+shift+f (fill/stroke dialog). Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087436352 (LWP 15995)] 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 256 ~basic_ios() { } (gdb) bt #0 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #1 0x080b15c8 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #2 0x0814be5a in sp_marker_prev_new(unsigned, char const*, SPDocument*, SPDocument*, char*, NRArena const*, unsigned, NRArenaItem*) (size=22, mname=0x87534a0 "Arrow1M", source=0x83134a8, sandbox=0x8313470, menu_id=0x822f56b "marker-start", arena=0x87db328, visionkey=7, root=0x875f600) at sp-object.h:173 #3 0x0814c51a in sp_marker_list_from_doc (m=0x8647700, current_doc=0x8313400, source=0x83134a8, markers_doc=0x0, sandbox=0x8313470, menu_id=0x822f56b "marker-start") at dialogs/stroke-style.cpp:1008 #4 0x0814c9b6 in ink_marker_menu (tbl=0x88c1e58, menu_id=0x822f56b "marker-start", sandbox=0x8313470) at dialogs/stroke-style.cpp:1126 #5 0x0814da4e in sp_stroke_style_line_widget_new() () at dialogs/stroke-style.cpp:1532 #6 0x081481cf in sp_object_properties_dialog() () at dialogs/object-properties.cpp:216 #7 0x081a00aa in sp_action_perform(SPAction*, void*) (action=0x879a3d0, data=0x0) at helper/action.cpp:132 #8 0x0809dcc6 in sp_shortcut_invoke(unsigned, SPView*) (shortcut=50331718, view=0x858b130) at shortcuts.cpp:33 #9 0x081a2816 in sp_window_key_press (widget=0x894c468, event=0x0) at helper/window.cpp:34 #10 0x405c427c in _gtk_marshal_BOOLEAN__BOXED (closure=0xbffff2d4, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8, marshal_data=0x0) at gtkmarshalers.c:82 #11 0x40884dd6 in g_closure_invoke (closure=0x894c450, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8) at gclosure.c:437 #12 0x4089698a in signal_emit_unlocked_R (node=0x831c268, detail=0, instance=0x894c468, emission_return=0xbffff260, instance_and_params=0xbffff2c0) at gsignal.c:2506 #13 0x40895a21 in g_signal_emit_valist (instance=0x894c468, signal_id=0, detail=0, var_args=0xbffff450 "h\2240\bx}\213j@...455...") at gsignal.c:2205 #14 0x40895eab in g_signal_emit (instance=0x894c468, signal_id=52, detail=0) at gsignal.c:2239 #15 0x406a8ebc in gtk_widget_event_internal (widget=0x894c468, event=0x8974620) at gtkwidget.c:3563 ---Type <return> to continue, or q <return> to quit--- #16 0x405c2a16 in gtk_propagate_event (widget=0x894c468, event=0x8974620) at gtkmain.c:2318 #17 0x405c1857 in gtk_main_do_event (event=0x8974620) at gtkmain.c:1582 #18 0x4079844a in gdk_event_dispatch (source=0x0, callback=0, user_data=0x0) at gdkevents-x11.c:2133 #19 0x408d1384 in g_main_dispatch (context=0x82c0000) at gmain.c:1895 #20 0x408d2349 in g_main_context_dispatch (context=0x82c0000) at gmain.c:2441 #21 0x408d266e in g_main_context_iterate (context=0x82c0000, block=1, dispatch=1, self=0x82c24c0) at gmain.c:2522 #22 0x408d2bd6 in g_main_loop_run (loop=0x8982d68) at gmain.c:2726 #23 0x405c11cb in gtk_main () at gtkmain.c:1172 #24 0x08089ead in sp_main_gui(int, char const**) (argc=1, argv=0xbffff6f4) at main.cpp:311 #25 0x08089d24 in main (argc=1, argv=0xbffff6f4) at main.cpp:233 thanks -mike

9 15

Test strategy
by Gazal, Geraud (MED) 17 Jul '04

17 Jul '04

Hi all, here is my workaround for the testing strategy of Inkscape. (sorry it's a copy paste of my doc in the mail, I can forward you the rtf document if you want)(easier to read) I'm currently listing the "specifications", in order to have a reference of features to be tested. The main things that should be defined if you agree with this : - establish a test process - establish communication/coordination tools (wiki / specific web page /mail list ?) - prepare/review specifications,test tools and test cases - begin tests Regards, Matiphas Preliminary note: This is a preliminary/draft document for defining a test strategy for Inkscape projet (http://www.inkscape.org) It is currently in Rich Text Format (rtf), for easy exchange purposes. -> Don't know yet how to manage this document (Dookbook ? Open Office)(specific web page ? wiki ? cvs ?) -> Any way this document will split for the following reasons : - separate specifications of software, test strategy, test traceability, test items, test results... - ease of maintenance - separation of features under test At the moment, it is mainly architectured according to the categories of bug tracking under sourceforge tool for Inkscape (see http://sourceforge.net/tracker/?group_id=93438) Reference: Inkscape testing framework: http://www.inkscape.org/cgi-bin/wiki.pl?TestingFramework (Missing) Inscape "specifications" (not really a pure specification of the software, this would be incompatible with the development process of Inscape, but somewhat a hierarchised and detailed list of features to be tested) Introduction: Why testing ? Just to ensure quality of the software (does it suits user needs ?) and even better the quality of the code/design What are the important concepts of testing : - measure: metrics (specifications and comparison to those specifications) are needed. This is important for the homogeneity of the tests and the correct interpretation of their results - coverage: what are the areas (design / code / features / architectures) covered by the tests. Stronly linked to the efficiency of the testing process - repeatability/reproducibility. The tests must provide coherent results, in order to to be correctly interpreted. Automatisation of the tests and well documented references (vocabulary, procedures...) help a lot. - periodicity: when shall the test be executed. This depends on the criticity, probability of bug and level of test. What is required for having efficient tests : - KISS : tests cases should be very simple in order to be easy to understand, easy to implement, and the results easy to interpret. - well maintained and documented Acronyms and abbreviations: (not used yet, but might become usefull) NA : Not Applicable TBD : To Be Done Levels of tests: Unit testing: at code level, providing tools/script in order to test classes/functions... Mainly depends on coding team Feature testing: the biggest part, and the largest amount of work. After definition of the features to be tested, establish precise test cases and execute them. Can be partially automated (see in this document) Non regression testing: the ability to check nothing has been broken in the code after important/critical development. Can be covered by feature and unit testing, but a non regression analysis after important/critical development is a great help. Plus after finding some new bugs covered by the test plan, prepare new test itemand ensure it covers properly the new bug. Reference tools: Purpose : define a list of reference tool against which the software should be compared. (especially for issues around import/export / rendering / printing / maybe UI) To be refined. At the moment : take a look at http://www.inkscape.org/cgi-bin/wiki.pl?OtherProjects SVG software Vector software Tests: Build Linux (Debian / Gentoo / Slackware / Mandrake / Fedora / Suse / Others) Windows (98 / 2000 / XP) MacOS (X) BSD (Free / Open) Other Unices (Solaris / Irix) Notice : should be automated (example see : http://public.kitware.com/Dart/HTML/Index.shtml) List of tasks : - establish a list of builders and link it with the architectures they can manage - establish a kind of "test contract" defining the tools to be used (compiler, dependancies, test report tool...) and the periodicity of the tests Import Bitmap Vector Export Bitmap Vector Printing Node editing Shape editing Transformations Color Management Internationalization Main tasks : - list the internationalization that are actively maintained - starting with http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeTerminology, prepare a good dictionnary covering the maintained languages (can be very helpful for the reading of test procedures), plus the vocabulary of the application (messages, menus, etc etc) - establish a list of users with the languages they can check and define a kind of "test contract" UI SVG compliance See in 'specifications of software' plus SVG specifications The main idea is to provide a large repository of reference "SVG files" and "editing sequences". then two types of actions : - open reference files with inkscape, export it as bitmap and compare with a reference bitmap provided by a reference application (Batik ?) - open Inkscape, launch reference editing sequence, export result as bitmap and compare with a reference bitmap provided by a reference application on the same sequence (Inkscape itself for non regression, Batik ?) Previous sequences can be combined in one in order to save time, but then analysis of results can become more complex. Performance "Speed benchmarking" (can be automated) - provide a list of criterias to be tested (time to launch, time to open complex docs, time to save complex docs, speed of scrolling, speed of application of different types of transformations) - provide a benchmark tool - establish a list of users with the architecture on which they use the software, then define a kind of "test contract" defining the tools to be used and the periodicity of the tests Verification of robustness - testing memory leaks (not a specialist of this : I need help) - provide a shaker tool (this tool would launch Inkscape and then start a predefined number of pseudo-random commands -logging each action). The goal is to detect crashes and analyse their conditions with the logs - testing against severe conditions (corrupted files / out of memory / out of disk space ...)

2 1

Re: [Inkscape-devel] BUG and solution in align dialog
by aubi＠...373... 17 Jul '04

17 Jul '04

>> BTW, I finished refactoring the align dialog to use gtkmm and more >>OO code. >> Now I'll add the align nodes features. > >How is it going to look in terms of UI? I think the most intuitive >would be to make it work on selected nodes when the node edit tool >is >active on the active desktop, and on selected objects otherwise. >This >way you need no additional buttons or switches in the dialog. > >Also it would be nice to disable all or some of the buttons >depending >on what is selected. Thus, if no objects or only object is selected, >all align/distribute buttons are grayed out; if several nodes are >selected, "distribute top/bottom/right/left" are disabled because >they >make no sense for sizeless nodes (only distribute centers and >equi-spaced remain). That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor). To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop. >> I also would like to talk about the possibility to use the dialogs >>like in >> gimp2 (drag and dropable notebook tabs, multiple instances of the >>same >> dialog, etc) >> I started a very simple implementation, but I'm not sure you want >>to do that. >> Now I'm used to it, I find it easier to remember keyboard >shortcuts and have >> transient dialogs. No mess with tabs. PLease let me know your >>opinions. >Draggable notebook tabs may be a good idea - it will let one combine >all the tabs used frequently into one dialog and have only that >dialog >open, thus saving space. But it's likely to be rather difficult to >implement, it will very much disrupt our old dialogs code. > Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class. For me the main question is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ? >Multiple instances of the same dialog does not sound like a good >idea >at all. I think it will be just confusing without any advantage. OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one. I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ... ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Inkscape Status July 15, 2004
by Bryce Harrington 17 Jul '04

17 Jul '04

Inkscape 0.39 has been released! It has been amazing to watch everything coming together over the past few weeks. Users have been very attentive to locating, reporting, and following up on wide ranges of bugs across an impressive range of platforms. Meanwhile developers have been grinding away at the bug list; the rate of bug fixing is astounding - it is not unusual for bugs to be fixed the day they're reported. The number of translations that have come in has also been impressive. Statistics Nov 15 May 15 Jun 15 Jul 01 Jul 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 930 845 (68.5%) (92.7%) (93.4%) (93.4%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 43 33 (99.6%) (99.8%) (99.8%) (99.8%) (99.8%) Total SF Page Views * 475,000 616,263 678,767 741,681 Total SF Downloads * 27,400 34,015 36,979 39,359 Total Freshmeat URL Hits 746 * 7,333 7,615 7,946 Total Freshmeat Subscriptions 16 74 87 91 93 Lines of Code in src/: 115,901 189,116 280,263 261,927 264,418 Code lines 147,471 210,119 190,519 192,240 Comment line 16,757 40,620 41,422 41,926 Blank 25,886 34,677 35,134 35,422 Lines of Docs in doc/: 1,135 4,544 15,170 15,201 15,217 Lines of content in website: 1,173 6,008 6,372 6,581 6,784 Size of the Inkscape wiki: 3,700 18,638 17,176 16,600 17,854 Minutes since last ChangeLog mod: 360 * * 28 54 Bugs open/total: 9/15 57/365 63/401 88/452 73/496 Features open/total: 18/18 183/238 210/285 222/307 242/331 Patches open/total: 1/ 6 4/ 83 5/ 88 6/ 91 8/110 CVS Commits (as per inkscape-cvs): 481 3391 5549 6033 6314 Inkscape-devel membership: 49 78 84 87 95 Inkscape-announce membership: 9 43 53 58 60 Inkscape-user membership: 71 76 84 90 Num Translations: Translated: 338 405 Fuzzy: 288 270 Untranslated: 349 325 Total number of PO files: 32 32 Ave Translation Ratio: 34.7% 40.5% * - Statistics unavailable

3 7

HELP WANTED: OSX packager for 0.39
by Bryce Harrington 17 Jul '04

17 Jul '04

Hi all, We have not had Mac OSX packages to provide in the past, but we'd certainly like to! OSX is an important platform for artists, and it would make sense for Inkscape to have a good presence there, as it does on Windows and Linux. Kees and others have verified that it builds and can be run on OSX, so the hardest part is done. The notes are available here: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape What we need is someone who can create a package that other OSX users can easily download and install. This probably doesn't require any coding know-how, but does require someone knowledgeable of fink and in compiling under OSX. If you're interested, please go ahead, and when you've got a working package, announce it here, and we'll add it to the Download area. :-) Bryce

1 0

[Fwd: Autopackage: fantastic, thanks.] (fwd)
by Bryce Harrington 17 Jul '04

17 Jul '04

---------- Forwarded message ---------- Date: Sat, 17 Jul 2004 12:42:28 +0100 From: Mike Hearn <mike@...333...> Reply-To: autopackage-dev@...375... To: autopackage-dev@...375... Subject: [Fwd: Autopackage: fantastic, thanks.] -------- Forwarded Message -------- From: Leland McInnes <leland.mcinnes@...456...> To: mike@...333... Subject: Autopackage: fantatsic, thanks. Date: Sat, 17 Jul 2004 03:01:08 -0400 Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Hi, I've been keeping vague tabs on the autopackage project as it looked promising, but mostly it was still in the "unstable API" stage, so wasn't really much to use to me as an end user. I was looking at the latest inkscape however, and noticed an autopackage install. I figured this was a good chance to actually give it a try. It worked flawlessly and elegantly and did everything I would expect of it. I look forward with great anticipation to the 1.0 version and a wide variety of packages available. This is exactly the sort of things linux package management desperately needs. Thanks for all the great work. Leland McInnes. -- "The bitter apple and the bite in the apple. And the ragged and restless waters" -- The Dry Salvages (Four Quartets), T.S. Eliot --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@...375... For additional commands, e-mail: autopackage-dev-help@...375...

1 0

problems compiling in macosx
by Albert 17 Jul '04

17 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

3 7

One thing to do before a branch
by Bob Jamison 17 Jul '04

17 Jul '04

Whoever does the branch, I request you do one thing just before that. Please run: perl mkfiles.pl and perl mkdep.pl and commit make.* This will hopefully ensure that the tarball will compile under win32. Thanks. Bob

4 4

status?
by bulia byak 17 Jul '04

17 Jul '04

Looks like the freeze is going well, with nothing serious showing up. Is there anything preventing us from making a release, say, tomorrow? Actually, Ted, since you are our Release Technician (right? :) what is the best time for you to cut the release? Arpad, thanks for committing the translations. As for the assert, I think it's not very frequent, but its fix is likely to be too dangerous for so late in the freeze. I will fix it for the next version.

8 9

[Fwd: Re: siggraph?]
by Jon Phillips 17 Jul '04

17 Jul '04

Anyone in the LA area for SIGGRAPH. Here is a form for free exhibits + passes. I'm going to go on MONDAY AUG 9. If anyone is there, then we could do a BOFA on INKSCAPE, or just meetup for some rip-off expensive lunch or supper in rip-off-cost land. Jon > >https://reg.jspargo.com/siggraph04/invitations/general/default.asp > >Guest Password: 1208 > > -- Jon Phillips Graduate Researcher Visual Arts Department PO BOX 948667 LA JOLLA, CA 92037 USA cell.858.361.2811 jon@...235... http://www.rejon.org

4 4

First experiences with 0.39pre4
by Wolfram Quester 17 Jul '04

17 Jul '04

Hi alltogether! Yesterday I prepared an inkscape package for debian unstable from 0.39pre4. Now, always when I start inkscape I get the message "Couldn't find helper" in my terminal window. Using strace doesn't tell me anything: 3911 access("/usr/share/inkscape/extensions/roundhole", F_OK) = 0 3911 access("/usr/bin/perl", F_OK) = 0 3911 access("/usr/share/inkscape/extensions/ill2svg.pl", F_OK) = 0 3911 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 3911 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30274000 3911 write(1, "Couldn\'t find helper\n", 21) = 21 Is this message just supposed to appear after the last extension is initialized or did I something wrong? Additionally yesterday I had to play with bézier curves. It seems that I forgot to close one of these or inkscape could not properly determine which area is enclosed by the curve. The whole canvas turned black and inkscape became inresponsive. To me, it looked like it was filling infinity and it was to busy with that to react to any keystroke or whatever. I had to kill it at least. The output in the terminal was wolfi@...453...:~/simu $ inkscape Couldn't find helper failed to load unicode charmap ** (inkscape:2508): CRITICAL **: file display/curve.cpp: line 578 (void sp_curve_closepath_current(SPCurve*)): assertion `curve->end - curve->substart > 2' failed Private normalization of gradient linearGradient7951 requested Changing object g7308 fill to gradient linearGradient7952 requested ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed ** (inkscape:2508): CRITICAL **: file color.cpp: line 95 (void sp_color_set_rgb_float(SPColor*, float, float, float)): assertion `b >= 0.0' failed I could not reproduce this with simple curves I drew today, so this is merely an information for you. Perhaps it helps. With best regards, Wolfi

9 23

Snapping
by Bryce Harrington 17 Jul '04

17 Jul '04

What is the difference between 'Snap to Grid' and 'Snap Points to Grid'? Bryce

2 5

Re: OSX packaging?
by Kees Cook 16 Jul '04

16 Jul '04

I asked a friend of mine about OSX packaging... I think we have a patch for a dmg, but I don't know what it means. :) ----- Forwarded message ----- Date: Thu, 15 Jul 2004 10:58:41 -0500 Subject: Re: OSX packaging? On Jul 15, 2004, at 08:10, Kees Cook wrote: >Hey, I want to try and get inkscape (inkscape.org) packaged for OSX. I >assume this is only possible via "fink", but I don't know where to >begin. How do I make an OSX package? :) There are two ways, really (maybe three): http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/Fi… 1) True Mac OS X way: drag and drop the .app from a .dmg file to your Application folder (or whereever else you want it) 2) More complicated OS X Way: Installer.app package. see Package Maker.app 3) UNIX way: fink. basically just a debian apt package. http://fink.sourceforge.net/doc/packaging/index.php If you want to target OS X users I would say 1 is the way to go. Otherwise 3. What are your dependencies? ----- End forwarded message ----- -- Kees Cook @outflux.net

5 6

Using imagemagick or graphicmagick as importer
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, I've been playing around about idea to provide support for Image/Graphicsmagick in inkscape. So we could import 88 Vector- and Imageformats used (http://www.graphicsmagick.org/www/formats.html or http://www.imagemagick.org/www/formats.html) but i been wondering should it been done like ill2svg or something deep cutting in inkscape code? Problem is that SVG output of programs isn't so good it should be. So what do you think? is this just a stupid idea? Tuukka ps. ImageMagick provides C++ bindings.. i think graphicmagick does also;)

2 1

Request for Adobe Illustrator files
by Tuukka Pasanen 16 Jul '04

16 Jul '04

Hi, Sorry about cross-posting.. but if anyone got AI files laying around (And have screenshot but it not must) that he/she could send me it/them to test ill2svg.pl. One could do it by Email (straight to me) or send URL to file (if file is bigger than 2M). I promise to use them only for testing ill2svg.pl script.. you can also create such documents if you have Corel Draw or Adobe Illustrator. Thanks, Tuukka

1 0

0.39 Release
by Bryce Harrington 16 Jul '04

16 Jul '04

Bulia has announced and finalized the 0.39 release, and Ted has established the release branch. What this means: * Packagers, please download the tarball and begin making packages * We will put out an announcement within a few days, once we've got some key packages up there. * We are in Release Phase. You can commit to CVS HEAD openly, but try to limit work to bug fixing for a couple days, just in case. * Users, please download and try out the packages as soon as they're ready. Let the packagers know of successful / unsuccessful installs. Congrats everyone! Bryce

1 0

no wimp please
by bulia byak 16 Jul '04

16 Jul '04

0.39 is up on SF. Whoever will be doing the windows package, please do not include gtk-wimp. The reason is that it gives me a lot of warnings about missing MS Sans Serif fonts. All these warnings flood the console window which therefore always jumps to the top and makes the program almost unusable. This is on windows 98. Normal builds without gtk-wimp work OK. I mentioned this on jabber but just want to reiterate. It's a nice thing but needs more testing before we can use it.

1 0

Linux Format Magazine has an article on Inkscape
by Alan Horkan 16 Jul '04

16 Jul '04

Linux Format Magazine has an article on Inkscape http://www.linuxformat.co.uk/ It has a strange lead in, I think they must have a regular section for the Gimp or something because of the way it is presented in relation to the Gimp. I only very quickly skim read the article (I'm not currently gainfully employed and have only pennies to my name) but it seemed favourable overall. I noted in particular that he found the user interface to be friendly. He mentions the Boolean operators and quotes one of the developers as having said that in the last while 'inkscape has improved 100%' (or suchlike). The article was written by Michael J. Hammel who appears to also be the author of "Essential Gimp for Web Professionals" and owner of the site http://graphics-muse.com/ and this page http://freshmeat.net/~mjhammel/ (his connections to the Gimp would explain the odd context of the Inkscape article). Perhaps someone might contact him and encourage him to write more about Inkscape. (Recommend some topics and I might try my hand at writing an article about Inkscape if I had a place to start). Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

3 4