Menu
▾
▴
omniprint-developer
|
From: Pete Z. <pz...@us...> - 2001-10-08 22:02:10
|
Till,
Thank you for reporting this information to us.
Currently we have corrected some of the items and need some additional
feedback on others.
1. Foomatic: in the file db/source/opt/omni-print-model.xml (generated
by the program "Foomatic") the line
<arg_proto>%s -sproperties" </arg_proto>
must read
<arg_proto>%s -sproperties="</arg_proto>
This has been corrected in the latest Foomatic.cpp in Sourceforge.
2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow
machine generated. It need some manual corrections, not only when
sometimes "+" and "Plus" is used in printer names, also when there is a
library file serving for two or more printers, as
"libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer
entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP
LaserJet 4Si which is already in the database ("439570.xml") and to a
new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for
single printers, not for printer groups.
We originally had them under one driver but they had been moved into
multiple devices so that
device specific options could be applied to each. We will look into how to
resolve this as best
we can.
3. Foomatic: Names of options and choices: Both the machine-readable
short names and the human-readable long names for options and choices
should be as similar as possible to the Foomatic data of already
existing drivers.
We will look into this.
4. Setting both PAPERSIZE and FORM= issues.
Are you saying Ghostscript will not generate the output correctly if both
of these are not set
even though we tell Ghostscript the correct resolution and page size in
pels? Or is this just going
to cause a failure when using CUPS?
5. Omni printer properties information: Some printers have incorrect
properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600
dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does
600 dpi on this printer without problems. The HP LaserJet 2100 and 3200
models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are
wrong properties for many other printers. Many printer properties you
find on www.linuxprinting.org and also in the repository of GIMP-Print.
The laserjet printers only support the higher resolution on the 2100 and
3200 when using PCLXL.
We will report back the PCLxxx (non-PCL6) level of support that is
available in the Omni. Why would
we need to report back something not available in the driver?
6. Omni driver: Borders broken: The LaserJet 2100 driver reports the
correct paper size (I manually started GhostScript, without spooler)
when printing the CUPS test page, but the hole test page is shifted by
around 6mm to the right and 3mm to the top. This leads to the head line
"Printer Test Page" being cut at the top. It seems that it is shifted by
the non-printable left and lower borders. The "ljet4" and the "pxlmono"
driver of GhostScript handle that correctly. They center the page
correctly. Also the output on the Epson Stylus 1270 is shifted to the
upper right by more or less the same distances. This makes the driver
unusable for most applications.
With the printouts that I have been doing, everything seems to be centered
correctly. Is there an
issue of what the physical page dimensions and clip margins do on the
output? Sounds like
something is adding back in margins when the driver already manages them.
Is this possibly
happening? I don't know why a page would be moved to the right unless the
margin was added
back in. Please let me know where I can get a test file that shows this to
me.
7. Yellow on the middle grays with the Epson Stylus Photo 1270.
Are there modifications to the gamma values that will correct this? I
currently do not have a 1270
available for testing so if I could get feedback as to gamma or other
corrections, it would be a
great deal of help.
8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops
around 7cm before the end of the page (the rendering process is still
going on, last two bands), this is independent from the dithering
algorithm.
What resolution is the printer running at and the form that is being used?
I can try the same code (if
I can use LETTER on an 870) and see if the same problem occurs.
9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270
messes up the printout completely. One sees the test page twice, one at
the side of the other, each with half the original width and the full
original hight. In this case problem (7.) does not appear, but problem
(8.) appears.
Currently only two dithers support multi-bit per pel on Epsons, Stucki and
Steinberg. Other dithers
do not work in multi-bit per modes and we should find a way to disable them
until the dithers are
updated.
10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine
rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min,
the printout is done in a few seconds. All GhostScript drivers
("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni
is absolutely unsuitable for laser printers.
We have added the -smonodither=GSMONO to the command line in the latest
Foomatic code.
When a device is either mono or configured to print mono, Omni will now use
Ghostscripts mono-
dither and not Omni's. Omni's mono is better than Ghostscript's but the
performance suffers. Now
we will use Ghostscript's and not use the internal Omni code. The driver
should be comparable
with other monochrome drivers out there with this change that we have put
into Foomatic.cpp in
CVS. Yes you are right, the other drivers are WAY faster, or should I say
were faster.
Thanks again,
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...
Till Kamppeter <til...@gm...>@lists.sourceforge.net on 10/05/2001
04:32:57 PM
Sent by: omn...@li...
To: Pete Zannucci/Austin/IBM@IBMUS, omn...@so...,
Ryan A Harper/Austin/IBM@IBMUS, cru...@re...,
gt...@pi...
cc:
Subject: [Omniprint-developer] Omni still very buggy
Oi,
I have tested Omni 0.4.3 with the Foomatic generator code (all files in
the Omni/Foomatic directory) from today's CVS. There I have found the
fllowing problems:
1. Foomatic: in the file db/source/opt/omni-print-model.xml (generated
by the program "Foomatic") the line
<arg_proto>%s -sproperties" </arg_proto>
must read
<arg_proto>%s -sproperties="</arg_proto>
The "=" was missing and this way GhostScript ignored all the options in
the "properties" string.
2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow
machine generated. It need some manual corrections, not only when
sometimes "+" and "Plus" is used in printer names, also when there is a
library file serving for two or more printers, as
"libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer
entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP
LaserJet 4Si which is already in the database ("439570.xml") and to a
new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for
single printers, not for printer groups.
3. Foomatic: Names of options and choices: Both the machine-readable
short names and the human-readable long names for options and choices
should be as similar as possible to the Foomatic data of already
existing drivers. This makes the Foomatic data of Omni more
user-friendly and understandable and it also makes it easier to switch
from an old GhostScript driver to Omni with the Foomatic tools, because
the default settings of equally-named options with equally-named choices
are conserved. In addition, the "lpr" command lines get shorter when one
uses option and choice names as the already existing Foomatic drivers
have. Foe example the paper size should have as long name "Page Size",
as short name "PageSize" (this is already done) and the choices should
not contain the prefix "FORM" and should not be all-uppercase. They
should look like:
Short naame Long name
----------------------------
Letter Letter
A4 A4
COM10 Comercial 10
... ...
The other options should be changed similarly. The values really
inserted into the GhostScript command line need not to be changed.
4. Foomatic/GhostScript: Omni needs the paper size to be defined twice
in the GhostScript command line, once as the option "-sPAPERSIZE=..."
(or appropriate prepended PostScript commands) and second as the
"FORM=..." option in the "-sproperties=..." block. Once this makes the
GhostScript command line unnecessarily complicated (I don't know a
situation where one needs to define two different paper sizes here) an
second, it breaks Foomatic. A Foomatic option can modify the GhostScript
command line only in one point, not in two or more, or it can prepend
one PostScript command block. Prepending PostScript and modifying the
command line by one option is also not possible. So I suggest that you
change Omni in a way, that it uses the paper size given to GhostScript
via "-sPAPERSIZE=..." or prepended PostScript for the whole process,
instead of expecting a second definition of the paper size from the
user. For Foomatic you should then generate an option similar to the
already existing option "2.xml", a PostScript-prepending "PageSize"
option, only for Omni, which enables only the available page sizes for
every printer used with the Omni driver. The PostScript-prepending
version should be preferred against a version using "-sPAPERSIZE=...",
because Foomatic extracts the page dimension numbers from the PostScript
commands to set up the "PaperDimension" section in CUPS PPD files.
5. Omni printer properties information: Some printers have incorrect
properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600
dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does
600 dpi on this printer without problems. The HP LaserJet 2100 and 3200
models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are
wrong properties for many other printers. Many printer properties you
find on www.linuxprinting.org and also in the repository of GIMP-Print.
6. Omni driver: Borders broken: The LaserJet 2100 driver reports the
correct paper size (I manually started GhostScript, without spooler)
when printing the CUPS test page, but the hole test page is shifted by
around 6mm to the right and 3mm to the top. This leads to the head line
"Printer Test Page" being cut at the top. It seems that it is shifted by
the non-printable left and lower borders. The "ljet4" and the "pxlmono"
driver of GhostScript handle that correctly. They center the page
correctly. Also the output on the Epson Stylus 1270 is shifted to the
upper right by more or less the same distances. This makes the driver
unusable for most applications.
7. Omni driver: On the Epson Stylus Photo 1270 Cyan, Yellow, Magenta,
Red, Green, and Blue look correctly, but light to middle grays are very
yellowish (720 dpi, Steinberg dither, CcMmYK). If this happens only for
a part of the dithering modes, these dithering modes should be excluded
from this printer.
8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops
around 7cm before the end of the page (the rendering process is still
going on, last two bands), this is independent from the dithering
algorithm.
9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270
messes up the printout completely. One sees the test page twice, one at
the side of the other, each with half the original width and the full
original hight. In this case problem (7.) does not appear, but problem
(8.) appears.
10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine
rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min,
the printout is done in a few seconds. All GhostScript drivers
("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni
is absolutely unsuitable for laser printers.
I hope this report helps to make Omni better.
Crutcher, have you the same problems with Omni? Will it be fully
integrated in Red Hat 7.2?
Till
_______________________________________________
Omniprint-developer mailing list
Omn...@li...
https://lists.sourceforge.net/lists/listinfo/omniprint-developer
|
|
From: Mark H. <ha...@us...> - 2001-10-09 03:03:14
|
Hello Till, I appreciate your feedback. > 3. Foomatic: Names of options and choices: Both the machine-readable > short names and the human-readable long names for options and choices > should be as similar as possible to the Foomatic data of already > existing drivers. This makes the Foomatic data of Omni more > user-friendly and understandable and it also makes it easier to switch > from an old GhostScript driver to Omni with the Foomatic tools, because > the default settings of equally-named options with equally-named choices > are conserved. In addition, the "lpr" command lines get shorter when one > uses option and choice names as the already existing Foomatic drivers > have. Foe example the paper size should have as long name "Page Size", > as short name "PageSize" (this is already done) and the choices should > not contain the prefix "FORM" and should not be all-uppercase. They > should look like: > > Short naame Long name > ---------------------------- > Letter Letter > A4 A4 > COM10 Comercial 10 > ... ... > > The other options should be changed similarly. The values really > inserted into the GhostScript command line need not to be changed. Why should they be similiar? I thought that the purpose of foomatic was to provide a mapping between printer-driver-readable options and a human-readable dialog. The omni's options were designed to be consistant and easy to understand what value goes with what key. For instance, how does one know that Hagaki and Chou are trays or forms? Also, omni supports 190 forms. Does ghostscript support that many? Can there be a 1 to 1 mapping between ghostscript forms and omni forms so that we can include the second parameter? I think that this discussion is what should be covered in the Linux Printing Summit. It would be a good goal to have every printer driver support common job properties. The printer working group over at www.pwg.org is working on a set of standard form names and how they should be expressed. I am sure that everyone's input would be appreciated on how it should look. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ |
|
From: Till K. <til...@gm...> - 2001-10-09 19:17:18
|
I do not mean that you should change the options of the GhostScript
command line. Foomatic can give any form of option on the command line
which it bulds (as the "driverval"). I mean that you should change the
option names with which the user and/or a frontend is dealing (the
"shortname" and the "longname"), so you only need to change Foomatic,
not the driver itself.
You are using:
Long name Short name driverval(=gs command line opt)
=================================================================
A4 FORM_A4 FORM_A4
Letter FORM_LETTER FORM_LETTER
...
I think it is more user- and frontend-friendly when you use
Long name Short name driverval(=gs command line opt)
(Change to this:) (Do not change, is for driver)
=================================================================
A4 A4 FORM_A4
Letter Letter FORM_LETTER
...
Foomatic has no problem when choices do not indicate to which option
they belong. The user also has to give always an option/choice pair to
set an option and not only the choice. For the example above the user
says
lpr -P <printer> -o PageSize=A4 <file>
(and I think it is much more user-friendly than needing to enter
lpr -P <printer> -o PageSize=FORM_A4 <file>
In addition, when the user used ljet4 before and had PageSize=A4 as
default and he changes to Omni by using the "foomatic-configure" command
or Mandrake's "printerdrake" he would get his setting conserved when the
short name is "A4" but not when it would be "FORM_A4")
For the paper sizes which GhostScript and GIMP-Print do not support, you
can freely choose a name, but also here it is easier to enter when one
leaves out the "FORM_" in the short names of Foomatic.
Till
Mark Hamzy wrote:
>
> Hello Till,
>
>
> Why should they be similiar? I thought that the purpose of foomatic was to
> provide a mapping
> between printer-driver-readable options and a human-readable dialog.
> The omni's options were designed to be consistant and easy to understand
> what value goes
> with what key. For instance, how does one know that Hagaki and Chou are
> trays or forms?
>
> Also, omni supports 190 forms. Does ghostscript support that many? Can
> there be a 1 to 1 mapping
> between ghostscript forms and omni forms so that we can include the second
> parameter?
>
> I think that this discussion is what should be covered in the Linux
> Printing Summit. It would be
> a good goal to have every printer driver support common job properties.
> The printer working
> group over at www.pwg.org is working on a set of standard form names and
> how they should
> be expressed. I am sure that everyone's input would be appreciated on how
> it should look.
>
> Mark
>
> Take a look at the Linux Omni printer driver at
> http://www.ibm.com/linux/ltc/projects/omni/
|
|
From: Pete Z. <pz...@us...> - 2001-10-09 22:25:01
|
Till, Thanks for the updates. I will look into these items. As far as number 10 goes and doing mono-dithering, we end up using RGB generated by Ghostscript and then map it to a gray dither. This takes a long time and that's why the code was put in to use the internal mono dither in Ghostscript. As time permits, we can go back and implement other algorithms. Thanks again, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us... Till Kamppeter <til...@gm...>@lists.sourceforge.net on 10/09/2001 01:54:54 PM Sent by: omn...@li... To: Pete Zannucci/Austin/IBM@IBMUS cc: Omn...@so... Subject: Re: [Omniprint-developer] Omni still very buggy Here a version of the message for the mailing list with the attached pages removed. The message got too big for the mailing list limit (40k). I have uploaded the pages to http://mandrakesoft.com/~tkamppeter/samplepages/ Till ---------Original message---------- All driver tests done with manual usage of GhostScript (no spooler, no Foomatic used, comand line example attached), A4 paper, test pages as attached, GhostScript 6.51, Omni 0.4.3 (no CVS). Foomatic reports about the CVS from the day of the original e-mail. Pete Zannucci wrote: > > 2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow > machine generated. It need some manual corrections, not only when > sometimes "+" and "Plus" is used in printer names, also when there is a > library file serving for two or more printers, as > "libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer > entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP > LaserJet 4Si which is already in the database ("439570.xml") and to a > new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for > single printers, not for printer groups. > > We originally had them under one driver but they had been moved into > multiple devices so that > device specific options could be applied to each. We will look into how to > resolve this as best > we can. > Can one not simply say in the Omni/Foomatic/foomaticDB hp-laserjet_4si_4si_mx:439570 hp-laserjet_4si_4si_mx:HP-LaserJet_4Si_Mx so that one Omni model/library is assigned to two printer models? > 4. Setting both PAPERSIZE and FORM= issues. > > Are you saying Ghostscript will not generate the output correctly if both > of these are not set > even though we tell Ghostscript the correct resolution and page size in > pels? Or is this just going > to cause a failure when using CUPS? > It is the following: The user has a certain paper in his printer, with a certain size. When he wants to print a document it is most convenient for him to set the page size at one point of the software. For me it does not make sense when the user has to supply two completely dofferent options at two different places to set the page size, as it is now with Omni. According to the documentation you have to give the option "form=FORM_A4" in the "properties" string and in addition the usual GhostScript option which is either "-sPAPERSIZE=a4" or a prepended PostScript command. Foomatic is also made in a way, that the setting of an option always modifies only one point of the command line, not various points. So it is much-more user-friendly and much easier for the implementation of Foomatic data to make Omni simply take the paper size which the user has supplied by standard GhostScript options. For paper sizes which GhostScript does not support one can always give the size numerically by the prepended PostScript: % PostScript for A4 paper <</PageSize[595 842]/ImagingBBox null>>setpagedevice > 5. Omni printer properties information: Some printers have incorrect > properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600 > dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does > 600 dpi on this printer without problems. The HP LaserJet 2100 and 3200 > models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are > wrong properties for many other printers. Many printer properties you > find on www.linuxprinting.org and also in the repository of GIMP-Print. > > The laserjet printers only support the higher resolution on the 2100 and > 3200 when using PCLXL. > We will report back the PCLxxx (non-PCL6) level of support that is > available in the Omni. Why would > we need to report back something not available in the driver? > I understand the problem for the 2100 and 3200. They need PCL-XL for 1200 dpi and PCL-XL is not implemented in Omni. But the HP LaserJet 1100 understands only PCL <= 5 and does 600 dpi with the "ljet4" GhostScript driver. So it should not be a problem for Omni to print 600 dpi on the LJ 1100. GIMP-Print also does not print more than 600 dpi on the 2100 and 3200, also due to lack of PCL-XL, but it prints with 600 dpi on the LaserJet 1100. > 6. Omni driver: Borders broken: The LaserJet 2100 driver reports the > correct paper size (I manually started GhostScript, without spooler) > when printing the CUPS test page, but the hole test page is shifted by > around 6mm to the right and 3mm to the top. This leads to the head line > "Printer Test Page" being cut at the top. It seems that it is shifted by > the non-printable left and lower borders. The "ljet4" and the "pxlmono" > driver of GhostScript handle that correctly. They center the page > correctly. Also the output on the Epson Stylus 1270 is shifted to the > upper right by more or less the same distances. This makes the driver > unusable for most applications. > > With the printouts that I have been doing, everything seems to be centered > correctly. Is there an > issue of what the physical page dimensions and clip margins do on the > output? Sounds like > something is adding back in margins when the driver already manages them. > Is this possibly > happening? I don't know why a page would be moved to the right unless the > margin was added > back in. Please let me know where I can get a test file that shows this to > me. > I have attached all files which I have printed. they all show the same shift. The RedHat test page (testpage-a4.ps) is a static PostScript file, as an application would produce. The CUPS test page (testprint*) is a PostScript program which asks the PostScript interpreter for the device propertes as margins, paper size, and resolution. All data is printed onto the page, and in addition, there is drawn a black rectangle on the border of the imageable area (paper size minus unprintable margins. I have given all GhostScript calls manually, without using a spooler or Foomatic (see attached sample command line gs_omni_cmd.txt), so the problem must be the driver. I have used GhostScript 6.51 with stock Omni 0.4.3, no CVS. > 7. Yellow on the middle grays with the Epson Stylus Photo 1270. > > Are there modifications to the gamma values that will correct this? I > currently do not have a 1270 > available for testing so if I could get feedback as to gamma or other > corrections, it would be a > great deal of help. > Perhaps you should contact the GIMP-Print team, with GIMP-Print this printer works even better than under Windows. They can tell you probably which gamma and colour balancing settings GIMP-Print uses or whether even special tricks are applied. I have done the tests on an Epson Stylus 1290 but as I know this model has the same inks and in addition, it prints perfectly with the GIMP-Print driver for the 1270. > 8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops > around 7cm before the end of the page (the rendering process is still > going on, last two bands), this is independent from the dithering > algorithm. > > What resolution is the printer running at and the form that is being used? > I can try the same code (if > I can use LETTER on an 870) and see if the same problem occurs. > The form is A4 and the resolution is 720x720 dpi. It seems to be independent of the document. The problem appears with both the CUPS and the RedHat test page. The used RedHat test page was the A4 version (pages attached). I have aso tried 360x360 dpi on the Epson Stylus 1270, but this mode is completely broken: Page shifted as with 720x720dpi. Printing (not rendering) of page needs around 2 hours (seems that the printer prints with only one nozzle), paper completely flooded with black, no magenta came out, "Linux Mandrake" and yellow star very greenish. Here you should perhaps also contact the GIMP-Print guys. But in this mode only 2 cm of the lower border are missing. > 9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270 > messes up the printout completely. One sees the test page twice, one at > the side of the other, each with half the original width and the full > original hight. In this case problem (7.) does not appear, but problem > (8.) appears. > > Currently only two dithers support multi-bit per pel on Epsons, Stucki and > Steinberg. Other dithers > do not work in multi-bit per modes and we should find a way to disable them > until the dithers are > updated. > Is there not an XML description for every printer? One should have a list of suitable dither algorithms there. > 10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine > rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min, > the printout is done in a few seconds. All GhostScript drivers > ("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni > is absolutely unsuitable for laser printers. > > We have added the -smonodither=GSMONO to the command line in the latest > Foomatic code. > When a device is either mono or configured to print mono, Omni will now use > Ghostscripts mono- > dither and not Omni's. Omni's mono is better than Ghostscript's but the > performance suffers. Now > we will use Ghostscript's and not use the internal Omni code. The driver > should be comparable > with other monochrome drivers out there with this change that we have put > into Foomatic.cpp in > CVS. Yes you are right, the other drivers are WAY faster, or should I say > were faster. There should be a way that a driver with its own dithering algorithms can also be fast, GIMP-Print has also its own dithering algorithms and it does not let a laser printer wait for ages to get a complete page. Till cat /usr/share/printer-testpages/testpage-a4.ps | gs -q -dSAFER -dBATCH -dNOPAUSE -sPAPERSIZE=a4 -sDEVICE=omni -sDeviceName=HP_LaserJet_2100 -sproperties="resolution=RESOLUTION_300_X_300 form=FORM_A4" -sOutputFile=- - > testfileLJ |
|
From: Pete Z. <pz...@us...> - 2001-10-15 23:09:45
|
Till, I wasn't able to reproduce your problem here with the parser. You were using the gz file and not CVS correct? I put a new Epson High Res Instance.cpp file up with the 0.5 package which will solve the lost band on the bottom of the page with A4. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us... Till Kamppeter <til...@gm...> on 10/12/2001 06:23:15 PM To: Pete Zannucci/Austin/IBM@IBMUS cc: Subject: Re: [Omniprint-developer] Omni still very buggy I have downloaded Omni 0.5.0 and get the following error when compiling it: make[1]: Entering directory `/home/tkamppeter/rpm/BUILD/printer-drivers-1.0/ghostscript-6.51/src/Omni/XMLParser' c++ -fPIC -Wall -I .. -g -DDEBUG=1 -c MyErrorHandler.cpp c++ -fPIC -Wall -I .. -g -DDEBUG=1 -c OmniDomParser.cpp OmniDomParser.cpp: In method `bool OmniDomParser::processDriver (xmlNode *)': OmniDomParser.cpp:4732: `parseSize' undeclared (first use this function) OmniDomParser.cpp:4732: (Each undeclared identifier is reported only once for each function it appears in.) make[1]: *** [OmniDomParser.o] Error 1 make[1]: Leaving directory `/home/tkamppeter/rpm/BUILD/printer-drivers-1.0/ghostscript-6.51/src/Omni/XMLParser' make: *** [XMLParser.make] Error 2 error: Bad exit status from /home/tkamppeter/tmp/rpm-tmp.80692 (%build) RPM build errors: Bad exit status from /home/tkamppeter/tmp/rpm-tmp.80692 (%build) It seems that something is missing in Omni. Till Pete Zannucci wrote: > Till, > > Thanks for bringing the problem with A4 forms to my attention. > I am investigating what in the commands going down is causing > this. The older Color Stylus printers handle it fine but the newer > printers are not. > It looks like the form size information is not set up correctly for the > printer. > > > > > Peter Zannucci > > IBM Linux Technology Center > Open Source Software Development > Omni Print Project http://sourceforge.net/projects/omniprint > Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us... > > > |
|
From: Till K. <til...@gm...> - 2001-10-17 18:06:48
|
I have downloaded Omni from CVS yesterday and now it compiles correctly
and the pages on the Epson Stylus Color 1290 come out completely. This
version is on Mandrake's Cooker now as the package "omni". The Foomatic
data for the Omni driver I have also integrated in Cooker, they are now
added to the "foomatic" package.
All tests are done by entering the GhostScript command line manually to
avoid the influence of filters used by the spooler, but some tests of
using Foomatic with CUPS lead to the same results.
Now to my results with Omni:
1. Printing on Epson Stylus Color 1290: 720x720 dpi and 1440x720 dpi
give a high quality (tested on plain paper, 24-bit CcMmYK), only the
grau composed from the colours is yellowish, the red looks somewhat
orange, and the blue somewhat violet. 2880x720 make the print head
moving a little bit, but nothing gets printed, 360x360 dpi prints very
slowly and the paper is completely soaked with ink, it seems that every
row is printed at least with 10 sweeps loading full ink onto the paper.
This makes the letters as painted with a thick pen, one can also read
them on the back side of the paper (the duplex of the poor man?). When
the printer has to print a row which contains colour and not only black,
the black ink intensity is OK, but the yellow intensity is much to high,
the yellow ink is soaking through the paper here and makes all colours
with yellow participation looking like through yellow glass. All yellow
free colours are normal. In the draft mode the printer does not even
switch into graphics mode, I get a lot of weird black ASCII text lines
on the sheets (as when I would use a driver for a non-Epson printer on
my Epson).
2. LaserJet 2100 driver: The printout is much faster now, but one has
similar steps in the grayscale as when one prints with the "ljet4"
GhostScript driver. Is it not possible to make the dither algorithms
faster? When I print with GIMP-Print on an HP laser printer, I get a
nicely dithered printout without any significant delay.
3. Document position: As I already observed in older versions of Omni,
the document is shifted around 3-6 mm to the right and around 3-6 mm to
the top of the paper. This effect one sees easily when one prints the
RedHat (testpage*.ps) or the CUPS (testprint.ps) test pages, but it also
appears with all other documents. The pages you find on
http://mandrakesoft.com/~tkamppeter/printer-testpages/
and they can be used with every distro and every spooler. The frames on
the RedHat pages must have distances to the border of the paper as
indicated at the frames, the frame on the CUPS test page marks the
border of the imageable area. The coordinates (relative to the lower
left corner of the sheet) of the imageable area are also written onto
the page as numbers. Comparing the numbers with the actual frame
position shows, that the whole document is printed in the correct size
but it is shifted to the upper right direction. This happens for all
drivers, printers, and modes. I have used the "-sPAPERSIZE=A4"
GhostScript option and "form=FORM_A4" in the "-sproperties=..." string.
When I prepend the lines
%!
<</PageSize[595 842]/ImagingBBox null>>setpagedevice
to the PostScript document and do NOT give the "-sPAPERSIZE=A4"
GhostScript option, but still the "form=FORM_A4" in the
"-sproperties=..." string, I have only the shift to the right, the shift
to the top disappears. This means that the upper and the lower margin
are correct now, the left margin is too wide and the right too narrow.
4. Paper size setting: According to the docs/Omni.readme.1st file one
has to specify the paper size twice in the GhostScript command line,
once by the GhostScript option "-sPAPERSIZE=..." (or an appropriate
PostScript command in the document or the "-g" option) and second, by
the "form=..." directive in the "-sproperties=..." string. I have
checked that when one gives the paper size only once (either GhostScript
option or "form=..." directive) the output gets wrong, cut off or
shifted by several centimeters. So giving only one (or two different)
paper size settings makes no sense. In addition, the Foomatic data for
Omni only sets the "form=..." option and not the GhostScript option, to
do it correctly, the "PageSize" option has to change two points in the
command line, the "-sPAPERSIZE=..." (or "-g") setting and the "form=..."
setting, but modifying two points is not supported by the current
Foomatic. Therefore I suggest the Omni driver to be changed that it is
enough to give only the GhostScript option or only the "form=..." option
and the other internal variable of the driver/GhostScript is set
appropriate to the value of the variable for which the user has given
the option. For example you could remove the "form=..." option and the
user/Foomatic provides the paper size as prepended PostScript or a
standard GhostScript option (GhostScript does not need to know all paper
size names, because the PostScript command and the "-g" option use
numbers to describe the paper size) the name/size relation and the list
of allowed paper sizes is provided by the Foomatic data. Then all is
compliant to the standard.
5. Choices in Foomatic options: The "shortnames" of the choices of the
Foomatic options are completely independent of the options on the
command line of GhostScript/the printer driver. So one can make the
Foomatic data somewhat more user friendly by using shortnames which are
equal to the ones of other drivers:
FORM_LETTER --> Letter
FORM_A4 --> A4
RESOLUTION_300_X_300 --> 300x300DPI
so users have much less to type when giving options on the command line
and when they have more than one printer and some printers are used with
Omni, others are used with other drivers, they can use the same command
line options for doing the same things on the different printers. This
change is only a change on the Foomatic data, the driver itself does not
need to be changed ("shortname" and "driverval" are independent from
each other).
6. Manufacturer "HP LaserJet": The following printers have "HP LaserJet"
as the manufacturer's name in their Foomatic data:
HP LaserJet 4PJ
HP LaserJet IIID
HP LaserJet IIIP
HP LaserJet IIISi
HP LaserJet III
This must be simply "HP". Probably more printer entries have that problem.
7. Printer names: All "HP LaserJet II" and "HP LaserJet III" models are
in the Foomatic database, but as "HP LaserJet 2" and "HP LaserJet 3".
Can you change the names in Omni appropriately and/or put appropriate
relations into the Omni/Foomatic/bin/foomaticDB file?
8. The HP LaserJet 1100 still offers only resolutions up to 300 dpi, the
printer is capable for 600 dpi (with "ljet4" or GIMP-Print).
That's all what I found now.
Till
Pete Zannucci wrote:
> Till, I wasn't able to reproduce your problem here with the parser. You
> were using
> the gz file and not CVS correct?
> I put a new Epson High Res Instance.cpp file up with the 0.5 package which
> will
> solve the lost band on the bottom of the page with A4.
|
|
From: Till K. <til...@gm...> - 2001-10-09 21:46:11
Attachments:
gs_omni_cmd.txt
|
Here a version of the message for the mailing list with the attached pages removed. The message got too big for the mailing list limit (40k). I have uploaded the pages to http://mandrakesoft.com/~tkamppeter/samplepages/ Till ---------Original message---------- All driver tests done with manual usage of GhostScript (no spooler, no Foomatic used, comand line example attached), A4 paper, test pages as attached, GhostScript 6.51, Omni 0.4.3 (no CVS). Foomatic reports about the CVS from the day of the original e-mail. Pete Zannucci wrote: > > 2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow > machine generated. It need some manual corrections, not only when > sometimes "+" and "Plus" is used in printer names, also when there is a > library file serving for two or more printers, as > "libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer > entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP > LaserJet 4Si which is already in the database ("439570.xml") and to a > new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for > single printers, not for printer groups. > > We originally had them under one driver but they had been moved into > multiple devices so that > device specific options could be applied to each. We will look into how to > resolve this as best > we can. > Can one not simply say in the Omni/Foomatic/foomaticDB hp-laserjet_4si_4si_mx:439570 hp-laserjet_4si_4si_mx:HP-LaserJet_4Si_Mx so that one Omni model/library is assigned to two printer models? > 4. Setting both PAPERSIZE and FORM= issues. > > Are you saying Ghostscript will not generate the output correctly if both > of these are not set > even though we tell Ghostscript the correct resolution and page size in > pels? Or is this just going > to cause a failure when using CUPS? > It is the following: The user has a certain paper in his printer, with a certain size. When he wants to print a document it is most convenient for him to set the page size at one point of the software. For me it does not make sense when the user has to supply two completely dofferent options at two different places to set the page size, as it is now with Omni. According to the documentation you have to give the option "form=FORM_A4" in the "properties" string and in addition the usual GhostScript option which is either "-sPAPERSIZE=a4" or a prepended PostScript command. Foomatic is also made in a way, that the setting of an option always modifies only one point of the command line, not various points. So it is much-more user-friendly and much easier for the implementation of Foomatic data to make Omni simply take the paper size which the user has supplied by standard GhostScript options. For paper sizes which GhostScript does not support one can always give the size numerically by the prepended PostScript: % PostScript for A4 paper <</PageSize[595 842]/ImagingBBox null>>setpagedevice > 5. Omni printer properties information: Some printers have incorrect > properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600 > dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does > 600 dpi on this printer without problems. The HP LaserJet 2100 and 3200 > models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are > wrong properties for many other printers. Many printer properties you > find on www.linuxprinting.org and also in the repository of GIMP-Print. > > The laserjet printers only support the higher resolution on the 2100 and > 3200 when using PCLXL. > We will report back the PCLxxx (non-PCL6) level of support that is > available in the Omni. Why would > we need to report back something not available in the driver? > I understand the problem for the 2100 and 3200. They need PCL-XL for 1200 dpi and PCL-XL is not implemented in Omni. But the HP LaserJet 1100 understands only PCL <= 5 and does 600 dpi with the "ljet4" GhostScript driver. So it should not be a problem for Omni to print 600 dpi on the LJ 1100. GIMP-Print also does not print more than 600 dpi on the 2100 and 3200, also due to lack of PCL-XL, but it prints with 600 dpi on the LaserJet 1100. > 6. Omni driver: Borders broken: The LaserJet 2100 driver reports the > correct paper size (I manually started GhostScript, without spooler) > when printing the CUPS test page, but the hole test page is shifted by > around 6mm to the right and 3mm to the top. This leads to the head line > "Printer Test Page" being cut at the top. It seems that it is shifted by > the non-printable left and lower borders. The "ljet4" and the "pxlmono" > driver of GhostScript handle that correctly. They center the page > correctly. Also the output on the Epson Stylus 1270 is shifted to the > upper right by more or less the same distances. This makes the driver > unusable for most applications. > > With the printouts that I have been doing, everything seems to be centered > correctly. Is there an > issue of what the physical page dimensions and clip margins do on the > output? Sounds like > something is adding back in margins when the driver already manages them. > Is this possibly > happening? I don't know why a page would be moved to the right unless the > margin was added > back in. Please let me know where I can get a test file that shows this to > me. > I have attached all files which I have printed. they all show the same shift. The RedHat test page (testpage-a4.ps) is a static PostScript file, as an application would produce. The CUPS test page (testprint*) is a PostScript program which asks the PostScript interpreter for the device propertes as margins, paper size, and resolution. All data is printed onto the page, and in addition, there is drawn a black rectangle on the border of the imageable area (paper size minus unprintable margins. I have given all GhostScript calls manually, without using a spooler or Foomatic (see attached sample command line gs_omni_cmd.txt), so the problem must be the driver. I have used GhostScript 6.51 with stock Omni 0.4.3, no CVS. > 7. Yellow on the middle grays with the Epson Stylus Photo 1270. > > Are there modifications to the gamma values that will correct this? I > currently do not have a 1270 > available for testing so if I could get feedback as to gamma or other > corrections, it would be a > great deal of help. > Perhaps you should contact the GIMP-Print team, with GIMP-Print this printer works even better than under Windows. They can tell you probably which gamma and colour balancing settings GIMP-Print uses or whether even special tricks are applied. I have done the tests on an Epson Stylus 1290 but as I know this model has the same inks and in addition, it prints perfectly with the GIMP-Print driver for the 1270. > 8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops > around 7cm before the end of the page (the rendering process is still > going on, last two bands), this is independent from the dithering > algorithm. > > What resolution is the printer running at and the form that is being used? > I can try the same code (if > I can use LETTER on an 870) and see if the same problem occurs. > The form is A4 and the resolution is 720x720 dpi. It seems to be independent of the document. The problem appears with both the CUPS and the RedHat test page. The used RedHat test page was the A4 version (pages attached). I have aso tried 360x360 dpi on the Epson Stylus 1270, but this mode is completely broken: Page shifted as with 720x720dpi. Printing (not rendering) of page needs around 2 hours (seems that the printer prints with only one nozzle), paper completely flooded with black, no magenta came out, "Linux Mandrake" and yellow star very greenish. Here you should perhaps also contact the GIMP-Print guys. But in this mode only 2 cm of the lower border are missing. > 9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270 > messes up the printout completely. One sees the test page twice, one at > the side of the other, each with half the original width and the full > original hight. In this case problem (7.) does not appear, but problem > (8.) appears. > > Currently only two dithers support multi-bit per pel on Epsons, Stucki and > Steinberg. Other dithers > do not work in multi-bit per modes and we should find a way to disable them > until the dithers are > updated. > Is there not an XML description for every printer? One should have a list of suitable dither algorithms there. > 10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine > rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min, > the printout is done in a few seconds. All GhostScript drivers > ("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni > is absolutely unsuitable for laser printers. > > We have added the -smonodither=GSMONO to the command line in the latest > Foomatic code. > When a device is either mono or configured to print mono, Omni will now use > Ghostscripts mono- > dither and not Omni's. Omni's mono is better than Ghostscript's but the > performance suffers. Now > we will use Ghostscript's and not use the internal Omni code. The driver > should be comparable > with other monochrome drivers out there with this change that we have put > into Foomatic.cpp in > CVS. Yes you are right, the other drivers are WAY faster, or should I say > were faster. There should be a way that a driver with its own dithering algorithms can also be fast, GIMP-Print has also its own dithering algorithms and it does not let a laser printer wait for ages to get a complete page. Till |
|
From: Till K. <til...@gm...> - 2001-10-09 21:36:16
|
All driver tests done with manual usage of GhostScript (no spooler, no
Foomatic used, comand line example attached), A4 paper, test pages as
attached, GhostScript 6.51, Omni 0.4.3 (no CVS).
Foomatic reports about the CVS from the day of the original e-mail.
Pete Zannucci wrote:
>
> 2. Foomatic: Probably the file Omni/Foomatic/bin/foomaticDB is somehow
> machine generated. It need some manual corrections, not only when
> sometimes "+" and "Plus" is used in printer names, also when there is a
> library file serving for two or more printers, as
> "libHP_LaserJet_4Si_4Si_Mx.so". This should not lead to a new printer
> entry "HP-LaserJet_4Si_4Si_Mx.xml", but to an association to the HP
> LaserJet 4Si which is already in the database ("439570.xml") and to a
> new printer "HP-LaserJet_4Si_Mx.xml". The database has entries only for
> single printers, not for printer groups.
>
> We originally had them under one driver but they had been moved into
> multiple devices so that
> device specific options could be applied to each. We will look into how to
> resolve this as best
> we can.
>
Can one not simply say in the Omni/Foomatic/foomaticDB
hp-laserjet_4si_4si_mx:439570
hp-laserjet_4si_4si_mx:HP-LaserJet_4Si_Mx
so that one Omni model/library is assigned to two printer models?
> 4. Setting both PAPERSIZE and FORM= issues.
>
> Are you saying Ghostscript will not generate the output correctly if both
> of these are not set
> even though we tell Ghostscript the correct resolution and page size in
> pels? Or is this just going
> to cause a failure when using CUPS?
>
It is the following:
The user has a certain paper in his printer, with a certain size. When
he wants to print a document it is most convenient for him to set the
page size at one point of the software. For me it does not make sense
when the user has to supply two completely dofferent options at two
different places to set the page size, as it is now with Omni. According
to the documentation you have to give the option "form=FORM_A4" in the
"properties" string and in addition the usual GhostScript option which
is either "-sPAPERSIZE=a4" or a prepended PostScript command. Foomatic
is also made in a way, that the setting of an option always modifies
only one point of the command line, not various points. So it is
much-more user-friendly and much easier for the implementation of
Foomatic data to make Omni simply take the paper size which the user has
supplied by standard GhostScript options. For paper sizes which
GhostScript does not support one can always give the size numerically by
the prepended PostScript:
% PostScript for A4 paper
<</PageSize[595 842]/ImagingBBox null>>setpagedevice
> 5. Omni printer properties information: Some printers have incorrect
> properties in Omni: The HP LaserJet 1100 has a maximum resolution of 600
> dpi, Omni allows only 300 dpi, the "ljet4" driver of GhostScript does
> 600 dpi on this printer without problems. The HP LaserJet 2100 and 3200
> models have 1200 dpi and Omni allows only 600 dpi. Perhaps there are
> wrong properties for many other printers. Many printer properties you
> find on www.linuxprinting.org and also in the repository of GIMP-Print.
>
> The laserjet printers only support the higher resolution on the 2100 and
> 3200 when using PCLXL.
> We will report back the PCLxxx (non-PCL6) level of support that is
> available in the Omni. Why would
> we need to report back something not available in the driver?
>
I understand the problem for the 2100 and 3200. They need PCL-XL for
1200 dpi and PCL-XL is not implemented in Omni. But the HP LaserJet 1100
understands only PCL <= 5 and does 600 dpi with the "ljet4" GhostScript
driver. So it should not be a problem for Omni to print 600 dpi on the
LJ 1100.
GIMP-Print also does not print more than 600 dpi on the 2100 and 3200,
also due to lack of PCL-XL, but it prints with 600 dpi on the LaserJet
1100.
> 6. Omni driver: Borders broken: The LaserJet 2100 driver reports the
> correct paper size (I manually started GhostScript, without spooler)
> when printing the CUPS test page, but the hole test page is shifted by
> around 6mm to the right and 3mm to the top. This leads to the head line
> "Printer Test Page" being cut at the top. It seems that it is shifted by
> the non-printable left and lower borders. The "ljet4" and the "pxlmono"
> driver of GhostScript handle that correctly. They center the page
> correctly. Also the output on the Epson Stylus 1270 is shifted to the
> upper right by more or less the same distances. This makes the driver
> unusable for most applications.
>
> With the printouts that I have been doing, everything seems to be centered
> correctly. Is there an
> issue of what the physical page dimensions and clip margins do on the
> output? Sounds like
> something is adding back in margins when the driver already manages them.
> Is this possibly
> happening? I don't know why a page would be moved to the right unless the
> margin was added
> back in. Please let me know where I can get a test file that shows this to
> me.
>
I have attached all files which I have printed. they all show the same
shift. The RedHat test page (testpage-a4.ps) is a static PostScript
file, as an application would produce. The CUPS test page (testprint*)
is a PostScript program which asks the PostScript interpreter for the
device propertes as margins, paper size, and resolution. All data is
printed onto the page, and in addition, there is drawn a black rectangle
on the border of the imageable area (paper size minus unprintable
margins. I have given all GhostScript calls manually, without using a
spooler or Foomatic (see attached sample command line gs_omni_cmd.txt),
so the problem must be the driver. I have used GhostScript 6.51 with
stock Omni 0.4.3, no CVS.
> 7. Yellow on the middle grays with the Epson Stylus Photo 1270.
>
> Are there modifications to the gamma values that will correct this? I
> currently do not have a 1270
> available for testing so if I could get feedback as to gamma or other
> corrections, it would be a
> great deal of help.
>
Perhaps you should contact the GIMP-Print team, with GIMP-Print this
printer works even better than under Windows. They can tell you probably
which gamma and colour balancing settings GIMP-Print uses or whether
even special tricks are applied. I have done the tests on an Epson
Stylus 1290 but as I know this model has the same inks and in addition,
it prints perfectly with the GIMP-Print driver for the 1270.
> 8. Omni driver: The printout on the Epson Stylus Photo 1270 always stops
> around 7cm before the end of the page (the rendering process is still
> going on, last two bands), this is independent from the dithering
> algorithm.
>
> What resolution is the printer running at and the form that is being used?
> I can try the same code (if
> I can use LETTER on an 870) and see if the same problem occurs.
>
The form is A4 and the resolution is 720x720 dpi. It seems to be
independent of the document. The problem appears with both the CUPS and
the RedHat test page. The used RedHat test page was the A4 version
(pages attached).
I have aso tried 360x360 dpi on the Epson Stylus 1270, but this mode is
completely broken: Page shifted as with 720x720dpi. Printing (not
rendering) of page needs around 2 hours (seems that the printer prints
with only one nozzle), paper completely flooded with black, no magenta
came out, "Linux Mandrake" and yellow star very greenish. Here you
should perhaps also contact the GIMP-Print guys. But in this mode only 2
cm of the lower border are missing.
> 9. Omni-driver: Fast diffusion dithering on the Epson Stylus Photo 1270
> messes up the printout completely. One sees the test page twice, one at
> the side of the other, each with half the original width and the full
> original hight. In this case problem (7.) does not appear, but problem
> (8.) appears.
>
> Currently only two dithers support multi-bit per pel on Epsons, Stucki and
> Steinberg. Other dithers
> do not work in multi-bit per modes and we should find a way to disable them
> until the dithers are
> updated.
>
Is there not an XML description for every printer? One should have a
list of suitable dither algorithms there.
> 10. Omni driver: Omni is terribly slow, on my 350 Mhz test machine
> rendering a 600x600 dpi test page for the LaserJet 2100 needs 2:30 min,
> the printout is done in a few seconds. All GhostScript drivers
> ("pxlmono", "ljet4", and even "lj5gray") are WAY faster. This way Omni
> is absolutely unsuitable for laser printers.
>
> We have added the -smonodither=GSMONO to the command line in the latest
> Foomatic code.
> When a device is either mono or configured to print mono, Omni will now use
> Ghostscripts mono-
> dither and not Omni's. Omni's mono is better than Ghostscript's but the
> performance suffers. Now
> we will use Ghostscript's and not use the internal Omni code. The driver
> should be comparable
> with other monochrome drivers out there with this change that we have put
> into Foomatic.cpp in
> CVS. Yes you are right, the other drivers are WAY faster, or should I say
> were faster.
There should be a way that a driver with its own dithering algorithms
can also be fast, GIMP-Print has also its own dithering algorithms and
it does not let a laser printer wait for ages to get a complete page.
Till |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X