- Inkscape Devel - Inkscape Mailman

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

18 Feb '05

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

2 5

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

18 Feb '05

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

1 0

Saving as pov
by Lucas Vieites 18 Feb '05

18 Feb '05

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

1 0

resource leaks on Windows
by bulia byak 18 Feb '05

18 Feb '05

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

2 1

doxygen updates
by Kees Cook 18 Feb '05

18 Feb '05

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

1 0

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

17 Feb '05

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

2 1

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

17 Feb '05

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

2 1

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

16 Feb '05

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

3 2

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

16 Feb '05

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

2 1

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

16 Feb '05

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

1 0

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

16 Feb '05

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

4 4

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

16 Feb '05

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

4 4

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

16 Feb '05

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

2 4

Inkscape::NSApplication ?
by MenTaLguY 16 Feb '05

16 Feb '05

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

2 2

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

16 Feb '05

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

1 0

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

16 Feb '05

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

4 7

Urgency and spirit
by Felix Rabe 15 Feb '05

15 Feb '05

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

3 2

Selection in text editing
by Aewyn 15 Feb '05

15 Feb '05

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

6 19

Comment to bug 1077213
by Praktikant 14 Feb '05

14 Feb '05

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

2 1

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

14 Feb '05

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

3 2

Update on Inkscape presentations
by Bryce Harrington 14 Feb '05

14 Feb '05

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

2 1

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

13 Feb '05

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

1 0

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

13 Feb '05

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

2 1

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

13 Feb '05

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

5 12

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

13 Feb '05

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

2 1