June 2004 - Inkscape Devel - Inkscape Mailman

Report on Bugs
by Bryce Harrington 14 Jun '04

14 Jun '04

I've gone through all the bug reports in the tracker on SF to update priorities. There were eight bugs that looked like critical bugs: 964635 CRASH (Win32) on insert special character in text w/ALT+Num 953771 Click on zoom spin control crashes inkscape 955020 assert when quitting with dialog and duplicated window 950610 SEGV with gradients 937347 symbol fonts not supported? 934209 Marker-related assertion failure. 852976 win32: mouse freeze when dragging outside canvas 925033 win32: non-ascii filenames still don't work For this release since it is development-focused I don't think we need to close all the critical bugs, but it'd be nice to close a few. Bug 852976 is reported a LOT, there's probably 3-4 other bug reports that describe basically the same problem, that I left at lower priority. We've looked at it before and it seems to be a Gtk-on-Windows issue so there might not be much we can do about it. It would be nice if someone could figure out if there's a work-around of some sort for Windows that would stop the crashing, even if it required disabling a feature on Windows (e.g. autoscrolling). Since the Pango patch was applied today, it would be wise for everyone to get a new development copy at this time and test the heck out of it, and report all recreatable crash bugs you can find, so we can address them prior to the upcoming release. Bryce

1 0

mucking with repr
by Kees Cook 14 Jun '04

14 Jun '04

So, I want to understand what I have to do to make the xml parser sane when it comes to reading RDF's. Currently it adds id='s and removes "xmlns"s. Where should I start looking for examples on how to search/change/update elements in the XML tree? -- Kees Cook @outflux.net

2 1

Re: [Clipart] ANNOUNCE: SVG::Metadata
by Glenn Randers-Pehrson 14 Jun '04

14 Jun '04

At 11:14 AM 6/13/2004 -0700, Bryce Harrington wrote: >On Sun, 13 Jun 2004, Glenn Randers-Pehrson wrote: >> At 10:04 PM 6/12/2004 -0700, Bryce Harrington wrote: >> >I've completed writing some code for processing collections of SVG files >> >to validate their metadata (title, author, license). The code is >> >packaged and released to CPAN: >> > >> > http://search.cpan.org/~bryce/SVG-Metadata-0.01/ >> > >> >It includes the following: >> > >> >SVG::Metadata - A module for parsing and accessing an SVG's metadata, >> > including title, author, license, and keywords. >> > >> >svg_validate - A script for scanning through a collection of SVG files >> > and extracting ones with valid metadata. It also automatically >> > generates png's for each (using inkscape) and metadata text files. >> >> For the past few weeks I have been attempting to get a "License" keyword >> approved by the PNG group, so far without success. The group seems to >> feel that licensing info should go in a textual chunk with the "Copyright" >> keyword, even if there is no copyright. I'll know more on June 23 >> when the group finishes voting. >> >> We could follow that recommendation, or we could of course use an >> un-registered "License" keyword or even "OCAP License" keyword. It >> would be good to use the same keywords in PNG and SVG metadata. > >Agreed. But if they end up using the Copyright keyword, that's probably >not an issue. > >Do you know of tools for editing the metadata in a PNG file? I could >modify the script to include a metadata insertion into the generated PNG >files as part of the process. pngcrush will do it. I wanted to resolve issues with the PNG group before writing it up. For example, pngcrush -text b "Copyright" \ "copyright 2000 svg-scribblers, Inc. Placed in Public Domain June 2004" \ -text b "Author" "J. F. Scribbler, www.svg-scribblers.com" \ in.png out.png The "b" means place the resulting tEXt chunk before the IDAT chunks. Otherwise use "a" to put it after the IDAT. Glenn

3 3

RE: [Inkscape-devel] Re: [Clipart] ANNOUNCE: SVG::Metadata
by bulia byak 13 Jun '04

13 Jun '04

>Do you know of tools for editing the metadata in a PNG file? I could >modify the script to include a metadata insertion into the generated PNG >files as part of the process. We probably also need to copy the SVG metadata into our exported PNG. Now our png-write.cpp has: /* Made by Inkscape comment */ text_ptr[0].key = "Software"; text_ptr[0].text = "www.inkscape.org"; but you can add arbitrary additional fields. Although I think this should be optional because not everyone wants their PNG bloated by metadata. _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

Re: [Clipart] ANNOUNCE: SVG::Metadata
by Glenn Randers-Pehrson 13 Jun '04

13 Jun '04

At 10:04 PM 6/12/2004 -0700, Bryce Harrington wrote: >I've completed writing some code for processing collections of SVG files >to validate their metadata (title, author, license). The code is >packaged and released to CPAN: > > http://search.cpan.org/~bryce/SVG-Metadata-0.01/ > >It includes the following: > >SVG::Metadata - A module for parsing and accessing an SVG's metadata, > including title, author, license, and keywords. > >svg_validate - A script for scanning through a collection of SVG files > and extracting ones with valid metadata. It also automatically > generates png's for each (using inkscape) and metadata text files. For the past few weeks I have been attempting to get a "License" keyword approved by the PNG group, so far without success. The group seems to feel that licensing info should go in a textual chunk with the "Copyright" keyword, even if there is no copyright. I'll know more on June 23 when the group finishes voting. We could follow that recommendation, or we could of course use an un-registered "License" keyword or even "OCAP License" keyword. It would be good to use the same keywords in PNG and SVG metadata. Glenn

2 1

off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610
by Artemio 13 Jun '04

13 Jun '04

