- Inkscape Devel - Inkscape Mailman

SVG::Metadata 0.21 released
by Bryce Harrington 08 Feb '05

08 Feb '05

Version 0.21 of SVG::Metadata has been released to CPAN tonight. Changes: * Added a metadata edit feature to svg_annotate. The script now accepted a '-e' parameter which allows altering the metadata in an SVG file. It does this in the crudest possible fashion: It parses the file for metadata, makes the modification you request, then deletes all the metadata, then re-inserts the metadata back into the file. Beware! This could really fsck up your SVG files, make sure to keep backups before running, etc. If it does, send me a bug report. * Fixed bug where SVG::Metadata parses the publisher info incorrectly, causing further writes to display it as HASH. * Entirely removed an if clause that was causing 'improvisedkeywordparse', 'HASH', etc. to appear in keywords. This was just a hack around a bug in Inkscape that's been fixed for a few releases anyway, so the code's not that useful. * Fixed the problem that was causing the above bug to begin with. It now assumes the 'subject' field is proper RDF instead of permitting freeform text, as Inkscape used to do long, long ago. * Removed the default values for the cmdline options for license and title. Now they default to blank (''). This was done so that when running `svg_annotate -e`, it won't change contents of your SVG metadata to the defaults. * Changed the default for title from 'Clipart by <AUTHOR> - <FILEBASE>' to just '<FILEBASE>'. Enjoy! Bryce

1 0

Unable to open SVG in Inkscape
by Christian Fredrik Kalager Schaller 07 Feb '05

07 Feb '05

Hi guys, The attached file (our company logo) renders fine with librsvg, but inkscape seems unable to even load it. Any ideas why? Christian

4 6

"Bug" with command line export
by jiho 07 Feb '05

07 Feb '05

