- Inkscape Devel - Inkscape Mailman

Re: [Gimp-developer] Re: [Inkscape-devel] common interface for graphics apps on the"free desktop"
by Sven Neumann 08 Feb '05

08 Feb '05

Hi, Michael Natterer <mitch@...85...> writes: > Perhaps we should just swap the Shift and Ctrl modifiers for display > scrolling to be consistent with the HIG and across graphics apps. Sounds like a good idea. Let's do this for 2.4. Sven

2 2

[Eng] [Fwd: OSCON Call For Proposals Closing Soon] (fwd)
by Bryce Harrington 08 Feb '05

08 Feb '05

---------- Forwarded message ---------- Date: Tue, 08 Feb 2005 09:34:25 -0800 From: Randy.Dunlap <rddunlap@...1...> To: eng@...1... Subject: [Eng] [Fwd: OSCON Call For Proposals Closing Soon] -------- Original Message -------- Subject: OSCON Call For Proposals Closing Soon Date: Tue, 08 Feb 2005 09:31:19 -0800 From: O'Reilly Conferences <elists-admin@...699...> To: rddunlap@...1... The Call for Proposals will end soon for the 7th Annual O'Reilly Open Source Convention http://conferences.oreillynet.com/os2005/ OSCON is headed back to friendly, economical Portland, Oregon during the week of August 1-5, 2005. If you've ever wanted to join the OSCON speaker firmament, now's your chance to submit a proposal (or two) by February 13, 2005. Complete details are available on the OSCON web site, but we're particularly interested in exploring how software development is moving to another level, and how developers and businesses are adjusting to new business models and architectures. We're looking for sessions, tutorials, and workshops proposals that appeal to developers, systems and network administrators, and their managers in the following areas: - All aspects of building applications, services, and systems that use the new capabilities of the open source platform - Burning issues for Java, Mozilla, web apps, and beyond - The commoditization of software: who and/or what can show us the money? - Network-enabled collaboration - Software customizability, including software as a service - Law, licensing, politics, and how best to navigate other troubled waters Specific topics and tracks at OSCON 2005 include: Linux and other open source operating systems, Java, PHP, Python, Perl, Databases (including MySQL and PostgreSQL), Apache, XML, Applications, Ruby, and Security. Attendees have a wide range of experience, so be sure to target a particular level of experience: beginner, intermediate, advanced. Talks and tutorials should be technical; strictly no marketing presentations. Session presentations are 45 or 90 minutes long, and tutorials are either a half-day (3 hours) or a full day (6 hours). Feel free to spread the word about the Call for Proposals to your friends, family, colleagues, and compatriots. We want everyone to submit, from American women hacking artificial life into the Linux kernel to Belgian men building a better mousetrap from PHP and recycled military hardware. We mean everyone! Even if you don't want to participate as a speaker, send us your suggestions--topics you'd like to see covered, groups we should bring into the OSCON fold, extra-curricular activities we should organize--to oscon-idea@...699... . This year, we're moving to the wide open spaces of the Oregon Convention Center. We've arranged for the nearby Doubletree Hotel to be our headquarters hotel--it's a short, free Max light rail ride (or a lovely walk) from the Convention Center. Registration opens in April 2005; hotel information will be available shortly. Deadline to submit a proposal is Midnight (PST), February 13. For all the conference details, go to: http://conferences.oreillynet.com/os2005/ Press coverage, blogs, photos, and news from the 2004 O'Reilly Open Source Convention can be found at: http://www.oreillynet.com/oscon2004/ Would your company like to make a big impression on the open source community? If so, consider exhibiting or becoming a sponsor. Contact Andrew Calvo at (707) 827-7176, or andrewc@...699... for more info. See you Portland next summer, The O'Reilly OSCON Team ******************************************************* To change your newsletter subscription options, please visit https://epoch.oreilly.com/account/default.orm and click the "Manage My Newsletters" link. For assistance, email help@...700... O'Reilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 ******************************************************* -- ~Randy _______________________________________________ Eng mailing list Eng@...701... http://lists.osdl.org/mailman/listinfo/eng

2 1

SVG tutorial translation
by Lucas Vieites 08 Feb '05

08 Feb '05

Hi list, In August last year (08/2004) we had a small thread in this list discussing new ways of making the translation process of the tutorials in svg format easier. TMX and XLIFF formats were mentioned and I remember talking about not having tools for these formats. A few days ago I read about the freedesktop.org XLIFF tools project: http://xliff-tools.freedesktop.org/wiki/ and googling a bit for "xml to xliff" conversion tools I found several initiatives (this one very nicely illustrated http://infomanagementcenter.com/pdfs/translation_wxml_tools.pdf). Question: Can we make use of these technologies for svg files? I suppose that because svg is a subset of xml we shouldn't have big trouble, should we? Cheers, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

5 4

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