Although I do not think that I need to apologize for being human, I
would like to take this opportunity to revise and extend my remarks.
James Richard Tyrer wrote:
> This is not going well.
>
This should have been taken as a cautionary statement. But, it is not
clear. I should have said more to express my frustration trying to do
what I thought should have been a simple task and that the comments I
made should be taken in that context. My apologies.
> I edited the file:
>
> $KDEDIR/share/apps/desktoptheme/Aya/widgets/translucentbackground.svgz
>
> to reduce the transparency to 75%. This is not simple since it was
> necessary to change the value for many elements.
>
> I would really rather use "Air" but that file in it is a $&#**^% mess.
Probably not the best choice of words. If I had not been having a bad
day and was not seriously frustrated, I would have used more objective
terms. Still I do have to say that the file in Air has serious issues
and could use some more work.
> Specifically, there is a lot of stuff in the file that isn't meta data,
> isn't definitions, and isn't paths or shapes. The file isn't a legal
> SVG file as it doesn't open in Squiggle. It also doesn't display
> correctly with the KDE3 KDE Plugin. It isn't a proper InkScape file
> either since if you clean it or save as a plain file, it doesn't work
> any more.
>
Unfortunately, these facts are true -- although the issue with Squiggle
could use some more elaboration.
<SNIP>
>
> Part of this could be improved if there were a way to manage
> translations and transforms in ink scape. But, much of it appears to be
> that some of the artists simply don't know how to use their SVG tools
> (or just don't bother with such details).
>
To make this clearer, I fault InkScape for much of the problem. It is
only at release 0.46 and it has many issues However, this means that
users of it need to know more and to learn workarounds. This also
requires more time and thought than might be the case if it was 1.0.1.
Some hints from a draftsman that knows more about how to use InkScape
than his limited ability as an artist. I am willing to provide
assistance but I have to say that it does not appear to be wanted.
IMHO, before committing an SVG file, made with InkScape, for release,
the author should make a copy and:
File -> Vacuum Defs
to remove *some* unneeded definitions. This is just a matter of
remembering to do it.
Unfortunately, there may still be issues. I have found many SVG files
(mostly icons) that contain groups of 0 files. These should be removed.
To do this, you have to scan through the groups and remove those that
don't contain anything. One does have to bother to to this, and it is a
bother to do it -- it can take considerable time. IMHO, these should be
removed when Defs are vacuumed -- this _is_ an InkScape bug.
There is no solution for the unnecessary or unwanted transforms. All
that can be done is to do part of it over.
This specific file also contains 2 SVG "text" objects which I do not
understand at all.
There is also a minor issue with the fact that InkScape doesn't
correctly round numbers. If you uncompress an SVGZ file and open it in
an editor, you will find things like:
-5.8042212e-6,14.999971
It should be obvious that this should be:
0, 15
The only workaround for this InkScape bug is to use a text editor. The
first problem should be simple to fix (in InkScape): numbers with an
absolute value less than a certain small value are replaced with "0"
(underflow fixup). The second one is not as simple although I note that
the math to solve this problem has been done. It refers to the
preferred values when converting from binary float to decimal float.
Finally, I always converted SVGs made with InkScape to Plain compressed
SVG files before I committed them. This _should_ only remove InkScape
specific meta data from the file. When I did this with this Air file,
the file was seriously corrupted and no longer displayed the same. This
could be an InkScape bug. Still, I believe that a developer is
responsible for their work. IMHO, this needs to be fixed somehow. If
it is an InkScape bug, then the artists need to develop a workaround for it.
And, as I said, there are issues with opening the file in Squiggle that
need some elaboration. Since W3C has not provided a validator for SVG,
the best test, currently, is to open the file in Squiggle:
http://xmlgraphics.apache.org/batik/tools/browser.html
The Air file in question fails this test. However, there are two parts
to this issue.
The first is that this is apparently not a legal SVG file and some of
the shadow is not displayed. Is this an InkScape bug, or a problem with
the file.
The second issue is something that I failed to understand. My (mostly)
bad here except that I have to say that if I hadn't had the other
problems that I probably would have figured it out.
> Perhaps with such SVG files, the feature which I want (adjustable
> transparency of transparent widgets) wouldn't be possible.
>
It appears that everything in the file in question except for the
shadows is white. I'm not sure that this is a good concept, but the
results are nice. I do have to say that if the "Opacity, &" in the
object had also been used that it would have been more obvious. It
appears to me that if Opacity is going to be user adjustable that it has
to be done this way.
In closing, I note that although I have been accused of making a
personal attack here, this is not the case. It is unfortunate when any
criticism that is not personal (no matter how stated) is taken this way
because it detracts from the task that we all need to work on which is
the continued improvement of the product.
My only interest is the improvement of the product. I am willing to try
to assist anyone that shares this interest.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