Hi all, first message on this list (following a first chat on jabber, lots of "first" today). I found a "bug" using inkscape 0.39 at the command line under mac (sorry but I can't spend all the necessary time to recompile CVS on my mac and I don't think this was mentionned before, so this wasn't fixed either probably). Anyway I wanted to export some file.svg to file.png: inkscape -d 72 -b white -e file.png file.svg as long as file.png does not exists, everything is fine. when file.png exists i receive a long list of errors starting like this: (process:12102): Gtk-WARNING **: Screen for GtkWindow not set; you must always set a screen for a GtkWindow before using the window (process:12102): Gtk-CRITICAL **: file gtkiconfactory.c: line 1224 (gtk_icon_size_lookup_for_settings): assertion `GTK_IS_SETTINGS (settings)' failed (process:12102): Gtk-WARNING **: gtkstyle.c:2037: invalid icon size '4' (process:12102): Gtk-CRITICAL **: file gtkstyle.c: line 1903 (gtk_style_render_icon): assertion `pixbuf != NULL' failed (process:12102): Gtk-WARNING **: Theme engine failed to render icon (process:12102): Gdk-CRITICAL **: file gdkpango-x11.c: line 53 (gdk_pango_context_get_for_screen): assertion `GDK_IS_SCREEN (screen)' failed [....long list of the same type of errors...] I imagine it is because inkscape tries to open a GTK windows asking me if I want to overwrite the existing file.png. a GTK window can't be opened because I launch this from the Terminal.app (and X11 is possibly not even started). But the point is that: -even if I run this command line on an xterm inside X11, I get the same errors -even if I add the "-z" option to the command line, I get the same errors If I try to export the same file from inside inkscape i got the correct dialog and I can export my file and overwrite the existing one without problems. So I think that on system where GTK is not "native" (I think it's a bad word but maybe you can understand what I mean) GTK popup windows like this can't be opened. Therefore, I think that, to make this command line tool more robust, it might be remplaced by a text sent to the standard output (terminal) asking if the user wants to overwrite the file or not. at least when the -z option is explicitely mentionned. thanks in advance for any help with this. ask me for precisions if yo need to. JiHO --- Windows, c'est un peu comme le beaujolais nouveau : a chaque nouvelle cuvee on sait que ce sera degueulasse, mais on en prend quand meme par masochisme. --- http://jo.irisson.free.fr/

3 3

Keywords issue between OCAL and Inkscape
by Bryce Harrington 07 Feb '05

07 Feb '05

Uraeus pointed out that the keywords added by svg_annotate don't show up in Inkscape. It looks like svg_annotate is inserting the keywords correctly, more or less. (It doesn't add id numbers to the elements, but I'm fairly sure that's not required anyway.) The problem appears to be that Inkscape is not reading the keyword info in. It's simple to check this: * Start up a new drawing in inkscape * Draw a circle or something * Go to Document Properties > Metadata and type "asdf" for a keyword * Save the file and exit inkscape * cat the saved file and note that asdf is in the keywords section * Load the file in Inkscape again * Go to the Document Properties > Metadata page. No keywords shown. I've submitted a bug report on the above. Bryce

2 1

Fwd: [devel] New Gnome Project (Clipart Browser)
by Alexandre Prokoudine 07 Feb '05

07 Feb '05

FYI. ---------- Forwarded message ---------- From: Mike Powers <mjpowersjr@...400...> Date: Fri, 28 Jan 2005 12:14:12 -0500 Subject: [devel] New Gnome Project (Clipart Browser) To: paolo.bacchilega@...695..., criawips-devel@...448..., miguel@...653..., support@...696..., scribusdocs@...84... Hello, My name is Mike and I have been using Gnu/Linux teamed with Gnome for my main desktop at home. During the past year as I have used linux for Multimedia, Internet/Email and Office tasks, I have noticed a few areas where I the Linux desktop seems to be lacking.Please correct me if I am wrong, but their seems to be no easy way for the average user to insert clipart into typed documents.Most all Gnome Office related applications allow insertion of pictures via the File Open Browser window, but it makes it hard for the average person, without understanding of file systems, to insert clipart. I plan to (hopefully with the help from others ;-) ) develop a standalone program (or library) that other applications can call upon, to aid in Inserting clipart. I am planning on using the source code from the current release of gthumb as a starting point for this project, and have some ideas listed below. If this is something that you would be interested in using as a part of your applications, or have ideas, suggestions, ect. please let me know. Also, I have done some initial mockups, without reading HIG yet. (sorry, but their bitmaps until i can leave work and get a chance to convert them.) http://www.sharelinux.org/clipbrowser/ Here is a semi-organized list of thoughts on the project: Program Input Options: -Filters on what categories to make visible -Import Images to the clipart gallery via command line. Program Output Options: -Clipart Browser can return a list of selected files. Design Problems needed to be solved (I need your input :) ): -What would be the preferred way to call the browser. -Where should the clipart be stored by default? -What permissions should people have for the clipart? -How to approach importing clipart. -What external websites should be queried for the websearch feature. (google...) -Is their even a need for image conversion in the browser utility? -How would they be implemented into existing programs. Maybe someone is already working on this and I'm just ignorant to the fact, To give you a background on my coding experience, I have taken classes in c++ about two years ago, and recently started reading up on the language again. I have never started a major project before, only pieced together small programs to "get the job done" so any help would be appreciated. I have wanted to contribute to the Gnome desktop for quite some time now, and thought a Project like this would be a good place to start, as I would imagine much of gthumb's code could be used in this project. -thank you. -Mike Powers. (mjpowersjr at gmail dot com) _______________________________________________ criawips-devel mailing list criawips-devel@...448... http://lists.nongnu.org/mailman/listinfo/criawips-devel

1 0

[jonadab@...581...: Re: [Clipart] character coding]
by Bryce Harrington 07 Feb '05

07 Feb '05

