[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: K-ARTIST: svg2png rendering
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-01-22 19:24:00
Message-ID: 200401222024.00514.frans.englich () telia ! com
[Download RAW message or body]

On Tuesday 20 January 2004 22:37, Kenneth Wimer wrote:
> * Wade Olson <wadejolson@yahoo.com> [Jan 20. 2004 18:04]:
> > The variables in the equation of svg quality we're discussing seem to be:
> > - A standard file format that itself needs to mature
> > - Software implementations (SodiPodi, Karbon, AI, etc) of varying degrees
> > of maturity - Rendering that is still maturing
> > - No standardized style guide
> >
> > So...why the problems? :)
> >
> > Thus, without seeing the results of this script, I like the direction of
> > this solution.
>
> Me too...to be honest, I have not had enough time to look at this
> either. I think that this is probably the best answer that I have heard
> yet.
>
> > Obviously, the solution of multiple svg files based on resolution is not
> > optimal, due to one of svg's selling points is the singular image file
> > without regard to size.  Because going that route would cause time and
> > work that would later be lost if any of the variables above changed and
> > resulted in acceptable quality, other options should be exahuasted first.
>
> Yes. I agree, but with some icons this will be a problem. Because of the
> numberr of different icons it is almost impossible to make "simple"
> graphics for all of them...think of text editors - how many "simple"
> text editor icons are possible? In the end, I agree that you are right,
> but I think that we will encounter many problems.

This is one of the lovely usability problems caused by KDE including tons of 
apps, ranging from tea cookers to multiple text editors.  The real solution 
does not only come from the artists but must be addressed globally. If the 
artists ensure the app icons in kdebase and the major apps from kdegraphics, 
kdemultimedia, kdepim and kdenetwork(core kde) is easily distinguishable it 
will one day be fine(and that is the day KDE does not include everything but 
the kitchen zink - because that's what causes this problem). I don't think 
it's simply possible to make 400 icons unique and distinguisable, but it 
doesn't matter because the problem is elsewhere - no one should be exposed to 
so much.

>
> > Can we test some of the problematic files with this new script to see if
> > any settings enhance the visibility at 16X16 (I don't have the means at
> > work myself)?  Can the person who reported the 16X16 issues (James Tyrer
> > I believe, but not sure) let us know if the new files appear more
> > suitable in their opinion?
>
> In 3-4 weeks a "Werkstudent" (a university student who is doing a
> praticum at SuSE) will be working for me. We will be testing and
> implementing a system at suse to use only svg graphics (using the
> scripts in kde, naturally :) I have thought about having the
> "Werkstudent" take this time to work on the SVG style guide, as well as
> testing and improving scripts, testing programs, etc.

As I see it, KDE's arwork problem has been caused by it being so informal, no 
community, no clear policies, no docs (roughly) etc. From time to time, 
artists from different companies have remotely worked on KDE.
In order to make the artwork situation "distributed" and failsafe, we need 
docs, community and a "system" which works without hired people. In other 
words, the best thing, for KDE as well as from a economic viewpoint from 
SuSE, it is best if your apprentice works /with/ and together with the 
community so the "base" is built at KDE. Not just /in/ the cubicle at SuSE, 
so to say ;-) But this is of course, my usual rambling.
In either case, considering the last weeks movements on this list, it looks 
very promising.


			Frans

_______________________________________________
kde-artists mailing list
kde-artists@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-artists
[prev in list] [next in list] [prev in thread] [next in thread]