My venerable Lexmark E120N needs a new drum kit - something between $70 and $80 bought online from the usual suspects.
It's also not wireless, which is not a great problem at the moment, our router still has ethernet ports, but we're in the throes of buying a new house, and that might mean the printer living somewhere other than next to the router.
What brought the whole problem to a head was we had to print out draft copies of the purchase contract, take one to the bank, two the lawyer and so on, and the photoconductor unit in the Lexmark had decided it was time to stop playing.
One of the big box stores had a pre Christmas special on FujiXerox Docuprint P115W's for less than a Lexmark drum kit, and I could get it there and then. So I did, and we printed nice clean copies and got papers filed the last day before the holidays.
Now for a cheapie I didn't expect much. I didn't expect inbuilt Google Print support, but given it plays nicely with our Macs I thought it might work with Linux as well, after all both use CUPS as print management solution.
Well, no.
FujiXerox don't distribute a ppd file - something that they must have to allow Mac support via CUPS. The obvious solution would be the the generic PCL driver, which certainly submits the job, and that's about it. (PostScript's worse, it's a great way to push a lot of blank pages through the machine to test paper handling).
I'm guessing that there's something wierd in the job initialisation sequence that is missing from the generic driver output - a language select statement or something like that needs baking into the generic ppd, and certainly there's some hints of this in the printer configuration if you dig round the internal system settings.
The question is which will be easiest - hack the generic ppd or try and extract the vendor one from the Mac printer driver distribution?
Hacking the generic one means it could be released back into the wild, but life would be easier if FujiXerox just released the ppd as an unsupported driver ...
It's also not wireless, which is not a great problem at the moment, our router still has ethernet ports, but we're in the throes of buying a new house, and that might mean the printer living somewhere other than next to the router.
What brought the whole problem to a head was we had to print out draft copies of the purchase contract, take one to the bank, two the lawyer and so on, and the photoconductor unit in the Lexmark had decided it was time to stop playing.
One of the big box stores had a pre Christmas special on FujiXerox Docuprint P115W's for less than a Lexmark drum kit, and I could get it there and then. So I did, and we printed nice clean copies and got papers filed the last day before the holidays.
Now for a cheapie I didn't expect much. I didn't expect inbuilt Google Print support, but given it plays nicely with our Macs I thought it might work with Linux as well, after all both use CUPS as print management solution.
Well, no.
FujiXerox don't distribute a ppd file - something that they must have to allow Mac support via CUPS. The obvious solution would be the the generic PCL driver, which certainly submits the job, and that's about it. (PostScript's worse, it's a great way to push a lot of blank pages through the machine to test paper handling).
I'm guessing that there's something wierd in the job initialisation sequence that is missing from the generic driver output - a language select statement or something like that needs baking into the generic ppd, and certainly there's some hints of this in the printer configuration if you dig round the internal system settings.
The question is which will be easiest - hack the generic ppd or try and extract the vendor one from the Mac printer driver distribution?
Hacking the generic one means it could be released back into the wild, but life would be easier if FujiXerox just released the ppd as an unsupported driver ...
No comments:
Post a Comment