[Clipart] 13 logo contributions

[Jonadab the Unsightly One]

"Jonadab the Unsightly One" <jonadab at bright.net> writes:

> Bryce Harrington <bryce at bryceharrington.com> writes:
>
>> I won't have time to look into it any time soon - I'm tied up with
>> Inkscape and Xorg presently; if it is something SVG::Metadata needs to
>> account for, I'd appreciate a patch.
>
> I might be able to put together a patch if I know what exactly needs
> to be done, in terms of precisely which element needs to be parsed for
> commas or whatever.  (Splitting on commas is very easy; knowing where
> to do that is the tricky thing.)  Does someone have a URI for the
> specific SVG file that's triggering the problem?

Sorry it took me so long to get to this, but the following seems to
work.  It only tries to parse the subject as a flat textual delimited
keyword list if it fails to find the rdf:Bag, so the keyword parsing
that is already working (which relies on the Bag) will continue to
work.  I've tested this with inkscape metadata containing in the
keywords field a comma-separated list, and it seems to work.

So, here's a patch...

--- Metadata.pm.0.15	2004-08-11 01:11:39.000000000 -0400
+++ Metadata.pm	2004-09-01 09:06:51.000000000 -0400
@@ -321,7 +321,17 @@
 	    $self->{_keywords} = { $subjectwords => 1 } ;
 	}
 	$self->{_subject} = undef;
-    } else {
+      } elsif ($self->{_subject}) {
+        # Inkscape gives the user a single text input for this and
+        # does no parsing, so we're liable to get keywords separated
+        # by commas, semicolons, colons, spaces, ...  This is our
+        # attempt to do the best we can with that:  we'll split on
+        # non-word characters except for hyphen and apostrophe:
+        $self->{_keywords} = { map { $_=>1 } grep { not /\A\s*\Z/ }
+                               'improvisedkeywordparse',
+                               split /(?![-'])\W+/, $self->{_subject} };
+        $self->{_subject} = undef;
+      } else {
 	$self->{_keywords} = { unsorted => 1 };
     }