The KOffice developers have been making outstanding progress towards their goal of creating a useful, powerful and reliable KDE office suite. But whereas the technology
in KOffice has been steadily improving, its visual appearance has not been keeping pace. To address this issue, the KOffice development team is pleased to announce the KOffice Icon Contest. This contest is being held to ensure that KOffice 1.3 not only works better but also looks better than any previous release.
Aim of the KOffice Icon Contest
One of the goals of KOffice 1.3 is to deliver an improved user interface that compliments the progress being made by the KOffice developers in the code. Icons and related artwork are a vital part of that interface improvement.
Entering The Contest
The KOffice Icon Contest is open to everyone. All submissions from individuals or teams of artists that meet the guidelines for the contest are welcome.
To participate, the following materials should be sent as a single submission to the contest organizer Ismail Donmez ([email protected])
and the KOffice users list ([email protected]):
- A single screenshot showing all of the icons in the submission. The individual icons in the screenshot should be either 22x22 or 32x32 pixels in size.
- An FTP or Web URL from which the icons can be downloaded. Please do not email the icons themselves!
The Icons
The icons should be provided in a single compressed archive containing icons for each of the following KOffice applications:
- KOShell (Koffice work area)
- KWord (Word processor)
- KSpread (Spreadsheet)
- KPresenter (Presentation program)
- Krita (Bitmap graphic editor)
- Karbon14 (Vector graphic (SVG) editor)
- KFormula (Mathematical formula editor)
- Kugar & Kugar Designer (Report creator)
- Kivio (Flow chart and diagram editor)
The icons for each application should include:
- an application icon which will appear in the KMenu and elsewhere
- toolbar and menu icons
- icons for use in dialogs such as the new document and configuration dialogs
All icons must be supplied in both 22x22 and 32x32 sizes. The application icons must also be supplied in 48x48, 64x64 and 128x128 sizes. The preferred icon format is SVG though PNG is also acceptable. The preferred icon style is Crystal SVG.
Artists should use KOffice 1.2.1 or later (e.g. KOffice from CVS) in creating their submissions. You may further wish to review the old KDE Icon Style Guide although portions of it have now been obsoleted with the adoption of Crystal SVG.
Licensing of Submissions
Just as with the official KDE icons, all icons submitted to the contest must be licensed under the LGPL. All submitted icons must also belong to the artist(s) who submit them. Icons belonging any other 3rd party will not be accepted.
Contest Timeline
The KOffice Icon Contest will be open for submissions for two (2) months starting February 20, 2003. At the end of those two months all of the submissions will be examined by KOffice developers and users and the winning submission will be announced by the KOffice development team a week later.
The Prize
The award for winning the KOffice Icon Contest is to have your icons distributed along with KOffice as its official icons and an acknowledgement of contribution in all of the KOffice programs.
Comments
If we used sodipodi to make the icons, would we be automatically disqualified?
If sodipodi has onerous licensing that impacts the license and rights of use of the icons that you create with it, then you better be careful. Otherwise you must make sure you comply with the above rules.
sodipodi is Free software, GPL v2...
Does that mean the icons you create with it are automatically GPL?
The GPL restricts *code* derived from GPL software, not *documents* created with GPL software. I can license art I create with sodipodi, the GIMP, karbon, kontour, etc. however I please.
I wasn't asking about the licensing; I was referring to this line:
"Artists should use KOffice 1.2.1 or later (e.g. KOffice from CVS) in creating their submissions."
which seems to imply that they want you to use KOffice programs to create the icons, but maybe I am reading it wrong...
Oh dear no, I doubt that's what it means. It means that you should create icons targeted at KOffice 1.2.1 or later.
Yeah, that makes much more sense. Good luck to all participants! :)
It says "*in* creating their submissions" not "*for* creating their submissions",
so I guess this means: You should make all Icons necessary for the functions
of KOffice 1.2.1. i.E. If there is no save button in KOffice 1.0 but a
save button in KOffice 1.2.1 then you will have to make an Icon for the save
button.
LMCBoy said:
"The GPL restricts *code* derived from GPL software, not *documents* created with GPL software."
No, this is incorrect. The GNU GPL derives all its power from copyright law. The GNU GPL cannot leverage powers beyond what copyright law grants. The reason the GPL doesn't set terms on the licensing of one's Sodipodi drawing is because it cannot. This is explained in .
I have no access to the HTML encoding, so please forgive the plain text URL.
Hmm, as far as I can tell, you just repeated what I said: the GPL restricts code derived from GPL'd software, not documents created with GPL'd software. What part of that are you saying is incorrect?
When I first read what you wrote, I think I misinterpreted it. I thought you meant something else by "code" and "documents". Reading it differently now, I see that you could have meant derivative works by "code", and output from a program by "documents". If this distinction is what you were indicating then we agree on this point and indeed this was mostly repetition. My apologies for the misinterpretation.
"anon" asked:
"Does that mean the icons you create with it [sodipodi, a GNU GPL-covered vector drawing application] are automatically GPL?"
No. See http://www.gnu.org/licenses/gpl-faq.html#GPLOutput for the FSF's take on this. You control the licensing of your drawings made with Sodipodi (or any other drawing program, for that matter).
In short, copyright law doesn't grant the power you're getting at. There is one rare exception, but even in that case it is easy to work around and claim all copyright power to the work you made with the program.
Speaking of SVG tools (sodipodi). Why is it that when KOffice is discussed it always omits Kontour and Karbon? Are they not part of KOffice? Are they being worked on? Where does one find out this info, I would think that the dot would talk about it.
Since the Kontour and Karbon websites are rarely updated it seems that development is slow....
Kontour is dead, Karbon will be part of KOffice 1.3. Blame its authors for not updating the website tho -- they're busy with coding :)
I can't believe KIllustrator is dead. It used to be so good!
There are not many people working on Karbon14. But it seems to me they all work on Kexi too and prefer to do that right now. So instead Kexi development is really fast now. If somebody wants to help out I'm sure they would appreciate it.
Yes, any help is appreciated :)
Cheers,
Rob.
I've just updated koffice.org to remove the Kontour pages, and added a tiny bit of info about Karbon. Thanks for pointing out.
No sodipodi does not have any license restrictions on artwork created by it.
it's funny....laugh
am I the only one who got the gnome vs kde joke?
really, it wasn't meant as a joke; I just misunderstood the part where the article said "you should use koffice-1.3 in making your icons". This just struck me as an odd requirement, but I now understand that they meant "in selecting the set of icons to create, use recent KOffice as a guide" (see other thread).
...please someone come up with anti-aliased Bold and Italic buttons.
Let me correct you:
For the love of GNOME..
(That was what you were trying to say, right?)
I notice this too ... it makes me close Kword/koffice and startup OpenOffice I'm willinng to bear 10 minute startup times and massive swapping just to avoid those glaring horrid Koffice icons!!!
IOW This contest is gonna add some beauty to the wonderful Koffice Suite. Go Artists!!
WOW!! How lazy are you? Geeze!
KOffice is certainly the next area that requires a big effort to reach a status where Office users feel at ease with it and consider it stable/usable. It seems to be making quite a lot of progress lately, which is just great! Icons can only help people feel good using these applications, so this is certainly a good idea.
There is, however, something that I'd qualify as even more important: Kivio has been there for quite a while, and the code seems to be mature enough. The only thing that prevents anybody from using it seriously, though, is that it is delivered with a ridiculous number of stencil sets.
I personally don't want to have to buy stencil sets from TheKompany, but I'd agree to spend some time in creating one or 2 sets (easy to do, since it is a simple XML format).
I once came accross an open-source project that allows to turn xfig libraries into kivio stencils (http://sourceforge.net/projects/xfig2sml/). It does much of the initial job, the only problem being that there are no connection points, but this is fairly easy to add.
If anybody had the means of organizing work so that volunteers take care of one or two sets each, I think we could turn kivio into something very usable very quickly.
> means of organizing work
How about the koffice-devel mailing list?
start a thread :)
Like this one? http://lists.kde.org/?l=koffice&m=102267883117074&w=2
It would be fantastic if you could provide additional stencils for Kivio. The KOffice mailing lists will have an open ear for that :-)
One of the best secrets of KOffice 1.2.1 is that Kivio has a Dia stencil import filter. Two drawbacks: It's told to only work with 75% of the Dia shapes and you can only work with one collection active at one time. For me it was as simply as "cd $KDEDIR/share/apps/kivio/stencils;mkdir Dia;cd Dia;ln -s /opt/gnome/share/dia/shapes/* ." to get them offered to me at next Kivio start.
Has it ever been discussed if Scribus should be part of KOffice?
It's a great DTP program! I've used it a bit and it is really a killer application!
http://web2.altmuehlnet.de/fschmid/
use it *a lot* and reort back :-)
I have used it a bit more than a bit... and I can assure you it's progressed a lot. The PDF output quality is really good compared to those of koffice. One of the main problems I find actually in koffice is the way they embed the fonts... TTF fonts look like crap on Acrobat Reader...
Actually, they look great and are the standard fonts
included in PDF docs in Windows and Mac worlds, along
with OT fonts.
You mean you are able really to do this ???:
1) Write a document in kword using Comic Sans
2) Export To PDF embedding fonts
3) Open in Acrobat Reader and say: it looks nice!
I tried... and the fonts are embedded as Type 3 (see in Acrobat Reader font properties)... which looks ugly in Acrobat. Yeah, I know it looks great in kghostview... but not everyone in this world uses KDE. And you call it a "publishing tool"...
Now, afaik, the only solution is to embed those fonts as Type1. OpenOffice and Scribus do it properly. Kword can't seem to deal with it. Why not import Scribus' code?
Please let me know if I said something wrong above there. I'm not an expert in fonts and PS/PDF format.
KDE has a really great API for supporting printers (CUPS PDF-export PDF-email etc.) the only problem is there's not really one app out there that can actually print nice output to said framework ...
For all intents and purpose KOffice DOES NOT FUNCTION for printing. It's thje largest "blocker" preventing the app from "breaking out" into big time use like OpenOffice (which doesn't work to well for interactive use but prints and imports/exports nicely).
KDE and Linux printing in general SUCKS HORRIBLY. We've made it look good, not crash, functional e-mail and browsers ... even some decent stabs/starts at office apps. What's missing is huge though:
- good quality printing ... postscript is still patented and ghostscript is weak version of that ... (no easy screen to print equivalence unless you have postscript in the display too).
- a good native well suported multi-media format and framework for supporting it anbd plugins for crap commercial closed media (ASF, WMV, MP3 etc ...) ARTs is getting old
Gnome does a bit better job on th output but has a crappy API/framework for allowing apps to print to devices .. KDE's is best bar none on that ...
Errm no *you* are wrong ;-)
Or there's something wrong with your set up ... but you are wrong on certain points.
CUPs rox ... LPRng is good too but everything is gravitating towards supporting CUPS and using it as a print interface to various other services (e-mail, DAV uploads, PDF and XML-FO rendering etc.) Magnificent! This is one are where Unix is WAY OUT IN THE LEAD re: windows ... Apple is right along side us ;-)
For the output onscreen/onpaper well, yes, we are weaker ... and certain Postscript technologes are patented - but not for long (a few key patents expire 2005 I think), and besides, much like X where XFree is starting to beat out commercial variants ... ghostscript is simply the best and most excellent postscript rendering environment out there in many ways. And "Postscript in the display" is not dead.... see sourceforge for various GS extensions for X.
Re: your setup:
Check if print previews in various applications are working and give you something that looks good. If print preview looks crappy then there's something broken with ghostscript/Xft/your KDE font setup.
If print preview looks good and printer output is crappy then it's your print drivers (Foomatic, GimpPrint etc.) Be sure ghostscript, print drivers, cups and all your fonts are as new and as extensive as possible!! Install everything!!
Here are the things that are wrong or need work:
- seamless screenfont/printfont display. We mix Type1, TrueType, Post/ghost, etc. it would be nice if Xft and fontconfig were as great a fix for printing as they are for X display fonts. Unix/ X really has grown up to be like commercial graphics power house OSes and apps re: *display* (AA, Xrandr, etc.) but for printing we have a radically separate subsystem.
I guess some might contrue this as an advantage ... (separate teams and tasks) but while it's possible to take say a Thai, or Indic font (TrueType) dump it into my ~/fonts/ dir and have beautiful Thai document display (assuming I've got encoding working right etc.) it is essentially impossible to have such a document display and print well automagically and out of the box ... i.e. useres can't deal with this ... printing and fonts is still a sysadmin type problem.
- Print speed. Since there's no tight integration of display and printing even printing a small simple document causes applications to lock up at times (while they wait for "background printing" to happen) and enormous processing power is used even just to print simple text. This is a reall pain if you are doing print previews on your laptop on battery power!!
- multi-media formats: yes bad support but not our fault! plus there are these fixes
* ALSA (linux only though)
* gstreamer (nicer if ported to Net|FreeBSD/Darwin etc.)
* Helixcommunity
* OGG/Vorbis (yeah baby!!)
Anyway multi-media is outg of scope here since I'm talking about printing :-D
I agree with everyone about the KOffice icons (especially the printer icon that pops up while the document is prepocessing/printing).
It appears to me that the Qt PostScript driver simply doesn't work.
I tried your experiment. I'm not quite sure what OpenOffice did, but KOffice has this error message in the PS file:
% No embeddable font for ComicSansMs found
Suggestion: then don't embed it.
Why does it embed the fonts? Or, at least, were do you turn embedding on and off?
That is really a rhetorical question. There is a box to uncheck in qtconfig but it doesn't appear to help the situation. And, in any case, there is no reason for fonts to be embeded if you will be printing the PS file on the same system.
And the experiment resulted in substituting Helvetica for Comic Sans MS. And then when I made a PDF, the margins were screwed up.
Repeat: PostScript driver is BROKEN.
Solution for embidding a TrueType font is supposed to be a scalable Type 42 font. Perhaps this font doesn't allow embedding, but that is a problem for GhostScript. The solution for the PostScript dirver is simply not to embeded it and list it as a system supplied font.
--
JRT
Scribus has really made astonishing progress.
It definitively should be a part of KOffice!
Perhaps some UI adjustments will have to be made
in order to make it similar to the other KOffice
applications.
If some KOffice developers are reading this:
Please get in contact with the developers of Scribus.
This would further improve the power of KOffice.
Imagine this:
Bitmap Editor, Vector Editor, DTP, Word-Processing,
Spreadsheet, Database, integrated PDF Generator, ... all
for free. All cooperating with each other. All with a similar
UI, similar Shortcut-Keys,.. This is not too far away.
Now M$ Office, Adobe, try to match this.
It's not really the task of the Office team to try to adopt other projects.
This is still the task of the owner of the product, because it must be in the interest of the programmer to be part of the project.
So if the Scribus author would like to join, I'm pretty much sure we will let him do so.
OTOH, Scribus is not a KDE application yet, it's a native QT app. So it would be a harder change for Scribus to fit into KOffice.
I personally don't think it's useful to have apps in one office suite which don't ingtegrate, just to tell that we have more apps in our suite than blabla.
The apps in a suite must fit together, otherwise it's not a suite.
As you know, Quark XPress is very expensive. Sribus may be mature enough for newspapers, writers and printers to migrate to GNU/Linux. People are tired to pay taxes to Quark/Microsoft/Adobe/Whatever. We need more freedom.
No matter if Scribus is a Qt application only. The history of GNU software shows that you sometimes have to make exceptions. The only matter is flexibility.
Come on: your team will never be able to release a software like Scribus in KOffice. So why hide and pretend it is not compatible. The simple fact that scribus is free software, makes it a potential candidate for integration into KOffice.
What I would suggest is an "Scribus output plugin" for kword... the PDF generation would improve greatly. I just wonder how difficult would this be to implement. Then, if Scribus was integrated, one could in one-go do: kwd->scd->pdf
How about just finding out what makes the pdf output of Scribus so great and fixing KDE's output to match. That way all KDE applications would benefit, since making PDFs is part of the print system and avaliable in every app.
KWord is supposed to be able to do DTP tasks, with its frame layout features. It would be kind of silly to have both KWord and Scribus in KOffice at the same time.
The trick seems to be that KOffice uses QT in order to generate the postcript files, which has certain limitations while embedding fonts. There was some long discusson about it in the kde-devel threads ... and the solution doesn't seem to be easy (too much work to be done).
Now... KWord is supposed to be working as Desktop Publishing tool, but... what about "retouching" or improving documents? I'm speaking about Acrobat(Distiller, writer,.. whatever you call it) features such as adding notes or small touches to pdf files (really useful for researchers), hyperlinks, or even importing pdf files.
I doubt that with the current kwd file structure every single PDF trick can be represented. This means that it would be easy to convert kwd->pdf, but not the other way around: pdf->kwd.
Scribus has the advantage that is oriented specifically to work with PDF's, so the document format represents every single detail (supposedly).
Now... merge Scribus + Kword in something like, KwordCribus ;-) and... oh man, ... I need it.
Please design a new Konsole icon. The blue is wrong and bad for usability. I always get confused when I alt-tab and don't know what window to switch to because all the icons look the same! And I don't see the selection anyway because it's yellow on gray!
I agree completely! Why must all icons be blue now? I can no longer distinguish between Konqueror and Konsole. Why can't Konqueror be green-blue and Konsole black like it used to be.
Is it so that everyone can feel how it is to be color-blind?
why is kexi not part of the content?
Because we are not sure if it will be a part of Koffice by 1.3 yet. And it now uses standart koffice icons ( load/save etc ) .
hi
well, i'm quite sure that kexi will be a part of koffice 1.3 but the main reason is, that we have got our "own" artist (Kristof Borrey known from iKons) who creates all icons we need :)
e.g. there is a svg icon avaible under http://luci.bux.at/kexi.svg all other kexi-only icons are created by him as well. the rest are usual koffice icons.
and i think that kristof has very good skills.
lucijan
'The preferred icon format is SVG...'
And that means I should use Adobe Image Ready which is used by Crystal icon team? Mo way. Because of Adobe (and its attack on KDE because of the name of the KOffice applications) and because I don't use Windows/Mac.
Sodipodi & other open source apps are not ready.
'The preferred icon style is Crystal...'
Why this contest at all?
You have Conectiva/Everaldo Crystal Icon set. Its style is Crystal. Which is BTW default. Use it. Authors just have to finish office icons. And there are 6-7 in the team. It shouldn't be a problem.
.....................
P.S. IMHO Koffice icons should not be created in Crystal style because of the usability issues. Take a look at AbiWord and see what a really proffessional office icons look like.
Cheers,
antialias