The KOfficedevelopers 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.

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 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.

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.

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.

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....

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.

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).

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.

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.

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...

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 ...

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

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.

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).

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!

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.