AppleTalk Printers don't work in Snow Leopard

[John A]

So we upgraded one of our prepress workstations yesterday to Snow Leopard and noticed you can't add AppleTalk printers to your printer list anymore.

Did a little searching this morning on the Apple forums and discovered that AppleTalk is no longer supported in the latest system release.

Unfortunately for us, we use a couple of printers/rips that don't offer IPP (internet printing protocol) as a configurable option.

Just thought I'd pass this along...

 

[MacTwidget]

AppleTalk Printers

AppleTalk Printers

That stinks. I have an old LaserWriter 4/600 PS that I use every day. I connect to it via an old Dayna EtherPrint box.

On the subject of Snow Leopard, I'm still a little miffed that they removed support for the PPC processor so soon. I mean, the last PPC G5s went out of production only a little more than 2.5 years ago. I have a MDD G4 at home that is still perfectly viable and runs Leopard (10.5) well....but now I've hit the ceiling.

 

[PrePress Guru]

Yet another reason to hold off on the upgrade!
A possible solution if you have an OSX 10.4/10.5 server. You can add the printer in as an Appletalk and share it out through the server as IPP, LPR or SMB.
A 10 client license should work and they should be cheaper now. It could double as a workstation/RIP server. Although not ideal it would solve a problem.
I did this here for a few printers that were misbehaving.

 

[cjwworld]

This would be a problem for old Mac oriented printers that don't support IP printing.

But, I like the suggestion to use the Server print server to provide Appletalk services for such printers. Thats added component but would be worth the investment

 

[PrePress Guru]

The workaround does work but come on Apple, support the PPC, AppleTalk and the other apps that SL seems to have broken.
I can see it from their point but part of Apples core user base is the pre press industry.
Lots of us still have legacy devices that require OS level support from Apple.

Anyway, I was just thinking about CUPS this week, i wonder if someone could write a filter or plugin for the CUPS printing system in OSX for Appletalk?
It might be a workable solution. CUPS is very flexible.

 

[mlanger]

Yes, you CAN use your printers with Snow Leopard

Yes, you CAN use your printers with Snow Leopard

Don't panic, guys. Just because AppleTalk is gone, you don't have to toss your printers. I got my 10-year-old HP LaserJet 2100TN working with Snow Leopard without any problems. I outlined the situation with details and references here:

http://www.mariasguides.com/2009/09/03/using-an-hp-laserjet-2100tn-with-snow-leopard/

Good luck and spread the word. It bugs me to see folks missing out on an easy fix.

 

[mattbeals]

Maybe AppleTalk is finally dead....

 

[graficworx]

Snow Leopard & PPC

Snow Leopard & PPC

I don't mean to miff anyone here, just go into a little more technical depth of what Snow Leopard Really is. Starting with the switch to Intel, all new Intel processors are by nature 64 bit. Tiger, and more recently Leopard, are not "natively" 64 bit, meaning their core code is 32 bit, with 64 bit add-on code to take advantage of the newer processors. G4's are 32 bit, and G5's are 64 bit, yet the PPC versions of Panther and Tiger were not native 64 bit either, they had a mixed architecture as well. So essentially Tiger and Leopard were dual architecture, they contained the exact same set of code TWICE, one for PPC, one for Intel. This worked fine in theory, but having a code base twice as large is a bit cumbersome, and takes up additional hard drive space with wasted PPC code an Intel machine will never run, or vice versa.

From the start Apple stated Snow Leopard isn't a replacement for Leopard, more of a re-write for 64-bit Intels, reason why its Snow Leopard; a different kind of Leopard, but still a Leopard. If this was a completely new version, it would have been Cheetah or something.
Snow Leopard is a complete re-write of the operating system to natively be 64-bit Intel. The reason this works as a marketing strategy is over 50% of the Apple install base is now fully Intel. Apple isn't forcing you to replace your G5, all the updates are still being made for Leopard for PPC, and will continue to be done for some time. We still have several G5's here that are in production every day running CS3, and have no need to replace them, and better yet no reason to want to upgrade the OS. If we wanted to go all CS4, then we would have to replace the G5's, but thats Adobe forcing us, not Apple. Hell, Adobe won't even release patches for CS4 for Snow Leopard!

Leopard works fine for what any print shop should need; Snow Leopard didn't introduce any new amazing technology or features that revolutionize the printing industry. I like the idea proposed of the dedicated print box, and I use this myself everyday. We have a G4 XServe running Tiger Server as our print server for all our large (5+) Xerox machines, and it handles this load fine. This way when a computer goes down, or we replace one, the work to setup the printing environment is minimal; install the drivers, point them at the XServe, and you're done. I recommend this for any larger print shop, not only does it save with having problems of different versions of drivers out there (trust me, can be an issue with print consistency), but a centralized print queue helps avoid problems as well.

