- Inkscape Devel - Inkscape Mailman

spammer question
by Jon Phillips 06 Aug '04

06 Aug '04

We have a serious problem with spammers/spambots on our usemodwiki system. Do you all have any recommendation or enhancements in developer versions. We try to run an open ship and do not want to require user/pass for editing the wiki. Please see: http://inkscape.org/cgi-bin/wiki.pl Jon -- Jon Phillips USA.PH.858.361.2811 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

[Fwd: Re: spammer question]
by Jon Phillips 06 Aug '04

06 Aug '04

Response from usemodwiki developers... Jon -----Forwarded Message----- > From: Clifford Adams <caadams@...503...> > To: Jon Phillips <jon@...235...> > Subject: Re: spammer question > Date: Fri, 06 Aug 2004 17:52:31 -0400 > > At 12:23 PM 8/6/2004, you wrote: > >We have a serious problem with spammers/spambots on our usemodwiki > >system. Do you all have any recommendation or enhancements in developer > >versions. We try to run an open ship and do not want to require > >user/pass for editing the wiki. > > I do have some recommendations that I recently sent to another wiki > admin. I don't know if you'll want to try the first suggestion (involving > editor passwords for some networks), but the second one has been very > helpful in discouraging spam on the usemod.com sites. Let me know if you > have any questions. > > --Cliff > > [excerpt from previous email:] > > [...] I plan to have some anti-spam features in 1.1. (I > don't know when that will be released, however.) In the meantime, here > are a couple suggestions: > > 1. Use the ban list to block IPs or networks. One approach is to use > very wide blocks, and give out "editor" passwords for exceptions. (The > editor password bypasses the bans.) > > For example, the UseModWiki site blocks posting from the aol.com web-proxy > sites. The Meatball wiki blocks a Chinese class A network (not my > decision). If needed, you could even make the site read-only and email > out editor passwords to contributors. > > 2. If you get persistent linkspam to particular sites, you might want to > add code like this to the DoPost subroutine (at around line 3890, just > before the comment "Lock before getting..."): > > # XXX CAA hack: block some spammers > if (($string =~ m|http\://.+webrank\.cn|) || > ($string =~ m|http\://.+google123\.net|) || > ($string =~ m|http\://.+ccnp130\.com|) || > ($string =~ m|http\://.+\.s5\.com|) || > ($string =~ m|http\://.+\.itgo\.com|) || > ($string =~ m|http\://.+\.tejia\.com\.cn|) || > ($string =~ m|http\://.+shemale|) || > ($string =~ m|http\://.+fueling\-dispenser\.com|)) { > &ReportError("Internal Error."); > return; > } > > # Lock before getting old page to prevent races > > This code (from my live wiki) rejects any submitted text that contains > these bad links. When spammers submit lots of links I don't bother > entering all of them into the code--just a few chosen at random. > > For 1.1 I plan to add a feature to read a "bantext" file, along with web > editing like the current banned list. > > Let me know if you need any help with implementing these suggestions. > > > I was surprised that a search for "spam" on the > > UseModWiki site revealed nothing interesting. > > Most of the discussion I've seen is on the Meatball wiki site, > specifically at: > > http://www.usemod.com/cgi-bin/mb.pl?WikiSpam > > ...which links to other discussions. > > [end of excerpt] -- Jon Phillips USA.PH.858.361.2811 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

NArtBpath misdesigned.
by David Turner 06 Aug '04

06 Aug '04

I'm rewriting some of the marker code, because it doesn't conform in any way, shape, or form to the spec. Along the way, I've found some deficiencies in the internals of Inkscape (as well as some in the SVG spec). NArtBPath does not properly handle closed subpaths. In SVG, a curve is divided into subpaths, which are either open or closed. A subpath ends with either 'z', 'm', 'M', or the end of the string. A closed subpath is one which ends with a 'z'. NArtBPath can represent this for non-final subpaths with NR_MOVETO (as opposed to NR_MOVETO_OPEN). However, for the final subpath, there can be no final MOVE_TO command (by definition). I believe that in fact, non-final closed subpaths are represented differently: they have a NR_LINETO to the final point, then a NR_MOVETO. This is reflected in the SVG: select the bezier tool. Click three points, then the first point, forming a triangle. This should be represented as M...L...L..z, but in fact is represented as M...L...L...L...z (extra line). Note the deficiency in SVG -- you can't have a curve which closes a subpath (you have to do a curve followed by a z, which should (but does not in Inkscape) generate an extra marker. Inkscape also doesn't respect the 'z' in rendering. More accurately, the lack of 'z'. If you have draw a triangle as above, then edit in the xml editor to remove the 'z', the rendering doesn't change. Inkscape treats the lines as joined because they have the same end point (you may need to change the line-join to see this in action). <whine> Note that Inkscape currently incorrectly renders marker-start on the start of any subpath, rather than only on the start of the path as a whole. This is entirely logical, but does not match the spec. It's my opinion that the spec is dead wrong here, and evidently somebody else agrees with me -- I just saw a message on www-svg@...157... proposing new markers for the beginning and ends of subpaths. I'll "fix" this too, to match the spec, even though the spec is wrong. I may also add custom subpath-start and subpath-end markers. </whine> My suggestion is that we remove NR_MOVETO_OPEN, and change the semantics of NR_MOVETO to simply mean moveto. We should add NR_CLOSEPATH, which indicates a 'closepath' command, and is rendered as per lineto, but with attention to the join. I don't yet very feel confident with the codebase, so I'm not sure I can do this on my own. I would rather discuss it here first. Tonight, I'm going to finish get the guts of marker directionality to match the spec as much as is possible with the current code. -- -David "Novalis" Turner Stalk Me: 617 441 0668 "PLAN WHILE YOU CAN, LITTLE THING OF EARTH. WE ARE NOT YET CAST DOWN." - Mary Gentle, _Ash: A Secret History_

3 2

Vacuum patch (2)
by David Turner 06 Aug '04

06 Aug '04

Hi! I would like to introduce myself to the list and provide a patch for review. I'm novalis_dt on Sourceforge. I know Bryce from when he worked on the Worldforge project. I have recently started using Inkscape -- I'm not much of an artist, but I redid the front page of my website with Inkscape. I've also done a couple of diagrams for work (I do licensing for the Free Software Foundation). I've submitted a couple of other minor patches, and now have CVS commit access. This patch provides a new command: "Vacuum unused defs." SVG files can accumulate cruft -- gradients, markers, etc, which aren't in use. I've chosen to make this command manual, because sometimes, you'll want to keep this cruft for later usage. But if you want smaller SVG files, for web usage (or secrecy reasons), you might try this feature. When I wrote the first version of this patch, I didn't understand the SPObject tree. I think I do now. I'm somewhat baffled that there's no sp_object_get_child_by_tagName function already -- am I just missing it? If not, it probably belongs in sp-object.cpp, but I didn't want to put it there prematurely. If I hear no objections, I'll commit it in a few days. -- -David "Novalis" Turner Stalk Me: 617 441 0668 "Once, there were three lizards, and they were all named Pants. " -Sho Kuwamoto (seen on talk.bizarre)

6 10

optimization
by bulia byak 06 Aug '04

06 Aug '04

I found that Inkscape runs 6% to 7% faster if I replace in nr-point.h Coord operator[](unsigned i) const throw(std::out_of_range) { if ( i > Y ) { throw std::out_of_range("index out of range"); } return _pt[i]; } with inline Coord operator[](unsigned i) const { return _pt[i]; } and the same for non-const version. I think it's safe to get rid of the range check because the indices are never calculated and are extremely unlikely to go off limits. So if nobody objects I will commit this change.

5 10

[Fwd: [ANN] Sketsa (SVG Graphics Editor) 2.0 released]
by Jon Phillips 06 Aug '04

06 Aug '04

-----Forwarded Message----- > From: Tonny Kohar <tonny@...498...> > To: www-svg@...157... > Subject: [ANN] Sketsa (SVG Graphics Editor) 2.0 released > Date: Tue, 03 Aug 2004 21:41:22 +0700 > > > We proudly released Sketsa SVG Graphics Editor 2.0. Sketsa is a cross > platform vector drawing application based on SVG. It features various > tools for optimizing content creation, giving designers unsurpassed > support for creativity. These tools include property palette, source > editor, resources editor, SVG specific shape tools, transformation > tools, and additional illustration tools. Sketsa uses SVG as a native > file format. > > Features: > - SVG native file format > - Property palette > - DOM Editor > - Source Editor > - Resource Editor: gradient and filter > - SVG specific shape tools: rect, ellipse, line, polyline, polygon > - Additional illustration tools: Pencil tool for freeform shape and Pen > tool for curve shape > - Transformation tool: rotate, skew, scale, and translate > - Basic Text Tool > - Export or rasterize to JPEG and PNG > - Written entirely in Java > > What's new > - UI changed (docked panel, menu rearrange) > - Speed Improvement > - Canvas Ruler > - Text Style property > - Toolbox transform improvement (support parent transform) > - Pencil / Freehand tool improvement > - Various bug fixes > > The latest news about Sketsa can be found on > http://www.kiyut.com/products/sketsa/index.html -- Jon Phillips USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

Inkscape BOF @ Siggraph LOS ANGELES - MON, AUG 9, 4-5 PM
by Jon Phillips 06 Aug '04

06 Aug '04

*PLEASE FORWARD* Inkscape: An Open Source Vector Graphics (SVG) Editor Overview Birds of a Feather Meeting in Co-operation with Siggraph 04 at the Los Angeles Convention Center http://www.siggraph.org/s2004/conference/birds/index.php?pageID=conference Monday, 9 August 4 - 5 pm Holiday Inn City Center Santa Monica Room Jon Phillips + Jon Cruz ### Inkscape: Draw Freely. (http://www.inkscape.org/) Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Inkscape's main motivation is to provide a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm, emphasizing a lightweight core with powerful features added through an extension mechanism, and establishment of a friendly, open, community-oriented development processes. The specific emphasis of this talk will be for intermingling between attendees and to allow for suggestions and discussions about where Inkscape is heading...draw freely! -- Jon Phillips USA.PH.858.361.2811 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu/) Scale Journal (http://scale.ucsd.edu/)

1 0

Inkscape BOF @ Siggraph LOS ANGELES - MON, AUG 9, 4-5 PM
by Jon Phillips 06 Aug '04

06 Aug '04

*PLEASE FORWARD* Inkscape: An Open Source Vector Graphics (SVG) Editor Overview Birds of a Feather Meeting in Co-operation with Siggraph 04 at the Los Angeles Convention Center http://www.siggraph.org/s2004/conference/birds/index.php?pageID=conference Monday, 9 August 4 - 5 pm Holiday Inn City Center Santa Monica Room Jon Phillips + Jon Cruz ### Inkscape: Draw Freely. (http://www.inkscape.org/) Inkscape is an open source SVG editor with capabilities similar to Illustrator, CorelDraw, Visio, etc. Supported SVG features include basic shapes, paths, text, alpha blending, transforms, gradients, node editing, svg-to-png export, grouping, and more. Inkscape's main motivation is to provide a fully XML, SVG, and CSS2 compliant SVG drawing tool. Additional planned work includes conversion of the codebase from C/Gtk to C++/Gtkmm, emphasizing a lightweight core with powerful features added through an extension mechanism, and establishment of a friendly, open, community-oriented development processes. The specific emphasis of this talk will be for intermingling between attendees and to allow for suggestions and discussions about where Inkscape is heading...draw freely! -- Jon Phillips USA.PH.858.361.2811 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

Glib::ustring
by Bob Jamison 05 Aug '04

05 Aug '04

With my short education into Gtkmm recently, I have become acquainted with the Glib::ustring class. It is a clone of the std::string class, with the addition of supporting unicode in utf8 format. This sounds like it might be a nice replacement for our many g_blah_blah_utf8() calls, and also a nice storage for our internal strings. Anyone have any thoughts? Maybe Jon could look at it to see if it is sufficient/valid. Just wondering.... (I'm sitting in a boring meeting right now ;-) Bob

3 2

Re: spalah + inkscape?
by bulia byak 04 Aug '04

04 Aug '04

I'm cc'ing my reply to inkscape-devel, where more people will be able to comment. On Sun, 25 Jul 2004 20:30:52 +0300, Anatoly Podlesnuk <beerubeer@...466...> wrote: > Hi > > It's good idea to join spalah and inkscape. > > There is some questions. > > 1. I'm not use in spalah "items tree" of SVG nodes from sodipodi. Spalah > items tree is much simple. So I will need some help with inkscape items > tree. We haven't yet departed too far from Sodipodi's system of SPObjects tree and repr tree that are synced periodically, though we did a lot of incremental changes to it (mostly in the direction C++fying it). I don't think anything simpler than that will actually work for interactive SVG editing. Of course we will be glad to help you with it. > 2. Spalah uses ming library (ming.sourceforge.net) for flash generation, > so inkscape will require this library. No problem. SWF export is a good thing to have, even if for static SVGs at first. > 3. What is role spalah code in inkscape? It will a part of ExportDialog > or inkscape will able to add animation to SVG objects? As I know > inkscape does not support some SVG nodes that responses for animation. Our goal is to be a complete SVG editor, and that includes animation. So we'll need to add support for all the corresponding elements and attributes. As for the UI, what I had in mind is a timeline control selecting one of the frames for editing, plus a separate preview window (based on inkview?) with actual animation. Of course, at this stage all this requires lots of thinking, planning, and experimenting. > 4. What about release planning, code formatting, > classes/functions/variables names? I guess the main development principle is that CVS must always remain compilable and workable, without bad regressions. Releases are done when there's enough stuff for a new release, usually every 2 to 3 months. There's a period of code freeze and bug hunt before a release, but at other times you're free to work on your stuff. For coding style, we have a few guidelines here: http://inkscape.sourceforge.net/doc/coding_style.php Let me know what you think.

5 9

new open dialog
by bulia byak 04 Aug '04

04 Aug '04

First off, I wanted to say thank you to Bob for this work. The preview on open is fabulous! It gives a whole new perspective on my files. A very important addition. Still there are problems. I know some of them may not be fixable due to GTK limitations, but still. 1 The dialog is modal but not transient. It's a very dangerous combination: it sinks under your document and you can't understand why the document is unresponsive. Please make it transient as it was before. 2 The dialog opens in some unpredictable place on the screen. Before, it opened centered over the document window. Can we restore that? (Maybe it's a consequence of its not being transient.) 3 BUG: when I press Ctrl+O for the first time, there are no files listed at all in the directory where it opens, only subdirectories. If I go e.g. to the parent dir and then back, the files appear. 4 After some thinking I'm convinced that (as suggested here) we must replace the "Autodetect" with two new options, "All images" and "All files". That makes much more sense and is more consistent with typical Windows/Mac programs. Both these options would do autodetect and differ in filtering the list: no filtering for "All files" and showing only Inkscape-supported images for "All images". The bad thing about "Autodetect" is that it speaks about what the program does, not about what the user needs. Autodetect is not something I ever want to be off; it must always work behind the scenes. What I want to control is what files are shown and what not, and this is what this menu must affect. 5 The menu should be reordered more logically so that the most frequently used options are at the top: All images <-- default All files SVG Compressed SVG ---------- (separator) AI EPS PS Dia Sketch WMF text rest of bitmap formats... 6 Also it would be nice to group the same formats with different extensions as proposed here: https://sourceforge.net/tracker/index.php?func=detail&aid=990674&group_id=9… 7 If I want to go e.g. to /home/me/inkscape and browse files here, I go to the filename field, type "/home/me/inkscape" and press Enter. Nothing happens. In other programs (and I believe in Inkscape with the old dialog) this caused the dialog to switch to that dir. 8 I get these warnings whenever I open it for the first time: (inkscape:7505): Gtk-WARNING **: Could not find the icon 'gnome-fs-home'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://freedesktop.org/Software/icon-theme/releases (inkscape:7505): Gtk-CRITICAL **: file gtksettings.c: line 447 (gtk_settings_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed (inkscape:7505): GLib-GObject-WARNING **: invalid (NULL) pointer instance (inkscape:7505): GLib-GObject-CRITICAL **: file gsignal.c: line 1726 (g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed I installed http://freedesktop.org/Software/icon-theme/releases/hicolor-icon-theme-0.5.… but this did not help. Any ideas? Preview: 9 There's no way to turn the previews off. 10 The open/close dance of the preview pane as you go through image/non-image files is a bit disconcerting. Can't we always have the preview widget on (that is, unless you turn it off, see 8), even if inactive for the current file, with the same unchanging size? 11 Bob, you mentioned that you did preview for the bitmap files as well, but this does not work for me, only SVGs. That's it for now, perhaps I'll find more when I test it more thoroughly.

5 13

Adobe Illustrator 7/10, Photoshop CS and Postscript (probably eps)
by Tuukka Pasanen 04 Aug '04

04 Aug '04

hi, A long story short. AI7 files aren't in PDF format and AI10 uses PDF 1.4 as native saving format. I Have also heared that Photoshop CS uses PDF 1.4 as saving format. So i looked in pstoedit program and finded out (Author pointed out) there is GPL svg output plugin. So it would be neat to have this option in inkscape but is it too much to ask for http://www.gnu.org/software/plotutils/ and pstoedit be installed to have this input?? There is also one problem in SVG because it doesn't put fill:none in style inkscape just fills everything in black:P.. I still look how good plot-svg output is but seems good enouhg to me.. Then i just have to think how to find AI7 and AI10 in ill2svg.pl;) So should we use it or not? In Gnu/Linux and *BSD (*nix) world it's easy to install but windoze is biggest problem.. Tuukka.

3 4

convention for XML names
by MenTaLguY 04 Aug '04

04 Aug '04

Although it's not crucial, could we settle on using XML names that adhere to a specific convention? I'm a little worried that having: inkscape:one-thing inkscape:another_thing inkscape:YetAnotherThing as element/attribute names in the same SVG file, while permissible, looks unprofessional. I personally favor using lowercase words separated with dashes (-). -mental

4 3

[Fwd: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU]
by Jon Phillips 03 Aug '04

03 Aug '04

bulia, et al. fyi...contact this person directly to encourage moving package to unstable and then stable fink... Jon -----Forwarded Message----- > From: Martin Costabel <costabel@...26...> > To: Jon Phillips <jon@...235...> > Cc: fink-gnome-core(a)lists.sourceforge.net > Subject: Re: [gnome-core] gtkmm 2.4 + inkscape + YOU > Date: Tue, 03 Aug 2004 12:20:08 +0200 > > Jon Phillips wrote: > [] > > I'm sending this to encourage the move up to gtkmm2 project's current > > stable version 2.4. > > There is a gtkmm24.info in > fink/experimental/gnome/2.6/main/finkinfo/gnome/ on CVS. Have you tried > it? It has been there since 2004/05/16. -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - flowRegion makes flow-go.svg render "correctly" Actually from my reading of the spec, the old rendering was correct: each flowregion filled from top to bottom, even if it contains multiple shapes. > - fixed the lost word problem. note that you need to > put spaces at the beginning of a flowSpan (or the end > of the previous) otherwise the words at both ends will > be glued together Yes, that's reasonable > - a preliminary convert_to_text() verb is in sp-flowtext Excellent, I put it on Shift+Alt+W as "Unflow text", with the Alt+W reserved for "Flow text" (convert text + shape into a flowed text). There were a few problems: - compilation errors on char conversions again - fixed - the text style only worked if set on flowRoot, not flowDiv - fixed by adding SP_STYLE_FLAG_ALWAYS to sp_style_write_string (line 787), so that it writes the entire style of each chunk, including inherited style - space after flowSpan was lost - partially fixed by adding xml:space="preserve" to the created text, but the start positions of spans are still sometimes off (convert the attached one and watch the words "as well as" and "kinsoku" - they jump off a bit) Plus a few other small changes, so please take the files from CVS if you want to change something. I also thought about the best way to create flowed texts. I think using clones is indeed the best method, as it will let us avoid adding flowtext parsing code to a million places. So when you select a shape and a text, here's what happens: - the shape is cloned, clone placed exactly over the original - the clone gets inkscape:use-move="parallel" and inkscape:use-delete="unlink" attribs to ensure these behaviors regardless of user prefs (sp-use support required, but it's simple to add) - tspans with sodipodi:role="line" are merged together, separated by spaces - an empty tspan with sodipodi:role="line" (i.e. empty line) is converted into <flowLine/> - the flowRoot is constructed from the clone and the text thus prepared; original text is deleted The original shape thus remains and is editable as usual, and the text shape will be updated via the clone. This means the paths in "foreign" (non-Inkscape) flowed texts that do not use clones will not be editable at all, but this is OK (at least for now). This approach has the advantage of relative simplicity, and two more commands can be easily added based on the same mechanism - "Flow around" (adds exclusion shape to an existing flowed text) and "Chain flow" (adds a new region to an existing flowed text), with all these shapes remaining editable (i.e. only their clones are added into the flowtext).

2 4

Re: flowtext
by bulia byak 03 Aug '04

03 Aug '04

> - reintroduced the *_update() functions in > sp-flowdiv.cpp; apparently they're needed to have > flowRoot reflow when text is edited > - print uses the text-to-path method, that is you can > print any font in flowRoot > - better convert_to_text(), including partial dx/dy > support (need to figure a way to get the sum of the dy > shifts at the end of a tspan) Thanks, committed. The jumping flowspans bug on convert-to-text seem to be fixed. Please use the version from CVS! I now had to re-type several small fixes I had in sp-flowtext (such as _() for description). What remains to be done: - word-spacing CSS property must be supported as well as letter-spacing. This needs to be added to style.cpp and then to sp-text. - justification must be achieved, first, by squeezing/stretching spaces, and only if this is not possible, by modifying letterspacing. To this end, inkscape:layoutOptions must support 4 parameters: squeezability of space; stretchability of space; squeezability of letterspacing; stretchability of letterspacing (all four are in % relative to the normal value). Some sensible defaults can be found by playing with various texts.

1 0

GNOME HIG
by Lucas Vieites 03 Aug '04

03 Aug '04

Hi all, I just read about the new release of the GNOME HIG (Human interface guidelines) 2 and suddenly I asked myself if Inkscape was taking these into consideration. I browsed the mailing list a bit and found some postings mentioning them. Thinking a bit about the future and the possibility of Inkscape becoming part of GNOME, or even if this is not on the roadmap, I think these guidelines are a "good thing". So, are the developers using these guidelines as they design the user interface? What do you think about them? Greetings, -- Lucas Vieites Fariña Asix Informática <info@...212...> http://www.asixinformatica.com/ Tel/Fax: +34 986 54 26 98

8 13

Re: [Inkscape-user] Re: Crash on startup
by MenTaLguY 03 Aug '04

03 Aug '04

Sorry for taking so long to get back to you; emails about compilation problems will probably get answered quicker on the development mailing list... On Thu, 2004-07-22 at 16:05, Florent wrote: > But maybe, the problem come from the new libs version ? > Is there anyone who can run the last CVS on a Linux ? Yes, I've been running it since I did the library conversion. > And what is his lib versions ? gtk+-2.0 = 2.4.3 gobject-2.0 = 2.4.2 gmodule-2.0 = 2.4.2 glib-2.0 = 2.4.2 pango = 1.4.0 gtkmm-2.4 = 2.4.4 gdkmm-2.4 = 2.4.4 glibmm-2.4 = 2.4.3 pangomm-1.4 = 2.4.4 > I don't know if it can help but when I run the "ddd inkscape", it gives me : > > Program received signal SIGSEGV, Segmentation fault. > SPDesktop::_layer_hierarchy_changed(SPObject*, SPObject*, SPDesktop*) > (top=0x84023d0, bottom=0x84023d0, desktop=0x86bc208) at stl_list.h:397 > /usr/include/c++/3.2.3/bits/stl_list.h:397:10573:beg:0x815f4c4 void SPDesktop::_layer_hierarchy_changed(SPObject *top, SPObject *bottom, SPDesktop *desktop) { desktop->_layer_changed_signal.emit(bottom); } That place for the crash looks a little strange to me. Could you try compiling without optimization and see if it yields the same backtrace (and give me some more of the actual backtrace as well..). The only reason I can think of that it would crash here is if SPDesktop::_layer_changed_signal were not initialized properly for some reason. -mental

2 7

[Fwd: Fwd: mozilla svg meeting log 26.July 2004]
by Jon Phillips 03 Aug '04

03 Aug '04

Sorry for the long email, but this will be of interest to several of you about Mozilla + SVG involvments. This is from the Mozilla SVG team meeting log. -----Forwarded Message----- > From: jon phillips <phillipsjd@...400...> > To: jon@...235... > Subject: Fwd: mozilla svg meeting log 26.July 2004 > Date: Sun, 01 Aug 2004 00:36:09 -0700 > > ---------- Forwarded message ---------- > From: Alex Fritze <alex@...488...> > Date: Sun, 01 Aug 2004 08:34:18 +0100 > Subject: mozilla svg meeting log 26.July 2004 > To: phillipsjd@...400... > > Jul 26 18:39:50 <afri> anyway, shall we start with item 1) "Criteria > for switching on"? > Jul 26 18:39:55 <jwatt> is there any way to search for bugs that have > patches that modify a given file? > Jul 26 18:40:06 <jwatt> oops, never mind, later > Jul 26 18:40:17 <Scooter> 1 seems like a good beginning > Jul 26 18:40:19 <afri> Anybody got any thoughts? > Jul 26 18:40:36 <jwatt> don't we really need a brendan or someone > similar here for that? > Jul 26 18:40:42 <afri> tor: you had some contact with m.org about this? > Jul 26 18:40:45 <jwatt> since they will have a major say in that? > Jul 26 18:41:09 <tor> afri: just the normal moz2 meetings > Jul 26 18:41:51 <Scooter> Well, lets start with which profile we are > shooting for: Tiny or Basic? > Jul 26 18:42:01 <tor> turning it on will depend on the feature set > and size > Jul 26 18:42:11 <tor> 1.2 doesn't have basic, fwiw > Jul 26 18:42:11 <jwatt> or should we do Tiny > Basic > Full? > Jul 26 18:42:23 <tor> (not that we should be shooting for 1.2) > Jul 26 18:42:56 <Scooter> Agreed -- I'm a little uncertain about > 1.2. There seems to be a lot of debate surrounding it. > Jul 26 18:43:02 <afri> do you reckon that feature set is important? > Isn't stability and footprint the issue? > Jul 26 18:43:11 <tor> is anyone interested in working on animation or > svg fonts, which are a couple of the big points we're short of 1.1 tiny? > Jul 26 18:43:30 <tor> stability is definitely important > Jul 26 18:44:01 <tor> we need to be featureful enough so that people > can start do interesting things > Jul 26 18:44:05 <jwatt> I'd be interested in animation in the long > run, but feel I'm still finding my feet > Jul 26 18:44:28 <afri> who do we need to press for criteria? i guess > they are being decided by brendan et al? > Jul 26 18:44:52 <jwatt> yeah, an email to drivers would be a good idea > Jul 26 18:44:59 <tor> brendan was floating the idea of turning on svg > for 1.8, but that causes problems with platform prereqs > Jul 26 18:45:03 <jwatt> or should we /invite some folk now? > Jul 26 18:45:14 <tor> mail to drivers is likely not to get anywhere > Jul 26 18:45:22 <jwatt> oh > Jul 26 18:45:51 <Scooter> OK, so it sounds like there are some > platform issues that need to be on the list -- what are they? > Jul 26 18:46:14 <tor> requiring gdi+ on windows > Jul 26 18:46:27 <jwatt> as in for the installer? > Jul 26 18:46:30 <tor> (unless maybe we can try dynamically loading it?) > Jul 26 18:46:49 <jwatt> I was working on getting the installer script > to do the right thing for that > Jul 26 18:47:05 <Scooter> So, we have requirement #1 -- we need to > deal with gdi+ on windows, right? > Jul 26 18:47:11 <afri> IANAL, but i think technically we are allowed > to redist gdiplus.dll for older windows > Jul 26 18:47:32 <tor> we can't ship libart bits under trilicense > Jul 26 18:47:35 <jwatt> for win me, 98, nt and 2000 > Jul 26 18:47:44 <jwatt> all others aren't allowed > Jul 26 18:47:57 <afri> but we could use cairo for linux, right? > Jul 26 18:48:23 <tor> yes, but we'd have to link it in statically > given that they're still changing the api > Jul 26 18:48:29 <afri> ah > Jul 26 18:48:54 <afri> i guess the other problem is the mac > Jul 26 18:49:11 <Scooter> Perhaps we should focus on listing the > issues and postpone trying to solve them? > Jul 26 18:49:56 <afri> so is it fair to say then that the real first > hurdle for getting svg switched on is sorting out a backend on each > platform? > Jul 26 18:50:04 <tor> how about we ask the question another way - > ignoring distribution issues, would we be happy subjecting users to our > svg at this point? > Jul 26 18:51:00 <afri> i guess that comes down to stability... > Jul 26 18:51:04 <Scooter> I would really like to see us get closer to > *at least* Tiny before we roll this out. > Jul 26 18:51:31 <Scooter> Then we can focus on stability. Things are > clearly still changing pretty rapidly. > Jul 26 18:51:32 <afri> i think the current feature set looks pretty > ok for users > Jul 26 18:52:14 <tor> once gradients are in things are looking good > Jul 26 18:52:16 <Scooter> Even without animation and SVG Fonts? > Jul 26 18:52:21 <tor> <use> would be nice > Jul 26 18:52:45 <jwatt> yeah, gradients and use I think would be > necessary > Jul 26 18:53:16 <afri> yeah, gradients & <use> would be nice. > animation i think will take quite a long while and svg is pretty useful > even without it > Jul 26 18:53:35 <Scooter> Fair enough -- what about SVG Fonts? > Jul 26 18:54:25 <afri> hmm, it sounds tricky getting it right for > several backends... > Jul 26 18:55:03 <afri> do you think without fonts, SVG is not really > worth much to the end user? > Jul 26 18:55:45 <Scooter> Not at all -- I'm just sort of playing > devil's advocate here. I'm happy to see it turned on without that. > Jul 26 18:55:54 <tor> I think svg fonts were probably added to tiny > for platforms that didn't have native scalable/tranformable fonts > Jul 26 18:55:54 <Scooter> What about <switch>? > Jul 26 18:56:26 <afri> well we have your patch for that, so i guess > it will be going in soon > Jul 26 18:57:02 <Scooter> OK, so what we have is: Stability, Platform > issues, <use>, Gradients, and <switch>, right? > Jul 26 18:57:37 <afri> ...of which platform issues are probably the > most difficult > Jul 26 18:57:51 <afri> i don't have a clue how to go about this > Jul 26 18:58:08 <Scooter> Which this? The requirements list or the > platform issues? > Jul 26 18:58:10 <afri> will cairo work on windows/mac? > Jul 26 18:58:25 <afri> Scooter: the platform issues > Jul 26 18:58:52 <afri> can we even link to it statically on linux? > Jul 26 18:59:04 <afri> wouldn't that mean it needs to be checked into > the tree? > Jul 26 18:59:29 <tor> the software path of cairo should work on mac > Jul 26 18:59:51 <tor> if we're allowed to redistribute gdi+ then that > might not be a problem > Jul 26 19:00:06 <afri> fair enough > Jul 26 19:00:20 <afri> so let's assume windows is sorted for now... > Jul 26 19:00:30 <jwatt> as I said, we can only redistribute > gdiplus.dll on WinME, Win98, WinNT and Win2k > Jul 26 19:00:34 <afri> how do we go about linux/mac then? > Jul 26 19:00:43 <tor> jwatt: what else is there? > Jul 26 19:00:53 <afri> tor: XP > Jul 26 19:00:54 <jwatt> nothing that we need to cater for > Jul 26 19:00:57 <jwatt> XP has it > Jul 26 19:01:04 <tor> there's a quartz wip backend > Jul 26 19:01:18 <afri> wip? > Jul 26 19:01:27 <tor> work in progress > Jul 26 19:01:32 <afri> ah > Jul 26 19:01:57 <afri> i think we'd need to find a developer for that > Jul 26 19:02:06 * Lightkey cracks his wip > Jul 26 19:02:12 <afri> it seems to have stalled > Jul 26 19:02:42 <afri> Lightkey: you are a mac developer? > Jul 26 19:02:54 <Lightkey> I am the lowest > Jul 26 19:03:02 <Lightkey> internet reporter :D > Jul 26 19:03:14 <tor> we have a mac here > Jul 26 19:03:18 <Lightkey> no, I'm just a user > Jul 26 19:04:14 <afri> so if we have as a working assumption that > someone will fix the quartz backend, that still leaves linux... > Jul 26 19:04:42 <Scooter> And the issue with Linux is the license > restrictions on libart? > Jul 26 19:04:52 <afri> with libart not being an option, how would we > proceed with cairo? > Jul 26 19:04:57 <tor> statically linking cairo is just a build problem > Jul 26 19:05:10 <afri> what about the cairo license? > Jul 26 19:05:12 <tor> though cairo does feel slower than libart > Jul 26 19:05:28 <Lightkey> changing croczillas licenses to the one > libart uses? *scnr* > Jul 26 19:05:46 <tor> still MIT style, though they keep threatening > to change to LGPL (which would sink the static link solution) > Jul 26 19:06:35 <afri> is MIT compat with tri-license? > Jul 26 19:06:43 <tor> yes > Jul 26 19:07:06 <afri> so we could check this into the tree then? > Jul 26 19:07:10 <Lightkey> MIT is like FreeBSD > Jul 26 19:08:37 <tor> if it gets to that point, yes > Jul 26 19:08:51 <afri> to which point? > Jul 26 19:09:04 <afri> LGPL relicensing> > Jul 26 19:09:07 <afri> ? > Jul 26 19:09:15 <tor> where we're going to take the static link approach > Jul 26 19:09:23 <afri> ah yeah, ok > Jul 26 19:09:34 <afri> well, is there any other way? > Jul 26 19:09:44 <lsmith> afri: are those performance issues solved > that matthias found afri? > Jul 26 19:09:51 <lsmith> (iirc he send you a test case) > Jul 26 19:09:54 <tor> not that I can think of offhand > Jul 26 19:10:12 <lsmith> those might also be a little showstopper > Jul 26 19:10:26 <afri> lsmith: no, we'll get to that later > Jul 26 19:10:46 * lsmith nods > Jul 26 19:10:49 <afri> so shall we run this past brendan et al then? > Jul 26 19:11:23 <Scooter> Makes sense to me. > Jul 26 19:11:35 <jwatt> yeah, good to keep him informed if nothing else > Jul 26 19:11:50 <jwatt> But do we really have enough contributors to > deal with the development cycle that would be imposed on us if SVG was > turned on by default? > Jul 26 19:12:14 <tor> what development cycle? > Jul 26 19:12:43 <jwatt> having to stabalise, etc a1, a2, b, rc, > milestone > Jul 26 19:13:27 <jwatt> there are certain benefits to not being build > by default, and therefore not having to meet the same standards as the > rest of the code > Jul 26 19:14:41 <jwatt> or is it better that we should start to be > forced to those standards? > Jul 26 19:15:10 <afri> so is it fair to summarize then: stability, > backend are the major issues. course of action: gdi+ on win, quartz on > mac, statically-linked cairo on linux? run past brendan et al. find out > other criteria from them? > Jul 26 19:15:36 * lsmith notes while he doesnt have the know how to > contribute code we (my co-worker and I) will definately be willing to > help on the testing front > Jul 26 19:15:53 <jwatt> lsmith: cool > Jul 26 19:15:57 <jwatt> afri: seems right > Jul 26 19:16:12 <Scooter> afri: sounds right to me. We should also > mention <use>, which is an outstanding feature on the list. > Jul 26 19:16:45 <tor> afri: and getting the current features working > through reviews (gradient, switch) > Jul 26 19:17:11 <Scooter> afri: and font-size > Jul 26 19:17:21 <afri> ok > Jul 26 19:17:44 <afri> then there is the issue of getting the current > code sr'ed... > Jul 26 19:17:55 <jwatt> fun > Jul 26 19:18:39 <lsmith> may i ask what timeframe you are hoping for? > (slap me if i am intruding btw) > Jul 26 19:18:41 <afri> so is anyone volunteering to run these issues > past brendan et. al. ? > Jul 26 19:19:10 <tor> afri: sure, I send something to the moz2 list > and talk to brendan > Jul 26 19:19:34 <jwatt> where is the moz2 list? > Jul 26 19:19:37 <afri> tor: cool > Jul 26 19:19:39 <jwatt> is that public? > Jul 26 19:19:53 <tor> unfortunately no > Jul 26 19:19:57 <jwatt> shame > Jul 26 19:20:19 <afri> anybody got an idea what timeframe we are > aiming for? i don't... > Jul 26 19:20:43 <Scooter> I will volunteer to take on <use> as soon > as I can clear out some of the other patches. <use> looks a lot like > the some of the gradient reference stuff. > Jul 26 19:20:52 <afri> cool > Jul 26 19:21:14 <jwatt> afri: no, I'm in no rush, I just wanted to > clarify things to aim for in the long run > Jul 26 19:21:35 <afri> ok, i guess that's item 1 sorted then as well > as we can atm > Jul 26 19:21:55 <jwatt> scooter's only here for another 40 min > Jul 26 19:21:57 <tor> brendan was floating 1.8 - if we were serious > about that, of that list, we might be able to get everything except for > <use> > Jul 26 19:22:07 <jwatt> what do we need to discuss while he's here? > Jul 26 19:22:32 <afri> cool > Jul 26 19:22:59 <Scooter> Do you really think we could get the > stability and platform issues worked out for 1.8? > Jul 26 19:23:03 <afri> tor: how about if you run this past brendan > and we talk about it again next week? > Jul 26 19:23:26 <tor> afri: sure > Jul 26 19:23:36 <afri> if there's a commitment by mozilla.org to get > this in, i guess we could make it > Jul 26 19:23:47 <tor> Scooter: do we have serious stability problems? > Jul 26 19:24:26 <Scooter> Not sure -- there's a lot of work in > progress. Until its all in a single build, we really haven't done much > to shake things out. > Jul 26 19:24:28 <afri> AFAICS many stability problems on linux are > libart-specific > Jul 26 19:24:51 <afri> there are issues with very large SVGs > Jul 26 19:25:03 <afri> we don't do any culling or clipping... > Jul 26 19:25:28 <Scooter> Should clipping be on our requirements list? > Jul 26 19:25:37 <tor> oh, speaking of which cairo is in the midst of > redoing their trianglization algorithms, so some fills mess up now > Jul 26 19:25:39 <afri> so if the SVG viewport is larger than the > client area we still build all the paths > Jul 26 19:26:14 <afri> i guess visual glitches are one > thing...crashing/hanging is another > Jul 26 19:27:10 <afri> shall we move to the other items then? > Jul 26 19:27:12 <Scooter> I don't know...I guess I'd feel more > comfortable enabling SVG right *after* 1.8. That way we could get in at > the start of a cycle. > Jul 26 19:27:23 <Scooter> Sure, lets move on. > Jul 26 19:27:50 <afri> "currentColor" > Jul 26 19:28:07 <afri> Scooter: you had a question about the intent > of the specs? > Jul 26 19:28:35 <afri> isn't "current" just the value of the "color" > property? > Jul 26 19:29:14 --> shaver (~shaver@...489...) has joined #svg > Jul 26 19:29:28 <Scooter> Sort of. The question is, is it the value > of the color property of the surrounding elements (i.e. inherited) or > just the last set value? > Jul 26 19:30:27 <afri> is there a difference? > Jul 26 19:31:24 <Scooter> Internally, I think that there is. For > example, I could set the "color" property on an HTML element then not > set the property again and then use it inside of SVG as "currentColor". > Jul 26 19:31:48 <afri> ah, i see > Jul 26 19:31:58 <afri> i haven't got a clue > Jul 26 19:32:23 <afri> don't the specs say anything about this? > Jul 26 19:32:29 <afri> (the css specs) > Jul 26 19:32:38 <Scooter> I *believe* that that is the intent of the > spec -- a way to maintain color between different document elements. > Jul 26 19:33:12 <Scooter> The only example (in the test suite) just > sets the color inside of SVG and then references it using "currentColor" > Jul 26 19:33:43 <afri> hmm, i guess noone here knows... > Jul 26 19:34:09 <jwatt> maybe ask in www-svg, or mail chris/dean > directly > Jul 26 19:34:10 <Scooter> The css specs (2.1) don't talk about > "currentColor". That's supposed to be coming in CSS3 (I'm told). > Jul 26 19:34:19 <Scooter> OK, will do. > Jul 26 19:34:26 <afri> great > Jul 26 19:34:38 <afri> 3. ICC Color - do we do it? Should we? > Jul 26 19:34:50 <afri> i don't even know what ICC color is > Jul 26 19:35:00 <tor> color profiles for color correction > Jul 26 19:35:12 <afri> ah > Jul 26 19:35:14 <Scooter> And its part of the SVG spec > Jul 26 19:35:40 <afri> i guess we should then > Jul 26 19:35:44 <Scooter> My take is to wait for somebody to ask for it. > Jul 26 19:35:47 <afri> at some point > Jul 26 19:35:51 <tor> somewhat low priority, I woudl think > Jul 26 19:35:57 <afri> yeah > Jul 26 19:35:58 <jwatt> btw, I found their specs online some years > ago, I downloaded them if they can't be found now > Jul 26 19:36:19 <Scooter> They are still online. > Jul 26 19:36:39 <Scooter> OK, I agree that this should be low priority. > Jul 26 19:36:40 <jwatt> cool, anyway, low priority > Jul 26 19:36:44 <afri> cool - so ICC color=low priority. 4) patterns > Jul 26 19:36:56 <Scooter> Any takers? > Jul 26 19:37:00 <jwatt> ugh > Jul 26 19:37:17 <afri> i think we need to sort out clipping before > patterns > Jul 26 19:37:23 <Scooter> Agreed. > Jul 26 19:37:27 <afri> that's something i wanted to do next > Jul 26 19:38:19 <Scooter> Great! Getting clipping would be really good. > Jul 26 19:38:26 <afri> so I guess we wait until clipping is sorted > out then > Jul 26 19:38:35 <afri> 5. SVG text > Jul 26 19:39:09 <Scooter> What's missing besides textPath? > Jul 26 19:39:12 <tor> textPath seems hard > Jul 26 19:39:36 <afri> selection is only partially implemented atm (i > got bored) > Jul 26 19:40:23 <afri> i think before we ship in default builds, > selection either needs to be disabled or finished > Jul 26 19:40:32 <afri> it's kind-of screwy atm > Jul 26 19:41:04 <afri> font-size we have Scooter's patch for, so i > guess that will go in soon > Jul 26 19:41:51 <Scooter> That's sort of minor (although you wouldn't > know it by the number of comments). > Jul 26 19:41:56 <afri> All the other stuff (textPath, tref, glyphs) > would be nice, but does anybody want to work on that? > Jul 26 19:42:05 <Scooter> So, I guess we don't have any takers for > working on SVG Text? > Jul 26 19:42:27 <jwatt> why disable it? I'd prefer not to, even if it > doesn't get finished. > Jul 26 19:42:58 <afri> disable selection, not text > Jul 26 19:43:06 <jwatt> I know > Jul 26 19:43:10 <Scooter> So, should we submit a bug for the missing > stuff with helpwanted? > Jul 26 19:43:30 <afri> it doesn't work - some of the machinery is > there, that's all > Jul 26 19:43:39 <jwatt> but sometimes it works, and the worst thing > that can happen is that the user can't select what they want and files a > bug > Jul 26 19:43:54 <afri> fair enough > Jul 26 19:44:40 <Scooter> If I'm going to do <use> I'll take a look > at <tref> also. > Jul 26 19:44:45 <afri> cool > Jul 26 19:45:08 <afri> tor: text is working on cairo, right? > Jul 26 19:45:13 <Scooter> That still leaves textPath (and glyphs) > Jul 26 19:45:39 <jwatt> these things are out of my league at the mo > Jul 26 19:45:49 <tor> afri: yes, though i18n text doesn't work > Jul 26 19:46:17 <tor> afri: font size tends to be off > Jul 26 19:46:37 <afri> i guess that's stuff we can live with > Jul 26 19:47:29 <afri> so shall we move on to the next then? > Jul 26 19:47:30 <tor> probably fixable - I'm using the "wimp api" for > cairo fonts > Jul 26 19:47:38 <Scooter> So, file a bug for textPath and move on? > Jul 26 19:48:09 <afri> cool > Jul 26 19:48:17 <Scooter> What's next? > Jul 26 19:48:24 <jwatt> item 6 > Jul 26 19:48:29 <tor> <defs> > Jul 26 19:48:39 <afri> <defs>: why on earth are they stylable? > Jul 26 19:48:54 <afri> & transformable? > Jul 26 19:49:14 <tor> good batch of crack at the w3c? > Jul 26 19:49:24 <tor> I mean, I'm sure they had a good reason > Jul 26 19:49:43 <jwatt> another one for chris/dean? > Jul 26 19:50:01 <afri> it looks to me as if everything that goes into > a <defs> has its style and/or xforms applied whereever it's referenced from > Jul 26 19:50:10 <afri> yeah, i'll mail the list > Jul 26 19:50:25 <afri> although i usually don't get any answers > Jul 26 19:50:50 <Scooter> Maybe all of us can sort of push for > answers. I'm on the svg list also (mostly been lurking). > Jul 26 19:50:54 <tor> <use> is supposed to use a combined cascade, > which makes the style make a bit of sense > Jul 26 19:50:57 <jwatt> then follow it up with personal emails > Jul 26 19:51:42 <afri> ok, i guess i should take a look at the <use> > specs before i complain about anything > Jul 26 19:51:56 <Scooter> I've got to go get ready for my > presentation. I'll be back in a couple of hours (if you all are still > at it), but if not, will somebody summarize via E-Mail? > Jul 26 19:52:25 <jwatt> yeah, somebody will > Jul 26 19:52:29 <-- lsmith has quit (Read error: Connection reset by > peer) > Jul 26 19:52:33 <afri> Scooter: have fun > Jul 26 19:52:42 <Scooter> Thanks! Talk to you soon. > Jul 26 19:52:45 <-- Scooter (~chatzilla@...490...) has left > #svg > Jul 26 19:53:19 <afri> so shall we carry on ... or wait for scooter > to come back ... or leave it for another day? > Jul 26 19:53:53 <jwatt> I'm happy to carry on or wait 'til scooter > gets back > Jul 26 19:54:10 <tor> either is fine for me > Jul 26 19:54:17 <jwatt> I'd rather not leave it until another day though > Jul 26 19:54:37 <afri> ok > Jul 26 19:54:47 <afri> what's next? > Jul 26 19:54:48 <tor> no 7 - svg matrices > Jul 26 19:55:00 <afri> should they be live or not? > Jul 26 19:55:23 <afri> the specs say nothing > Jul 26 19:56:02 <afri> does anybody have any strong feelings on this? > Jul 26 19:56:18 <jwatt> but it seems that at least dean and the other > SVG WG members that work on batik say they aren't > Jul 26 19:56:30 <afri> if not, then i'd prefer to leave them as they > are now... > Jul 26 19:56:34 <jwatt> I would like to maintain compatibility with > batik > Jul 26 19:56:51 <jwatt> but to be honest I don't understand your > reasons in the bug > Jul 26 19:56:54 <afri> yeah but i think they just say that because > that's how they implemented them in batik > Jul 26 19:57:18 <jwatt> does dean work on batik? > Jul 26 19:57:24 <afri> i don't know > Jul 26 19:58:01 <jwatt> is there no other way of doing what you want > them to do? > Jul 26 19:58:52 <afri> do you think the compatiblity issue is a real > issue? > Jul 26 19:59:10 <afri> i mean in 'normal' svg usage this is unlikely > to come up > Jul 26 19:59:43 <jwatt> it's the kind of thing that I would be likely > to come up against > Jul 26 19:59:58 <jwatt> but then dom scripting is really what I like > to do most > Jul 26 20:00:06 <jwatt> I don't know about other users > Jul 26 20:00:31 <afri> the way i see it is, the specs don't say > anything, so anybody scripting in this area can't make any assumptions > about it being live or not > Jul 26 20:00:41 <jwatt> what I would be worried about is that people > would start to take advantage of the fact that one matrix could be > referenced by multiple transforms in mozilla > Jul 26 20:01:12 <jwatt> and then it becomes impossible to change it > without annoying a whole load of people > Jul 26 20:01:15 <jwatt> maybe not, but they will > Jul 26 20:01:43 <afri> the thing is I don't see why we should cripple > our api because batik implemented something that is outside the specs in > a particular way > Jul 26 20:01:52 <afri> batik should change > Jul 26 20:02:23 <jwatt> heh > Jul 26 20:02:32 <afri> also, i think it is really inconsistent with > other datastructures that have to be live > Jul 26 20:02:35 <afri> e.g. points > Jul 26 20:02:37 <tor> what does adobe do? > Jul 26 20:02:49 <jwatt> adobe doesn't do that part of the dom > Jul 26 20:02:51 <afri> why are points live and transforms aren't > Jul 26 20:03:03 <jwatt> afri: yeah, I agree with that bit > Jul 26 20:03:46 <jwatt> to be frank this is another WG mess that has > no good solution > Jul 26 20:03:58 <afri> i really think this is not a big > interoperability issue > Jul 26 20:04:24 <afri> live matrices are nearly a superset of > non-live matrices > Jul 26 20:04:46 <jwatt> well for the moment let's leave it as it is, > and perhaps come back to it in the future > Jul 26 20:04:56 <jwatt> I'll just get on with that bug and ignore the > liveness aspect > Jul 26 20:04:57 <afri> what i mean is, any code that is coded with > non-live matrices in mind is likely to work in Moz as well > Jul 26 20:05:06 <jwatt> brb > Jul 26 20:05:21 <afri> not vice versa of course > Jul 26 20:06:32 <jwatt> back > Jul 26 20:06:35 <jwatt> afri: right > Jul 26 20:06:37 <afri> so would you guys be ok with leaving it as it > is for now? > Jul 26 20:07:27 <tor> I'd be curious to hear what others thought > about <embed> content > Jul 26 20:07:28 <jwatt> for now yes, but I'd like to go over how much > of a problem this would be for crocodile-maths with you later > Jul 26 20:07:40 <jwatt> so <embed> > Jul 26 20:08:03 <tor> oh, thought you were talking about the end of > the meeting, not the item > Jul 26 20:08:27 <afri> i think we should do <embed> > Jul 26 20:08:37 <jwatt> I think we should allow the use of <embed> > for svg content in html, but not in xhtml > Jul 26 20:08:51 <afri> i don't agree with dbaron's objections > Jul 26 20:09:10 <jwatt> I do for xhmtl > Jul 26 20:09:10 <tor> is <embed> even in xhtml? > Jul 26 20:09:23 <jwatt> actually I don't know > Jul 26 20:09:36 <jwatt> come to think of it, probably not > Jul 26 20:10:11 <jwatt> In which case I would support implementing it > Jul 26 20:10:18 <jwatt> (your patch) > Jul 26 20:10:40 <tor> but should we always use the internal svg? > Jul 26 20:11:13 <tor> or should we <span class="quiet voice">add a > pref</span>? > Jul 26 20:11:23 <afri> heh > Jul 26 20:11:44 <afri> does the abobe stuff work with moz? > Jul 26 20:11:58 <afri> i've never tried it > Jul 26 20:12:22 <tor> it did last time I tried > Jul 26 20:12:23 <afri> from my point of view, always running native > svg would be just fine > Jul 26 20:12:57 <afri> it probably depends on how much people use asv > with moz > Jul 26 20:13:08 <tor> it would be a problem for a customer currently > happily using svg beyond the capablities of mozilla > Jul 26 20:13:21 <jwatt> does <embed> not have an attribute for > specifying the prefered plugin? > Jul 26 20:13:33 <afri> but are there customers like that? > Jul 26 20:13:49 <afri> in which case, yeah, we'd probably need a pref > Jul 26 20:14:30 <afri> sorry i got to go as well in a minute > Jul 26 20:14:52 <afri> tor: what do *you* think about embed? > Jul 26 20:14:59 <jwatt> afri: will you be back later when scooter > gets back? > Jul 26 20:15:14 <afri> if we had a pref would dbaron be ok with it? > Jul 26 20:15:23 <tor> afri: I think we should handle embed content > Jul 26 20:15:28 <afri> jwatt: hopefully > Jul 26 20:15:52 <tor> afri: maybe we should check if a plugin can > handle it first, then go to the browser? > Jul 26 20:16:09 <afri> sounds good > Jul 26 20:16:20 <afri> would that be easy to implement? > Jul 26 20:16:43 <tor> not sure offhand - have to check the code > Jul 26 20:17:27 <afri> ok, sorry gtg - talk to you later > Jul 26 20:17:33 --- You are now known as afri_away > Jul 26 20:19:49 <jwatt> tor: enumerate the gecko-content-viewers > category for supported mime types? > Jul 26 20:20:32 <jwatt> practically a quote > Jul 26 20:36:44 --> santamarta > (juanjo@...491...) has joined #svg > Jul 26 20:40:53 <-- shaver (~shaver@...489...) has left #svg > Jul 26 21:14:56 <tor> mailed the quartz guy to check the status of > that backend > Jul 26 21:23:18 <jwatt> cool > Jul 26 21:23:23 <jwatt> afri: ping > Jul 26 21:23:50 --> Hixie_ (~ianh@...492...) has > joined #svg > Jul 26 21:24:13 --> rocWork (roca@...493...) has > joined #svg > Jul 26 21:28:55 <jwatt> tor, we might come short of some aspects of > svg tiny, but aren't there things we do that are only in basic or full? > Jul 26 21:31:00 <tor> jwatt: yes, gradients are the big one > Jul 26 21:31:14 <rocWork> mmm, gradients > Jul 26 22:30:29 --> Scooter (~chatzilla@...490...) has > joined #svg > Jul 26 22:37:11 <-- DaaWk has quit (Ping timeout: 372 seconds) > Jul 26 22:37:15 <jwatt> hi scooter > Jul 26 22:37:35 <-- Daa has quit (Ping timeout: 372 seconds) > Jul 26 22:39:18 <tor> did my mail get through? I haven't gotten the > bounce back from drivers, but apparently gila is suffering from spammage > Jul 26 22:39:44 <jwatt> tor: that's what my previous comment was about > Jul 26 22:46:55 --> DaaWk (daa@...494...) has joined #svg > Jul 26 22:48:08 --> Daa (daa@...494...) has joined #svg > Jul 26 22:49:19 --- You are now known as afri > Jul 26 22:56:21 <jwatt> afri: can you expand on what you mean by: > 'Live' matrices that can be shared amongst several transforms come in > very handy for things like implementing dynamic canvases where part of > the objects should be transformation-invariant. > Jul 26 22:57:16 <jwatt> particularly the part about "part of the > objects should be transformation-invariant" > Jul 26 22:57:29 <-- Scooter has quit (Remote host closed the connection) > Jul 26 22:59:52 <afri> jwatt: well e.g. imagine a map where cities > are displayed by some icon > Jul 26 23:00:20 <afri> jwatt: as you zoom into the map you want the > icons to stay at the same size > Jul 26 23:01:14 <afri> ... but everything else should zoom > Jul 26 23:01:45 <afri> so you need a different xform for the city > icons and for everything else > Jul 26 23:02:41 <jwatt> afri: I see, that makes sense -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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

