[Clipart] transparent turkeys
Stephen Silver
ocalocal at btinternet.com
Fri Jan 7 08:07:11 PST 2005
Jonadab the Unsightly One wrote:
> "Stephen Silver" <ocalocal at btinternet.com> writes:
>
> > So the problem is much more widespread than I expected. But the fix
> > can probably be automated: replace every "fill-opacity:0.75000000;"
> > by "fill-opacity:1;" when it occurs on the same line as "fill:url".
> > This should make the image look the same as Inkscape 0.39 shows it.
> > I intend to try this out later.
I count 285 different files with this problem (or 487 if duplicates
are included).
But I've since found that there are files suffering from this problem
with fill-opacity different from 0.75, e.g., scorpion-md-v0.1.svg and
addressed_envelope_with_stamp_01.svg. This increases the total to 406
images (or 628 if duplicates are included), if the transparency really
is unintentional in all of these.
> Off the top of my head...
>
> perl -e '
> fix("openclipart-0.09");
> sub fix {
> my ($dir) = @_;
> for $f (<$dir/*>) {
> if (-d $f) { fix($f);
> } elsif ($f =~ /svg$/i) {
> open SVG, "<", $f; open TMP, ">", "temp"; my $line=0;
> while (<SVG>) {
> ++$line;
> if (/fill:url/) {
> s/fill-opacity:0.75000000;/fill-opacity:1;/g
For the more general case
s/fill-opacity:0[.0-9]*;/fill-opacity:1;/g
would presumably do it.
> print "$f line $line\n";
> }
> print TMP $_; }
> close SVG; close TMP;
> `mv temp $f`;
> }}}
> '
I found while looking at these files that some of them are also
suffering from Inkscape bug #1048268, so that they don't display
at all with Adobe or Batik. This bug can be fixed by removing all
occurrences of the line
inkscape:collect="always"
in files that do not have the string "xmlns:inkscape".
Another of the files (otto_02.svg) won't display because it uses
sodipodi:absref without xmlns:sodipodi - presumably another Inkscape
bug, though this one doesn't seem to have been reported, so it may
still exist in Inkscape 0.40.
--
Stephen Silver
More information about the clipart
mailing list