From our last exciting episode:

Quote Originally Posted by paradocs
Kate prints just fine -- probably using lp as Edwin points out --
when printing simple black text. But when you ask for a color
syntax printout, Kate locks up and nothing happens. I expect
that an image file is made and then the program to print
out the postscript file is missing or faulty.
And

Quote Originally Posted by A. Jorge Garcia
OK, so its something to do with processing color text.
Now I hate to be a spoilsport, but I tested with a file named "test.php". When opened in Kate she syntax-colored it very nice. When printed from Kate it came out of the printer just as on the screen _INCLUDING ALL THE COLORS_. No freeze or lock-up. And that on 5 different systems. Hmmm....what is happening here?

But anyway, I did some reading on cups. Then I did some more printing. All from Kate, all to an Epson 580 color, all from the same cpu. I made 2 files, 'test.php' and 'test.txt'. 'test.php' syntax-colors in Kate, 'test.txt' does not. I printed both from Kate. This is from the error_log (Time-stamps removed for better readabillity):

Job 11 queued on 'epson' by 'edwin'.
Started filter /usr/lib/cups/filter/pstops (PID 1000) for job 11.
Started filter /usr/lib/cups/filter/pstoraster (PID 1001) for job 11.
Started filter /usr/lib/cups/filter/rastertoprinter (PID 1002) for job 11.
Started backend /usr/lib/cups/backend/usb (PID 1003) for job 11.

The output was the same for both files (except for the PID's and job-numbers).
Then I printed the files using the 'lp' command. This showed up in the logs:

Job 13 queued on 'epson' by 'edwin'.
Started filter /usr/lib/cups/filter/texttops (PID 1012) for job 13.
Started filter /usr/lib/cups/filter/pstops (PID 1013) for job 13.
Started filter /usr/lib/cups/filter/pstoraster (PID 1014) for job 13.
Started filter /usr/lib/cups/filter/rastertoprinter (PID 1015) for job 13.
Started backend /usr/lib/cups/backend/usb (PID 1016) for job 13.

From my reading I understand this to be the way cups works. But interesting is that the job is queued first, the filters are applied after that. And that Kate presents a PostScript file to cups, color-coded or not.

I am stabbing in the dark here, but maybe Kate makes a mistake when generating a PS-file with color-information. She sends the file to cups, waiting for the digital equivalent of a 'Thumbs-Up' from cups. Cups chokes on the file, not sending the 'Thumbs-Up'. So Kate just sits there. This 'thinking-aloud-stab' does not address the question why this only happens on your side of the ocean ;=)
Could you post your error_log entries after a failed print attempt? I wonder how far cups gets.

Quote Originally Posted by A. Jorge Garcia
I find the root cause of all this very baffling. I don't see a pattern to these errors.
The only pattern I see is that, as far as I can see, you created your test.ps and test.pdf from VIM; any printing of them causes black text to disappear. The error is in the printer-driver that created them. But I might have overlooked something in your post. Did you try to print these files from Windows?
Apart from that, it could be a diabolical plot from the combined printer-producers to bump up their sales in ink or toner.... Ah well, I should turn in for the night. I think I'll do just that.

Quote Originally Posted by paradocs
Dumb, old serial printers could not make pretty fonts and
picture
Yeah, and a lot of people created ascii-art to compensate. Manager-types thought it looked like working, so they left you to it. Beats the Internet as a time-waster ;=)

Quote Originally Posted by A. Jorge Garcia
EDIT: OOPS, sorry, I forgot about ps -A -F.
Hey, thats what I have been looking for! Thank you!.

Regards,

- - Edwin