If you have any other questions, feel free to ask.

- Don

 

[chasd]

I know I am posting to this thread late, but there are some problems I have with the last post.

Starting with the switch to Intel, all new Intel processors are by nature 64 bit.

This is not true.
The very first Intel Macs used 32-bit processors.

Tiger, and more recently Leopard, are not "natively" 64 bit, meaning their core code is 32 bit, with 64 bit add-on code to take advantage of the newer processors.

This is not true.
It was possible to write 64-bit applications for both 10.4.x and 10.5.x.
See this Apple document :
<http://developer.apple.com/macosx/64bit.html>
More of 10.6.x is 64-bit, but it isn't the first Mac OS to have 64-bit capability.
I'm not sure what " add-on code " is or what that term is meant to describe.

G4's are 32 bit, and G5's are 64 bit . . .

True.

. . .yet the PPC versions of Panther and Tiger were not native 64 bit either,. . . .

10.3.x did not have any 64-bit capability, 10.4.x did.
I'm not sure what the word " native " is supposed to mean here.

The PPC processor is capable of switching between 32-bit and 64-bit on the fly. The AMD 64-bit implementation is not pretty ( licensed by Intel ). It requires the processor to be booted into 64-bit mode to use the x86_64 features.

On PPC, mixing 32-bit and 64-bit is easier to do and has fewer complications. So by switching to Intel processors, Apple actually complicated the migration from 32-bit to 64-bit. More work was done by sofware publishers fixing applications to make the processor architecture switch rather than the work to migrate from 32-bit to 64-bit. I could make the conjecture that if Apple would have stayed with PPC we might have migrated to 64-bit sooner.

Oh, there was a 64-bit PPC processor way before the G5 ( it came after the 604, before the G3 and G4, called the 620 ) but it never made it into production or into any Macs.

So essentially Tiger and Leopard were dual architecture, they contained the exact same set of code TWICE, one for PPC, one for Intel. This worked fine in theory, but having a code base twice as large is a bit cumbersome, and takes up additional hard drive space with wasted PPC code an Intel machine will never run, or vice versa.

I never had an issue caused by Universal binaries. If there was a problem, it was due to running PPC code on a x86 processor, which is a separate issue.

Hard drive space is cheap, I don't consider the small gain to be a big deal.
Plus, now you likely have 32-bit libraries and duplicate 64-bit libraries " wasting " some of that hard drive space.

Snow Leopard is a complete re-write of the operating system to natively be 64-bit Intel.

If that was true 10.6.x wouldn't run any 32-bit applications at all.

I must point out that for most applications, being 64-bit won't make it any faster. What happens is that on x86_64, when a system is booted into 64-bit mode, the processor has access to more features that speed up processing. If those features were available in 32-bit mode, you would get the same speed up, or maybe even faster. If an application is 64-bit, it uses more memory for the same task compared to a 32-bit application. Moving that increase in data around the system takes longer.

Also, when the source code for an application is compiled, the compiler can take advantage of those added features available in 64-bit mode, so there is a speed up from that.

Again, both of those performance benefits are not because of 32-bit vs. 64-bit, it is because of how AMD designed the 64-bit mode. However, in order to be able to run existing applications, those super-fast good-guy features can't be enabled in 32-bit mode. This is true for OS X, Windows, Linux, or any OS using x86_64, it isn't a Mac-specific thing.

As for printing via AppleTalk, you don't have to use an Apple server for a print server, a Linux server can work too. Plus, many printers may have LPD support if they don't have IPP support, so you can use that.

In a prepress environment, using hot folders is usually much faster than AppleTalk anyway.

Please don't confuse using Appletalk for printing and Appletalk for file sharing.
Printing via AppleTalk uses PAP ( Printing Access Protocol ) while file sharing via AppleTalk uses AFP ( Apple Filing Protocol ). Another confusing point is that AFP can run over Appletalk or TCP/IP. Apple dropped support for AFP over AppleTalk in 10.4.x. This is simply the other shoe dropping, I'm surprised people hadn't prepared for it since the first show dropped with 10.4.x.


Chasd.

 

[graficworx]

The first intel Core Solo/Duo (Codename Yonah) was in fact a 64 bit processor as it supported the SSE3 instruction set. The fact that Intel called it 32 bit still doesn't make any difference. I wrote and ran 64 bit C code on these processors fine.

I'm not sure why you are confused by the term "natively". Saying that 10.4.7 on an Intel could run 64 bit code does not mean the OS CORE was 64 bit. Many of the main OS libraries were 32/64 bit, or still 32 bit. Core Audio for one was 32 bit still in Tiger. Leopard introduced 64 bit Audio handling.

A processor can be either 32 or 64 bit... its not both. The "bit length" here equates to the length of a single "word" in computer memory. See Word (computing) - Wikipedia, the free encyclopedia