Jon, can you give some advice on this one? ----- Forwarded message from Jonadab the Unsightly One <jonadab@...581...> ----- Date: Mon, 07 Feb 2005 00:01:33 -0500 From: Jonadab the Unsightly One <jonadab@...581...> To: clipart@...330... Subject: Re: [Clipart] character coding Nicu Buculei <nicu@...398...> writes: > i remember we talked several months ago about this problem and IIRC is > generated by the upload tool. The upload tool's approach to character encoding is completely naive: it just assumes that whatever form it _receives_ the data in is suitable also for _storing_ it. (At least, that's how it's supposed to work.) It doesn't care whether the data is ISO-8859-15 or what. (For the filename, it uses only 7-bit printable ASCII characters, but it doesn't remove non-ASCII characters from the actual metadata or change them in any way; it just represents them as underscores in the filename.) It does need the data to be in some encoding that encodes certain characters the same as in ASCII -- mainly the characters that have special significance to XML, such as < and > and / and so forth, plus the letters in certain tags (s, v, g, r, d, f, and so forth). But those are all 7-bit characters. It won't be able to handle EBCDIC data, for example, but any sane, ASCII-compatible encoding should work just fine. In theory. I do not off the top of my head know what character set ISO-8859-15 is, other than that I think all the ISO-8859-anything charsets are fully ASCII-compatible in the bottom seven bits. And it was my understanding that UTF8 has this property also. So in *theory* it should Just Work (in the sense of not making any undesired changes). The one problem I can think of off the top of my head that could occur with this is if the data that the upload tool receives is not consistent in its encoding -- e.g., if the SVG it receives is in one encoding, and the metadata the user fills in on the form is sent by the browser in a different encoding. Is it possible that that is what happened here? > is saved as ISO-8859-15 I was unaware that the filesystem maintained character-set metadata. What does it mean for a file to be "saved as" ISO-8859-15? How can you tell what character set a file uses, apart from looking at the charset information in the XML declaration? More to the point, how can the script detect what encoding the information it's receiving is encoded in, short of asking the user? Maybe we need a Unicode guru. I'm not one. Alternatively: does RDF allow for non-ASCII characters in the metadata to be encoded as entities? Could we just use something along the lines of HTML::Entities to encode it (so that e.g. the problematic character in the file in question would become é or somesuch)? Wouldn't that render the character encoding basically irrelevant? -- $;=sub{$/};(a);=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/ _______________________________________________ clipart mailing list clipart@...626... http://lists.freedesktop.org/mailman/listinfo/clipart ----- End forwarded message -----

1 0

Next up URI madness!!!!
by Jon A. Cruz 07 Feb '05

07 Feb '05

Well... now that 0.41 is all chilly and such, time to start thinking of next things to do. One of the ugly, sneaky, subtle probleme we have is URIs. What is a URI? Do we want to use URIs all over? Is there something else we want to use instead? Some places we have a 'gchar const *uri', Inkscape::URI, and 'gchar const *filename'. The first (sometimes) is some string representation that might be a URI The second is a class for a 'URI' as defined in RFC 2396 The third is just a local file path. One problem is that often the first and third get mixed up. Another problem is that URI's are supposed to be encoded in escaped ASCII, and all the glib routines like g_filename_from_uri expect properly formed URI strings. So there are things we use as file paths and such that break when treated as pure URIs. Soo....... what should we do about this mess?

1 0

Inkscape 0.41pre2 posted
by Ted Gould 07 Feb '05

07 Feb '05

Inkscape 0.41pre2 has been posted here: https://sourceforge.net/project/showfiles.php?group_id=93438&package_id=991… It is currently expected that this will be the last prerelease before 0.41, please check it for any bugs so they won't make it into 0.41! --Ted

1 0

Object Rotation
by Aaron Spike 07 Feb '05

07 Feb '05

I just wanted to say that having the degrees on the taskbar follow the objects rotation is fantastic. It makes 1 and 2 degree snapping very useable for me. I can even get 72 degrees now. :) Thanks very much. And I just found another really fun use for inkscape: creating gDesklets <http://gdesklets.gnomedesktop.org/>. A little XML, a little python, an SVG and wahla instant eyecandy. Thanks again, Aaron Spike

1 0

AI Input
by Ted Gould 07 Feb '05

07 Feb '05

There is a bug in the .inx file for AI input. One of the attributes got changed to the wrong name. It looks like it happened when changing a bunch of other values. Without the fix AI input will not work unless the extensions directory is put into the path. I've attached a patch, which I believe should be put in for 0.41. --Ted

2 1