- Inkscape Devel - Inkscape Mailman

Polyline and polygon point specification
by Mark Nyrup Mortensen 03 Jul '04

03 Jul '04

Hi, i received a svg-file converted from wmf (by the Batik Graphics2D SVG Generator) a little more than a month ago. The file consisted of several thousands of polygons (i looked in the XML Editor :-), yet Inkscape displayed nothing but a blank canvas. I looked into the problem and found that Inkscape (and a pre-inkscape cvs-version of Sodipodi) only considered points in polygons (and polylines) written the same way as Inkscape does, and not in every way the SVG spec indicates (requires?). Well, to the point :-) I made a small patch (and a small test-file), which I have used for the last month with a CVS-update almost every day (no crashes), and I would like to know if anyone is interested in them? And then a small questions, sorry ;-) I would like to look into a blend tool (and some other more or less useful tools), but since I'm new to the internals of Inkscape, I would like to know if it's sane in it's current state (with the structural changes going on). I could still try to make an abstract outline of the blend function, which then could be implemented later (when the Extension API has been implemented around version 0.42?). (I make no promises though:-) I have been using Java almost exclusively since version 1.0.1 came out, with some perl and python tossed in, and have had only a brief look at C/C++ in the same period (that's the reason i don't promise anything :-). Mark Nyrup Mortensen

2 1

Re: [Inkscape-user] SVG that doesn't display in Inkscape.
by MenTaLguY 02 Jul '04

02 Jul '04

On Wed, 2004-06-30 at 22:36, Trent Buck wrote: > Removing the <switch> </switch> tags from around the body seems to work. > > About 80% of the data is some binary formatted junk in an <i:pgf> tag. > I guess it's a thumbnail or something. > > Maybe as a kluge inkscape should ignore <switch> tags to make such > exported images work? <switch> its intended use is to enclose a bunch of children, only one of which is supposed to be rendered (based on conditions specified in their requiredFeatures, requiredExtensions, and systemLanguage attributes); I'm not sure whether displaying everything would be an improvement over displaying nothing for typical documents that use it. It shouldn't be hard to support properly, though. We're a little too close to the pre-release freeze to squeak it into this release, but I'll put in an RFE and stick it on the roadmap for 0.40. -mental

1 0

Brasilian Portuguese Translation
by Juarez Rudsatz 02 Jul '04

02 Jul '04

Attached there is a pt_BR translation. Somebody could review ? Mit Freundichen Grüßen Juarez Rudsatz

2 1

new tutorial started on Wiki
by John Griessen 02 Jul '04

02 Jul '04

Hi, I've started putting up a tutorial, and would like a little help putting an image on the wiki... I read about links thinking they would apply to a upload file that is an image in .png format, but no luck... http://www.inkscape.org/cgi-bin/wiki.pl?action=edit&id=TutorialIdeas is where to look to help out. I have not seen any other image content on the Wiki, is it possible? JG -- John Griessen Cibolo Design Austin Texas EE good at IR systems, power supplies, logic design, A2D D2A, digital amps, mechatronics, SiGe and CMOS layout, MEMS/mech/electronic/photonic modeling, charge pump PV/battery/fuel cell power converters, linux counter #249315

2 1

Report for 2004-07-02 10:00 GMT-0500
by unknown＠example.com 02 Jul '04

02 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

1 0

mergining SPObject and SPRepr
by MenTaLguY 02 Jul '04

02 Jul '04