flowing text support is in
by bulia byak 03 Aug '04

03 Aug '04

I just committed another exciting patch from Fred: support for flowing text! http://www.w3.org/TR/SVG12/#flow So far it's pretty much read-only, i.e. there's no UI yet for creating flow objects. But they are rendered already, and you can partially edit the envelope shape. Load share/examples/flowtext.svg from CVS, select the object, switch to node tool. and node-edit the envelope - the text will reflow into whatever shape you give it, preserving all the paragraph divisions and applied styles. Really exciting. There are two flow shapes in that example; when the text does not fit entirely in the first one, the rest will go to the second shape (to the right). There's also an "excluded" shape in the middle that the text flows around. You can only edit the first shape so far. You also cannot yet edit the flowed text by text tool - this is yet to be done. Note that this is a feature from SVG 1.2, which itself is not final yet and may change. This means that Batik or Adobe can't yet render that example. And yes, I know, we don't support all of 1.1 yet :) Now with Pango and this new patch, I hope to find time for rewriting the rest of the text system for the next version, to finally make it usable.

3 6

'No Preview' drawing
by Bob Jamison 02 Aug '04

02 Aug '04

Here is the file open dialog again, with a default preview SVG image, for when a preview cannot be displayed: http://troi.titan-aeu.com/~rjamison/inkscape/files/filedialog5.png That is what I meant by the "Preview not available" drawing. It would be nice if someone were to replace this (imho) unattractive placeholder I made, with something simple (small SVG code), elegant, and understated. Something like the Gimp dialog, only nicer. The only constraint is that the words are a single text string that can be localized. Any volunteers? Bob

