Moments in Time Photography
You are currently browsing the archive for the Mac OS X category.
I’ve written a post about how to set up Mac OS X 10.7 (Lion) for use with the WFT-E1 (or later). As it is quite technical, I’ve placed it in Random Problem (solved) blog:
http://randomproblem.blogspot.com/2011/11/using-canon-wft-e1-with-mac-os-x-107.html
Enjoy!
On Mac OS X 10.6 (Snow Leopard) a non-administrator user can not change all settings of the installed printers. This is really annoying when a printer error causes the print queue to go on hold: the user can not resume printing when the problem has been solved. Instead, a dialog pops up asking for the user name and password of a member of the “Print Operators” group. Usually, that means a system administrator has to manually enter the credentials before the user can resume working.
The problem is caused by the fact that only members of the group “Print Operators” are allowed to control the printer. Normal users (i.e. members of the group “Staff“) are not automatically added to the group “Print Operators“. This makes sense in an environment where you don’t want Joe Public messing with printer settings. It makes less sense in a lab or production environment where the staff can be trusted with the printers.
Fortunately, I found a simple solution here:
In Terminal.app, type the following:
dseditgroup -o edit -u ADMINUSER -p -a USER -t user _lpadmin
where ADMINUSER is the user name of an administrator and USER is the user name you want controlling the printer.
You will be asked for the password of ADMINUSER and then USER is added to the “_lpadmin” group, solving the problem permanently.
CAUTION
A word of advice to the wise: I do not know if adding a user to the group “_lpadmin” has any side effects. The users of the machines I administer are considered trustworthy. The only reason they do not have administrative privileges is to protect the machines from unintended damage. So giving limited administrative privileges is not a problem. This may be different in your environment.
Consider the implications carefully before making changes!
Background Information
It appears that the problems observed are not uniform: some machines always show the problem, some not at all, and some only for some users.
It looks like Apple changed the defaults some time during the life-cycle of Mac OS X 10.5 (I have been unable to ascertain when exactly). Users created before the change were all members of “_lpadmin“, users created later are not members.
The best solution would be to tell CUPS (the printing system used in Mac OS X) to allow members of the group “Staff” to control the printer. To do so, the file /etc/cups/cupsd.conf section
Require user @AUTHKEY(system.print.operator) @admin @lpadmin
Order deny,allow
needs to be changed to something like
Require user @AUTHKEY(system.print.operator) @admin @lpadmin @staff
Order deny,allow
I did not try this myself. If you do, you may find cupsd.conf documentation useful. I would appreciate a comment telling about your experiences. Good luck!
We recently received some photos from a family event that were – gasp – made using analog film. You should have seen the look on the face of the dozen or so children when they crowded around the SLR expecting to see a preview on the LCD only to discover that there was no LCD on the back of this camera. Talk about culture shock. 😉
Anyways, the quality of the prints was appaling, as where the scanned images on the CD that came from the processing lab. The negative, however, looked fine to my no-longer-used-to-look-at-negatives eyes. I decided to revitalize an old film scanner I still have in a box. It is a rebadged Pacific Imaging PrimeFilm 1800u scanner, which will turn a negative into a 4 Mpxl file with 16 bits per color channel.
I like using VueScan with flatbed scanners. It is a low-cost, high-power solution and Ed Hamrick does a fantastic job of supporting almost every scanner under the sun. My experience so far has been that you plug in the scanner, start VueScan, and start scanning.
With the PF1800u it turns out to be a little bit more complicated than that:
“Open using Rosetta” in the Finder “Get Info” panel.
You can skip steps 3 & 4 if you are using a PowerPC Mac. CyberViewX_SF is a PowerPC application, so Intel Macs need to be told to run PowerPC code because though VueScan is a native Intel application. I wish Pacific Imaging would update their driver!
I had some difficulties because CyberViewX_SF is not in the default install location on my system. In this case, VueScan can not find the driver it needs and complains.
If you – like I – want to put your applications in a non-default place, you can create a soft (or hard) link to it to make VueScan happy:
$ sudo ln -s /Applications/Graphics/CyberViewX_SF /Applications/CyberViewX_SF
where “/Applications/Graphics/” is the location of the CyberViewX_SF folder. That’s it!
Thanks to Ed Hamrick for the great support!
Update: Since Mac OS X 10.7 (Lion), Apple has dropped support for PowerPC code. You can no longer install Rosetta, so your scanner is just a paperweight if you switch to 10.7 or later.
I had an interesting experience with Mac OS X (10.5.6 for the record) today: I use a KVM switch to connect a single keyboard, monitor, and mouse to a number of computers. I swapped my Microsoft Comfort Curve Keyboard 2000 for a Unicomp Customizer 105 (which rocks, by the way!) and started typing away. To my dismay, the ^° key was recognized as <> – and vice versa.
The keyboard layout was still correctly set to a German layout but Mac OS X thought that the KVM switch was the actual keyboard (it certainly identifies itself as a HID). So it looks like Mac OS X can not see that the keyboard type has changed and the wonderfully simple process that works when connection a keyboard directly fails to even get started.
Read the rest of this entry »
