I have an old system around with F16, which I didnt bother to update to F17 or F18 because I seldom use it (old specs, ancient cpu, low ram ,120GB IDE HD, etc) but XFCE boots and can be used when everything else fails. I decided to plug a Samsung 2165W laser to it through its usb port. The 2165W like many other cheap Samsung lasers are closer to ´winprinters´ because, althought not GDI printers, those use the proprietary Samsung SPL page description language, implemented in Samsung´s windows drivers, -but also as Linux binaries, more on that later-. In other words, these printers don´t enjoy the flexibility of PCL/PCL5 or PostScript printers that are almost ´universal´ and work out of the box with little fiddling around. F16 XFCE showed a nice ´detecting new printer´ dialog on the top-right side of the screen only to conclude 30 seconds later with ´drivers not found´ or a message like that, with a ´search for drivers´ button below. 1. I pressed ´search for drivers´ and the dialog went away, networking leds flickered a bit, then nothing. (??) I decided I had to try again, unplugged and replugged the device, althought this time, after the flickering stopped, it said once again, that no drivers were found, so I choose the option to ´manually point towards driver´ or words to that effect. A file selection dialog asks you to point to a .psd file. 2. Luckily, I had downloaded the Samsung drivers and unpacked those to the hard drive by then, so I pointed it towards ./drivercd/linux/noarch/bin/(something else, I didn´t keep notes) and there was a long list of .psd files, one for each samsung printer model #. I selected 2160 because I know 2160 and 2165 are the same model# family. Cups did its magic and lo and behold I had a printer object with the right cups driver. 3. When I tried to print, obviously, it failed (you saw that coming), the problem ´rasterizer not found´ or words to that effect. It was complaining about a missing package dubbed ´raster2samsungspl´ engine. Obviously Samsung´s idea is for one to run the ´install script´ as root. Apparently it copies binary files around (and libs, like libstdc++) to fixed destination paths and hopes for the best. My idea, on the other hand, was that cups should be (by now) intelligent enought to search for some sort of ´driver description file´ and install the driver from the cups side, not from a manufacturer-provided ugly bash script. I was wrong. apparently the only way to make it work is by running Samsung´s install bash script. So the $1M question is: can´t Samsung design drivers which can be installed via a package manager (rpm), or via a cups install routine, instead of the current method?. I´m sure they can, in theory. Which is the right venue to complain about this? (other than Samsung, which I´m sure couldn´t care less about us Linux users). There was an ´openprinting´ effort... or perhaps the FSF? or the cups project?. One would think that by 2013 distros would have gotten around to design a foolproof way for hardware manufacturers to properly package drivers (even proprietary blobs) which would then be installed semi-automagically by the Linux printing subsystem, no?. Anything wrong with my analysis?. Yeah, I know "just run the darn manufacturer-provided bash install script and be grateful it at least works". Yes, that´d be the easy way. I don´t think it´s the right way going forward.... No, I´m not asking for directions on how to get my printer working. No, please don´t tell me to update to F17 or F18. No, please don´t start a flamewar. My point is about the packaging of Samsung´s drivers and the install method they have chosen. "doesn´t it suck? what -if anything- can we do to get it improved?". FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