Hello everybody! This may be off-topic, but maybe not. I didn't do anything to my system except for installing inkscape-20040610 yesterday. I have been using my system (Mandrake Linux 10.0) for three months: viewing PS/PDF files, creating PS/PDF files - all with ESP Ghostcript 7.07 (that one with CUPS). But yesterday, suddenly, GS became broken. So, everytime I try to view a PS or PDF file with KGhostView, Ghostview or any other viewer, and everytime I try to print to PS or PDF, I get an error message box from these applications, they show a gs command line and an error message: "Unrecoverable error: syntaxerror in token Operand stack: --nostringval-- --nostringval-- Zmachine sRB --nostringval--" I don't have any GS_* variables defined except fot GS_LIB=/home/artemio.fonts The weird thing is that when I say "gs" in the command line, I instantly get this: ESP Ghostscript 7.07 (2003-11-19) Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Unrecoverable error: syntaxerror in token Operand stack: --nostringval-- --nostringval-- Zmachine sRB --nostringval-- On my system, /usr/bin/gs is symlinked to /usr/bin/gs-common, and gs-common is an ELF executable, not a shell wrapper that adds some extra options. Please excuse me if this is off-topic here, but I just don't know what to do... Artemio. -- fOr ThE 1337 mEmBeRz OnLy -> http://elite.artemio.net [local time 12:56:51 (GMT +3) 13 June 2004] [system uptime 1 hr 49 min]

1 1

[Clipart] ANNOUNCE: First official release of Open Clip Art Library (fwd)
by Bryce Harrington 13 Jun '04

13 Jun '04

---------- Forwarded message ---------- Date: Sat, 12 Jun 2004 21:35:02 -0700 (PDT) From: Bryce Harrington <bryce@...260...> To: clipart@...330... Subject: [Clipart] ANNOUNCE: First official release of Open Clip Art Library The first official release package of the Open Clip Art Library is now available in the download section of the website: http://www.openclipart.org/downloads/ openclipart-0.03.tgz This is the "Father's Day, 2004" release. There aren't really any Father's Day type images, though; they're actually all UK road signs. ;-) Nineteen items passed a validation against the OCAL File Guidelines, and these are included in this release. The items that failed were missing RDF metadata sections and did not indicate title, author, and license. A listing of files scanned and a log of the testing results is included for review. A Makefile is included for installation on *nix platforms via the command `make install` as root. `make uninstall` also works. On Windows, users will need to manually install to their preferred directory. While not many items are included in this release, the focus has been to find and establish a process for accepting, checking, and packaging the files. With these in place, future releases will be quicker and easier to put out. :-) Bryce _______________________________________________ clipart mailing list clipart@...330... http://freedesktop.org/mailman/listinfo/clipart

1 0

sp_document_lookup_id deprecated
by MenTaLguY 13 Jun '04

13 Jun '04

Hmm, I seem to be more productive than usual tonight. I decided to go ahead and lay down some of the groundwork for decoupling SPObjects and ids. To begin with, I've replaced sp_document_lookup_id with two methods: * SPDocument::getObjectById() * SPDocument::getObjectByRepr() They do pretty much what you expect; I've already rewritten all the code in the codebase to getObjectById(), or getObjectByRepr() where it was simple and obvious to do so. (getObjectById() should stay at least for some things like Inkscape::URIReference) As before, I've left sp_document_lookup_id as a deprecated wrapper, but it will go away soon. -mental

1 0

SPObject update method C++ification
by MenTaLguY 13 Jun '04

13 Jun '04

I finally got fed up with confusing the sp_object_{request,invoke} methods, so I gave them more descriptive names, made them real C++ methods, cleaned up internal comments, and documented them somewhat. Quick overview of what became what: > sp_object_invoke_write -> SPObject::updateRepr > sp_object_request_update -> SPObject::requestDisplayUpdate > sp_object_invoke_update -> SPObject::updateDisplay > sp_object_request_modified -> SPObject::requestModified > sp_object_invoke_modified -> SPObject::emitModified There are now two versions of SPObject::updateRepr() -- the two-argument version lets you specify a repr; the single-argument version works on the repr attached to the object (and defaults to flags of SP_OBJECT_WRITE_EXT if you don't specify). This means that most of the time when you just want to push changes down to the SPObject's repr, you only need to call object->updateRepr() with no arguments and it'll do the right thing. Other than that, given the massive scale of the change (see the ChangeLog), I've tried to resist making any other major changes. Given that changes touch a very large portion of the tree you'll all probably find yourselves rebuilding quite a lot of files. Sorry about that. ^^; Also note that if you've written any new code using the old C methods, it should still work for now (I left wrappers in place), but you will get deprecation warnings. So rewrite that soon, I'll be pulling the wrappers in a day or two. -mental

1 0

SVG::Parser issue with top level comments
by Bryce Harrington 13 Jun '04

13 Jun '04

Hi Peter, In testing out use of SVG::Parser with SVG documents created by Inkscape I found an issue. Inkscape (as well as other SVG editors like Sodipodi) insert a comment at the top level indicating the app that made it, but SVG::Parser appears to not like top level comments. I.e., for a document like this: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">  <svg id="svg1" ...> ... </svg> I get the following from running it through SVG::Parser 0.97: Can't call method "comment" on an undefined value at /usr/lib/perl5/site_perl/5.8.0/SVG/Parser/Expat.pm line 225. When I change line 225 from this: $parent->comment($data); to this: if ($parent) { $parent->comment($data); } The problem goes away. For my purpose, dropping comments is fine; I imagine there is probably a better solution, and would love to hear it. (I'm writing a validator for checking presence and validity of RDF metadata within an SVG file, for the Open Clip Art Library project, http://www.openclipart.org.) Hope this helps! Bryce

2 1