A few things you could try:
1) Set Normalizer signatures to their default values, and add produce-verbose-alert to all of the Normalizer signatures.
Some users have tried disabling Normalizer signatures or removing the default actions on some of the Normalizer signatures. However, sometimes these signatures and actions are necessary for the Normalizer to do it's job and so in some cases the action will stick place even if removed from the configuration. This can cause difficulties in trying to diagnose the issue. So it is better to leave the signatures and actions at their defaults until determining what the problem really is.
Some of the signatures do not have produce-alert by default. Adding produce-verbose-alert will force creation of an alert if these signatures are being triggered, and by doing the "verbose" it can also add more information into the alert.
Now try printing and monitor very closely for any Normalizer signatures firing between the addresses of the Print Client and Print Server.
2) Trace down the packet path for connections to your Print Server. If the packets are passing through your sensor twice for some reason, then the Normalizer could be getting confused.
If your client and server are on separate networks, then the traffic could be being routed through the sensor twice.
There are configuration changes that could be made to alleviate this problem on the sensor if you determine that this is what is happening.
3) Another change to try temporarily is to configure the virtual sensor's inline-TCP-evation-protection-mode to asymetric.
This in effect disables the Normalizer.
If your print server starts working with the sensor in this mode, then the Normalizer is likely doing something to the packets.
The next step would be to set it back to "strict" and using method 1 and 2 above to determine what the issue is.
Once the issue is known, there may be another configuration option for the sensor to get it working right.
The asymetric mode is a good option to get things working temporarily while trying to determine the Normalizer problem. But should only be used long term if you actually are forced to run in an asymetric environment.
4) If the asymetric mode doesn't help, then it is likely Not the Normalizer.
Next step would be to take a closer look at the alerts. It it might be that the particular signature being triggered by your printer communications could be firing often enough that it is in Global Summary mode. And in Global Summary mode you won't see any of the addresses involved.
So look not only for alerts containing the specific IPs, but also for any alerts with 0.0.0.0 as the addresses. The 0.0.0.0 addresses show it is a Global Summary alert.
5) Also take a close look at your filters. You might unintentionally be filtering out the generation of the alert, but still allowing a deny to happen.
