February 2005 - Inkscape Devel

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

Last minute file naughiness
by Jon A. Cruz 07 Feb '05

07 Feb '05

Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now. The one I am concerned about is in repr-io.cpp, in sp_repr_read_file I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.

6 25

line-height
by bulia byak 06 Feb '05

06 Feb '05

Peter: Please don't touch line-height property which I added to style.cpp. Reasons: 1. CSS2 says: "User agents must ignore a declaration with an unknown property." This means even if it is an invalid property, it will do no harm. It will just be ignored. 2. In SVG 1.1, line height is just given a fixed value equal to font-size. Our specifying a different value will have no effect whatsoever on compliant renderers. 3. SVG 1.2 indeed does not mention line-height for flowtext (as I wrote here some time ago). But it also proposes NO OTHER mechanism for controlling inter-line spacing. So I'm inclined to think that this is just an omission in the standard. If you're so worried by it, you can go to the W3C SVG list and raise this issue there. I'm reasonably sure that when made aware of the omission, the authors will reuse line-height as this is the most natural approach. 4. Without a way to control line spacing, flowtext is pretty much useless. So, if we cannot use line-height nor any other mechanism for that, I see no reason to continue working on flowtext. In other words, the choice we have is between completing the draft spec where it's most obviously incomplete, or just giving up and not having flowtext at all.

1 0

inkscape.svg vs plain.svg
by unknown＠example.com 06 Feb '05

06 Feb '05

Hi, I have been going through the openclipart.org flag collection yesterday, cleaning up metadata etc. There is a couple of issues I would like to bring up which I noticed in this process. The first thing is that images saved in sodipodi.svg/inkscape svg do not always render correctly with librsvg. I filed a bug with librsvg on this, but the reply I got is that this is caused by sodipodi/inkscape svg not being fully SVG compliant. Saving the flags with prolems as plain.svg made them all render correctly. Now the question is wether I should file these flags towards Inkscape as bugs, I assume so, as I think if we generate a file with .svg it should render nicely in all other SVG renderers? For some testfiles all the pirate flags in openclipart 0.10 misrender until resaved as plain svg. librsvg bug with some details here: http://bugzilla.gnome.org/show_bug.cgi?id=166385 The second thing which I have brought up with Jon Cruz and Bryce already is that there is some difference in metadata handling between svg_annotate/svg_validate and Inkscape. Inkscape do not recognize keywords set by svg_annotate and svg_validate do not recognize titles set by Inkscape for instance. Apart from these items, keep up the great work, Inkscape is really rocking! Christian

2 2

Bug 1114714
by Jon A. Cruz 06 Feb '05

06 Feb '05

To try to see if bug 1114714 is fixed, can someone on Win32 add some asserts and test things? Just go into src/dialogs/export.cpp and before each call to *_set_text add warnings just before each? if (!g_utf8_validate(variableAboutToCallSetWith, -1, NULL)) { g_warning( "variableAboutToCallSetWith IS NOT UTF-8" ); } Then try some file/directories with umlauts in them? Thanks.

1 0