Thanks for contributing an updated comets.dat file.  

Please have a look at the file README.ephemerides, which ships with KStars, or see here:
http://websvn.kde.org/trunk/KDE/kdeedu/kstars/README.ephemerides?revision=623819&view=markup

The JPL website is referenced in that file, and in addition, it expains that some entries in ELEMENTS.COMET need to be removed, because they reference comets that no longer exist.  The README file specifies comet Shoemaker-Levy 9 (which crashed into jupiter in 1993), as well as all the SOHO and SOLWIND comets (which are sungrazing microcomets, discovered as they plunge into the Sun). 

Actually, I need to update the README, because in addition to S-L 9, there are other comets in ELEMENTS.COMET that no longer exist:  all of the comets whose designation begins with "D/" instead of "P/" or "C/" are "disappeared" comets, and should be removed before being used in KStars.

After I removed all of the D/ comets, as well as the SOHO and SOLWIND comets, the number of comets is reduced to 1409, which is still about 50 new comets.

Regarding the column formatting issue, it looks like JPL has modified its file format, because it used to be the case that no formatting changes were necessary to use the file in KStars.  For 4.0 I will try to come up with a more bulletproof file parser, but for now we'll need to remove three spaces from each line as you suggest.

I will update the comets.dat file in trunk, the 3.5 branch, and at the "download new stuff" location.  I first will need to update the asteroids file as well, which involves a bit more work (see README.ephemerides for details).  I'll close the bug when this is done.

Note also the large number of comets in ELEMENTS.COMET with a large negative value for the modified Julian day.  Unfortunately, these numbers are not parseable by the current code, and so these entries will also need to be removed from the list.  These comets exist in the current version of comets.dat, but because the MJD value is truncated, their positions are totally wrong (I have only just discovered this, as a result of this bug report).

The negative MJD values for these comets indicate that their last perihelion passage was a long time ago (as reflected in the dates encoded in their designations; e.g., comet C/-146 P1 went through perihelion in the year 146 BC!  Most of these historical comets are known only from historical records, mostly from Chinese astronomers.  I seriously doubt that they are observable today, so their orbital elements are very uncertain.  An argument can be made that they should not be included in KStars at all, or perhaps they should be included in the program, but should not appear in the map unless the user goes back to the dates when the object was actually present in the solar system (i.e., these comets are on parabolic orbits; they will never come back to the inner solar system and are not gravitationally bound to the Sun).  I'd be glad to hear anyone's thoughts on this.

- The README.ephemerides appears not to be packaged on my system, I have filed a change-request for this : http://www.freebsd.org/cgi/query-pr.cgi?pr=117440

- 50 new comets is still nice and more in-line with what I expected :)

- I propose to keep the header and use the second line (with the dashes) to parse the file. Would it be helpful if I tried to hack KStarsData::readCometData such that this works ?

- About the disappeared comets; I think they should be skipped automatically from the right moment on (assuming that the disappear-date is part of the data file ;-)

- About the negative MJD comets; if someone is *really* interested in historical records, and has time to spare, then they can be added in such a way that they are only part of the map when the date is set back to when they were present.

I updated the comets.dat and asteroids.dat file in trunk.  For 3.x, you'll have to get the update from the GetNewStuff action, because adding new objects would break the strings freeze in the 3.5 branch.