Ever heard of single and double precision? Single precision is the use of 1 word, i.e. 32 bit on a 32 bit processor, and double precision is the use of 2 words, or 64 bit on a 32 bit processor. On a 64 bit processor a word is 64 bits, so single precision is 64 bit and double precision is 128 bit. A 64 bit processor can run 32 bit code, it just pads the end of the register with 0's. A 32 bit processor CANNOT run 64 bit code. A 32-bit address register meant that 2^32 addresses, or 4 GB of RAM, could be referenced. A 64-bit address register means that 2^64 addresses of RAM can be referenced.

It is possible to write 64 bit applications for Tiger and Leopard, as they run on 64 bit processors (including the Core Duo or Core Solo). The fact that the majority of the operating system libraries were still 32 bit code is whats refered to as native 32 bit in the industry. Native 64 bit is an operating system where the core functionality code is compiled as 64 bit. Nothing says you can't have a 32 bit application run on 64 bit, but you cannot have a 64 bit kernel module run on a 32 bit kernel. The kernel is the extreme core of the operating system, and as such all packages must have the same architecture as the kernel. Photoshop 64 bit can run fine in its own virtual machine space ontop of a 32 bit kernel as long as the processor is 64 bit as well. The whole reason why Apple invented Universal was to fix this problem: a PPC, 32 bit and 64 bit application in one package. If you actually look inside a Universal App, you will infact find 3 seperate executables, one PPC (no bit designation), one 32 bit and one 64 bit.
(As a side note, was back in the PPC motorola days Apple supported 64 bit multipliers before Intel had even imagined them.)

The G5 was a 64 bit processor. The Nintendo 64 and PS2 also had a 64 bit processor. The CDC 6600 from 1964 used a 60 bit processor. The idea of 64 bit is not new, the only reason for the "switch" is because personal computers are now running out of physical memory, and the only way to expand beyond 4 gigs is to use 64 bit addressing.

No, 64 bit won't make a program "faster", it just increases the precision of a floating point operation and increases the amount of available physical RAM. I a programmer is really good he can use a 64 bit register to do two 32 bit operations as one. Also, don't forget that in modern CPU's the multipliers return a result in a fraction of a clock cycle, meaning several operations can be performed in one clock cycle. And here's the kicker... A computer can only add 2 numbers, 0 and 1.

0 + 0 = 0
0 + 1 = 0
1 + 1 = 1

MAGIC!

 

[cmcfarling]

While it seems this thread has strayed a bit from Appletalk printers, I'll continue that to reply to the last thread.

The Core Duo and Core Solo are not 64bit processors. Having SSE3 support is not a deciding factor of an Intel processors register width.
Yonah_(microprocessor)
SSE3

Show me any evidence that a 64bit process will run on a Core Duo/Core Solo.

"the only way to expand beyond 4 gigs is to use 64 bit addressing"

Yes and no. If a single process needs more than 4GB then yes. Otherwise the OS can address more than 4GB using PAE and dish out multiple 4GB chunks to multiple processes.

 

[Soluzione]

Try printing to file

Try printing to file

I had a similar trouble. type Command+P to open print dialog box, select imagesetter (panther Por 62, agfa accuset, Screen rt 2035 or anyother), then on PDF option change to any Poscript option. Change other parameters.
If you have a Panther Pro or Panther Plus may be PDF format is incompatible, then select PostScript in print dialog box. Prin to a file an copy the file to a hot folder in the rip.

 

[cjwworld]

. If we wanted to go all CS4, then we would have to replace the G5's, but thats Adobe forcing us, not Apple.

- Don

I am running CS4 on G5 PPC without issues, is there a known problem with this?

 

[[email protected]]

Don't panic, guys. Just because AppleTalk is gone, you don't have to toss your printers. I got my 10-year-old HP LaserJet 2100TN working with Snow Leopard without any problems. I outlined the situation with details and references here(snippity snip). Good luck and spread the word. It bugs me to see folks missing out on an easy fix.

Unfortunately this only works for printers that support tcp/ip and some older AppleTalk printers do not - hence the server solution posted by member: PrePress Guru.

This also invalidates the advertisement for a certain book advertised in your original link because the printer has to support tcp/ip for this solution to work.

 

[pmhapp]

I am running CS4 on G5 PPC without issues, is there a known problem with this?

Yeah, this threw me off too. I think the intent was CS5 on a G5.

 

[kparker]

AppleTalk is Dead! Bonjour!

 

[prepressguru]

we have a 10 year old HP that works perfect with ip printing in 10.6. Could be hit and miss with printers. But HP's are usually well supported by Apple.

P

BTW.. even though you might have a intel mac and upgrade it to 10.6. Don't expect it to run 64 bit apps. Some of the older intels are limited by the EFI firmware and will not support 64 bit. Thanks Apple!