Bouncing the spooler service is the only viable choice that I'm aware of. In my experience, some jobs get "jammed" in a queue so "severely" as to require stopping the spooler server, clearing the files that represent the jobs out of the %SystemRoot%\System32\Spool\Printers folder, and re-starting the spooler service.
You're not going to lose any jobs that are already queued for other printers by bouncing the spooler service (you can demonstrate this yourself on another server or a client-- pause a printer, put some jobs in queue, and stop / restart the spooler serivce), but if you find that you have to go the route of deleting job files from the spool directory you'll have a hard time locating them amid the other spooled files for jobs you intend to keep.
(As an aside: Microsoft could do a lot of enhancemnet of the print spooler service, IMO, to alleviate situations like you're seeing. The print spooler service has languished in a state of relatively little enhancement throughout the last few releases of Windows. Printing isn't sexy, but it's often business critical.)
Each print job is represented in the spool directory by a ".SPL" file (containing the print job data in EMF or raw format) and a matching ".SHD" file, containing "header" information about the job. This header information file contains the details about which printer the job is being sent to.
Deleting the matching pair of the "SPL" and "SHD" files for a given print job effectively deletes that job.
Unfortunately, the format of the ".SHD" file is officially undocumented (see http://www.undocprint.org/formats/winspool/shd for some reverse engineered documentation), so figuring out "which file is which" in the spool directory and deleting only the "corrupt" print jobs is very difficult, at best. From what I can see, the destination print queue name is in that "SHD" file as a uncode string, so I suppose it would be possible to cobble together a script using command-line tools line "strings" and "findstr" to grovel thru all the ".SHD" files to find jobs destined for the "problem" printer and delete them while leaving jobs bound for other printers untouched.
Any manipulation of the spool files has to be done with the spooler service stopped because, while it's running, the files are locked.