The instructions for ubuntu were a good starting point. I’ll summarize:

1. Download these drivers for the FX DocuPrint C525A.
2. Unzip and use alien to convert the package to a .deb, and install it.
   benv@error:/tmp$ unzip dpc525a_linux_.0.0.tar.zip; alien Fuji_Xerox-DocuPrint_C525_A_AP-1.0-1.i386.rpm; dpkg -i fuji-xerox-docuprint-c525-a-ap_1.0-2_i386.deb
3. Go to http://localhost:631/admin and add a new network printer.
4. Select a protocol (either Jetdirect or LPD) and enter the IP address of the printer
5. Select the PPD file you installed from the .deb archive (/usr/share/cups/model/FujiXerox/en/FX_DocuPrint_C525_A_AP.ppd) or select the driver through the menu system
6. In cups go set the default printer options and make sure to set the optional tray module to 250 Sheet Feeder.

Issues I ran into

That’s all pretty default as the linked installation guide says. However, in my first attempt I used the JetDirect protocol on port 9100 (using an IP address, not a hostname). While this worked, everything was dirt slow. Going to the options page of a print dialog took almost a minute!
After some messing around I decided to try other protocols. The other protocol that worked was LPD/LPR. But not only did it work, but it’s fast! Click *BAF* Bluescreen1!!… uhh, I mean, print dialog
Anyway, instead of using an URI like socket://192.168.1.123:9100 simply use lpd://192.168.1.123:515. Let me repeat this so that people who skip over this post also read it: Use lpd://192.168.1.123:515 instead of socket://blabla, this works a lot faster!.

Once I got the printer in CUPS I also ran into the issue that the printer would respond but give an error on the printer itself. This was because I forgot to properly select the Tray Module, make sure it’s set to the 250 Feeder like in this picture:

Xerox 6125N tray module selection

Another issue, cups doesn’t seem to give all options for this printer in their default options dialog. This is bad, because you need to change the default paper source. Default it’s set to the bypass tray, which means you have to manually insert the paper when printing. Very annoying. However, using other tools give you more options. Using system-config-printer for instance gives the chance to change it. Make sure you put it to auto or tray 1 like this:

Xerox 6125N Paper source selection

When you finally manage to get those options set, the printer works perfectly under linux.
Have fun printing!

Oh yeah, here’s a slackware package in case you don’t want to mess with aliens and pokemon os
Slackware package for Xerox Phaser 6125N cups driver - Version 1.0 - SHA: 5f8b6478f93a6484d4834990448b152fb10d9cdd

And now, back to my Glenlivet… mmmmmmm

Glenlivet 18 year old

So we fire up xpdf on the document, hit the print icon, lpr, GO!
*time passes*
Mhm, what is it now?
*check http://localhost:631*
Nope, no document there, seems like it was handled by the printer.
*check cups error_log*
Heaps of garbage there.

Remember that we had this issue left in our previous cups story? Something about PDF printing causing issues?
Well, since then cups got upgraded to version 1.3.11 and some other stuff too, like ghostscript.
This time the error log showed something like this (only the relevant part here):

Some weird definition of ‘successfully’ you have there, cups.
After a few hours of debugging through that error_log, fucking with filters in /usr/share/cups/filters (cursing at Brother for their half baked wrapper scripts), turning on and off debug and log options
I was getting more and more annoyed with it. Considering on how to pick up the Brother DCP-135C and smashing it through the 2nd story window onto the pavement, but then not being
sure if it really was the brother’s fault at all, I decided to make sure once and for all which one I had to throw through the window.

Time for a manual debug session with the filters again. If you are having trouble with stuff like this, I can commend it to you. The steps I took (after the usual turning on debug and log options etc):

1. Grab your input file, in my case some PDF document which I ran through xpdf.
2. Instead of sending it to the printer, print using the “save to file” option so we have the source that cups has to deal with to work with.
3. Manually run this file through the filters as cups does. I curse on cups for not being more specific — EVEN WITH THE LogLevel debug2 OPTION TURNED ON (it just becomes MORE unreadable, but without more information) — about how it runs these filters, but there are some shell scripts floating around that you can use. What I did was just use
   strace -qfve execve -p `pidof cupsd` -s 250

   to figure out how my filters were called, but be ready to read tons of output on that one
   Anyhow, to save you some trouble, the call syntax seems to be

   filterprogram PRINTER JobNum User title copies documentoptions [file]

   or a real example from my test case:

   /usr/lib/cups/filter/pstops "DCP135C" 666 benv jemoeder 1 "document-name=4a93e8d852a17 number-up=1 job-uuid=urn:uuid:873e2907-cf50-35e2-5626-741377b394be" "/var/spool/cups/d00666-001"