(yay, I'm back, sorta) Since it's been brought up I don't think the suggestion of merging SPObject and SPRepr to solve our update problems is necessarily a good idea. The main reason is just that with a unified representation we have to make a tradeoff between: * an efficient representation for editing or * a representation that preserves the XML syntax tree during every transformation (i.e. we don't want Inkscape to chew up or discard arbitrary XML fragments which have no semantic meaning to us, but are important for other uses..) Both of these are important goals for us, so I think dividing our representation into separate classes to address each of these needs is necessary. We could still wrap SPObject/SPRepr pairs in another object, which would encapsulate our updating strategies for them. That _might_ be helpful, but I'd need to think about that some more. FWIW, here are some of the updating problems I see: 1. the id binding problem Currently, the SPObject <-> SPRepr binding is maintained by using XML fragment ids. This is IMO, more problematic than it's worth and forces us to impose ids on all XML nodes (including text nodes). My existing plan is to do the mapping directly rather than relying on ids (I've done some of the preliminary work on this already; new code should use SPDocument::getObjectByRepr rather than SPDocument::getObjectById). 2. the authority problem Are SPObjects or SPReprs authoritative? Not all our code is consistent in this regard, especially as it's often more convenient/efficient to update the SPObject directly. I believe the answer should be that SPReprs are authoritative, though SPObjects can temporarily be out of sync ("dirty") with new changes, provided those changes are flushed to the SPRepr layer at key points, e.g. before committing an undo log. (i.e. SPObject is essentially a cache for SPRepr, which functions as a backing store) 3. the manual update problem Many times it's more efficient to make changes at the SPObject level rather than to the SPRepr. Under the present system, this requires explicit calls to SPObject::updateRepr() to synchronize the state; if updateRepr() is called for every SPObject change, it becomes grossly inefficient. On the other hand, it's very tricky to defer these update calls until later, because mistakes are easy and they often get missed. I think the solution is to automate the "lazy" updating of SPReprs, so we get the performance benefits of lazy updates without having to debug manual updating code in a bajillion places. This is one thing that could (conceivably) be addressed in a wrapper class. -mental

1 0

Re: Report for 2004-07-01 18:00
by bulia byak 02 Jul '04

02 Jul '04

> Unfortunately, the last build attempt at compiling Inkscape CVS was > very unsuccesful. Maybe it's better to just forward error logs to the devel list because it's hard to predict whose changes may be the cause of the problem. In this case, hierarchy_* is Mental's stuff and rdf_* is Kees'.

2 1

Unable to set an object ID
by Bob Jamison 01 Jul '04

01 Jul '04

Does anyone have any ideas about this one? I don't think that this is a new bug, but another symptom of our ongoing problem with SPRepr and SPObject synchronization. Now it seems that any attempt to set the ID of an object via the GUI, either via Item Properties, or the XML editor, fails with messages like this: ** (inkscape:7718): CRITICAL **: Attempt to set id of bound SPRepr (0x8f98b34) without having registered the SPObject in the document's id table I know that some code could set the ID of the SPObject, too, but I fear that might break things further. Bob

2 2

SVG::Metadata Release 0.06
by Bryce Harrington 01 Jul '04

01 Jul '04

The 0.06 release of SVG::Metadata is now available on CPAN, here: http://search.cpan.org/~bryce/SVG-Metadata-0.06/ The change for this release is the addition of a --delete flag to svg_annotate, which removes any <metadata>, <rdf>, or <rdf:RDF> tags from one or more svg files (it also recursively processes directories, if specified). Thanks go to Nicu for the suggestion (see below). Bryce On Thu, 17 Jun 2004, Nicu Buculei wrote: > Bryce Harrington wrote: > > This will add metadata to any files that don't already have it, > > including setting the license to Public Domain and the title to > > "My Name - <filename>". (You can override this if you want; see the > > manual page for svg_annotate on CPAN). > > > > Let me know if you run into issues. > > it looks OK to me, expect very soon my images with metadata added. > > you may want to consider in the future the case of files already having > metadata - for example the author may want to change the license or to > correct a spelling mistake made in the previous annotation. > a possible method is to request an additional command line parameter to > override > also an interesting case is to remove metadata from files - for example > in order to minimize the file size (this may matter for a huge collection) > >

1 3

L10n files
by Arpad Biro 01 Jul '04

01 Jul '04

Hi, The current UI localization status: am 11 % az 7 % be 25 % ca 80 % cs 26 % da 14 % de 75 % el 5 % es_MX 57 % es 100 % et 0 % fr 50 % ga 1 % gl 11 % hu 100 % it 12 % ja 42 % mk 0 % nl 25 % no 24 % pl 22 % pt_BR 1 % pt 28 % ru 55 % sk 28 % sl 99 % sr@...428... 28 % sr 86 % sv 28 % tr 25 % uk 16 % zh_CN 15 % Average 34 % As you can see, we have two translation files at 0 % and another two at 1 %. Probably it would be better to remove these four files. What do you guys think? Arpad Biro __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

5 8