3 6

Re : comments on fr.po
by Gazal, Geraud (MED) 02 Aug '04

02 Aug '04

>I"m not a native french speaker; can someone please check the following > comments and diff? Thanks. I'm :) > What"s the preference between normal space and non-breaking space before >e.g. `:" ? I"d have thought that it would be bad to have a line break >just before `:", which suggests that non-breaking space (  /   >/  ) is better. In French, the 'typographic" rule is to place a space before (and after) ":". But no line break. -> preference is "non-breaking space" I think I'll try to have a second look on the French translation. (I don't always agree with some translations, or would like to shorten some of them) But haven't had time enough recently to do so. Plus did not manage to synchronize with Frederic Rodrigo. (I think he has done a great job, and I don't want to break this) Regards, Matiphas

1 0

Inkscape Status 2004-08-01
by Bryce Harrington 02 Aug '04

02 Aug '04

Statistics Nov 15 May 15 Jun 15 Jul 15 Aug 1 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 845 844 (68.5%) (92.7%) (93.4%) (94.0%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 33 17 (99.6%) (99.8%) (99.8%) (99.8%) (99.9%) Total SF Page Views * 475,000 616,263 741,681 838,154 Total SF Downloads * 27,400 34,015 39,359 44,068 Total Freshmeat URL Hits 746 * 7,333 7,946 9,034 Total Freshmeat Subscriptions 16 74 87 93 112 Lines of Code in src/: 115,901 189,116 280,263 264,418 273,381 Code lines 147,471 210,119 192,240 199,473 Comment line 16,757 40,620 41,926 42,411 Blank 25,886 34,677 35,422 36,717 Lines of Docs in doc/: 1,135 4,544 15,170 15,217 16,117 Lines of content in website: 1,173 6,008 6,372 6,784 6,953 Size of the Inkscape wiki: 3,700 18,638 17,176 17,854 19,096 Minutes since last ChangeLog mod: 360 * * 54 30 Bugs open/total: 9/15 57/365 63/401 73/496 103/548 Features open/total: 18/18 183/238 210/285 242/331 253/347 Patches open/total: 1/ 6 4/ 83 5/ 88 8/110 6/117 CVS Commits (as per inkscape-cvs): 481 3391 5549 6314 6,528 Inkscape-devel membership: 49 78 84 95 98 Inkscape-announce membership: 9 43 53 60 65 Inkscape-user membership: 71 76 90 98 Num Translations : 32 33 Ave Translation Ratio: 40.5% 43.8%

1 0

Boehm Garbage Collector
by Jon Phillips 02 Aug '04

02 Aug '04

Hello all, In my attempt at being able to build CVS once again and upgrading to Fedora Core 2 from FC1 (intermediate b4 gentoo), I found several errors which many users and developers have been complaining about not working. Upon some research and acting as JoeUser, it appears that this collector is not available as an RPM or common package!!! I'm reacting to this as JOE USER and this is probably not good for our next release. There are only old rpms for SUSE available and Bryce has tried (and they did not work). Also, Ted says that this garbage collector is avail. for debian. But, there are not packages available for Fedora Core as far as I can see and not many listings elsewhere. Thus, we really need this to be more widely available. There are three options I see: 1.) EASY: Drop Boehm Garbage Collector as a dependency (or replace with something more widely avail) 2.) MED: Push changes upstream and try and get packages for current version of this collector at common repositories. 3.) HARD: Supply our own along with Inkscape as a package or in our main build tree. Please voice your opinions, as our current dependencies are a little too bleeding edge it seems right now, and I totally understand why these are needed. However, if by the time we do a release these dependencies are not widely available on the dominant distros (fedora core, windows, etc), then there will be a problem (aka, loss of users). Thoughts and solutions? Jon -- Jon Phillips PO BOX 948667 LA JOLLA, CA 92037 USA USA.PH.858.361.2811 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/)

3 3

Notes with 0.40 dependencies
by Bryce Harrington 02 Aug '04

02 Aug '04

A couple notes regarding some of the new libs, that Ted, Rejon, and I have been talking about... * We need to think about maybe providing a package for the boehm gc dep. The packages available through rpmseek are for an old version and don't have the cplusplus option. * Our 0.40 release timeframe is going to be gated by having packages of gtkmm 2.4 and its deps available for all major distros. The package availability for SuSE (and other distros) isn't pretty right now. Hopefully it'll get better within a couple months, but regardless, it would not be wise to release *until* those packages are posted and sufficiently available. Bryce

2 1