4. Find out which part fails. The pstops had some output that looked fine by me, as far as I can read postscript as it scrolls through my terminal.

Funny thing is…. it seemed to me like pstops worked fine, as did the brother cups wrapper….
However, there was still this soab left:

Execution of /usr/bin/gs showed up in strace as well btw, don’t worry
So now the big question was: when did ghostscript become retarded?

I took my “print to file” postscript document, and tried opening it in ghostview.
It just looked at me like a cow looks at an oncoming train. Or in its own words:

Ah-HA!

….

What?

Since I’m by no means an expert on postscript, I googled it. The search revealed that apparently this could be the result of an eps image conversion gone bad.
Postscript doesn’t like to deal with binary data, so it’s not supposed to be there.
This can mean only one thing!
xpdf failed!!!!!!

Some testing revealed that xpdf on the old slackware32 chroot environment still does work, and printing the exact same PDF file there works fine, while printing that document from the 64 bit
slackware envrionment fails with the above story. Fascinating. Seems like it isn’t a library issue though, unless it’s cleverly hidden in the X libraries. I hope they’ll fix this soon
Just for reference, this is the xpdf-3.02pl3-x86_64-1 package that fails.

Well, now that we all know the details we can go to bed.
And if you need to print that pdf document: simply use pdf2ps, it works. (and stay away from habbokrat reader)

Attempt 1:

Easy. It even works, the printer starts rumbling and out it comes. Oh…. seems like the barcode is a bit screwed…. mhm, wonder how it managed to do that. (the rest looked fine).
Browsing through the cups error_log gave some gibberish, this line caught my attention:

Mhm, interesting. Google returned a bunch of filter thingies, and I was like “maybe it’ll work better if I try converting it to ps myself first”.
So I ran pdf2ps (instead of pdftops as cups does) and viewed the resulting ps file. Looks a lot better. Print it!
lpr on the file, and out it comes. Huh, no landscape? I try lpr -o landscape stupidfile.ps which also does portrait. RAAAH, STUPID KANKER CUPS.
After an hour of google and cursing I said “Fine, you do it” to lotjuh, who asked me earlier if she had to do it with her Habbokrat Reader…. what a piece of garbage that is….

Anyway, lotjuh soon ran into a new issue. First of all, her new Windows 7 didn’t have a printer driver, and trying to install the Vista on failed. Our printer is a cheap Brother DCP135C, which isn’t THAT old I thought. Oh well, that’s your windows problems for you
So she booted to linux. Surprise! Print didn’t work. That is, it said “OK” but out came nothing. Jobs just collected at her local cups.

*grumble*WHYYYYY???

Debugging this is a tough, since none of the logs give any useful information whatsoever, even in debug mode.

To understand this problem you might want some more network background info:
We have our internet through xs4all, who gave us a Fritzbox for that. Since I couldn’t get it to work like our previous internet setup with the external IP address on our local server,
we eventually decided that the thing could route for us, but we have our own DHCP server running on our local server.
So in our LAN the default gateway is the fritzbox, but our local server has most ports forwarded to it. In order to also run a dns server and dns cache it has multiple IP addresses in our local lan.
In fact, it has 3 IPs in the 192.168.1.x range on a single ethernet device.

Back to cups:
In cupsd.conf I have Listen 192.168.1.1:631. That should work, right?
However, BrowseAddress only accepts a .255 at the end, or an @IF statement. So I had @IF(eth_local) there.
Result: clients get confused, try to send data to all 3 IP addresses on the network. And since I can’t put the primary IP address in the BrowseAddress…. it fails.
My guess is that cups detects all 3 IP addresses on that interface and happily announces those, while only 1 of them should be used. Especially because of the listen statement.
I fixed this by using the second address, which I conviently have on a ‘different’ ethernet device eth_local:0. This seems to work a lot better, the clients now have a single printer in their cups
configuration and it even provides its location!

instead of the old

However, my first problem was still present. The whining about invalid PDF files. Printing from KWord also gave this error. The local cups would happily forward my job to our server, which then barfed on the thing:

… well, that’s just lovely.
(insert your curse of the day here).

Oh btw, if anyone ever wonders about the status of their printer and cups and everything:

So far I haven’t found a solution for this problem yet, except for a print to file, scp, manually convert, lpr style workaround, but that’s tedious.
If anyone knows, I’m interested in the cause and fix for it.