Comment 15 for bug 286048

There are actually two Brother HL-5250DN printers options: one is labeled HL-5250DN, the other is labeled HL-5250DN BR-Script3. The former is a foomatic-generated PPD, and has the line "*cupsManualCopies: True", and therefore never asks the printer hardware to do the copies. The latter lets the hardware do the copies (which I happen to think is the preferable option).

With some experimentation I was in fact finally able to get the n*n bug to be produced: by asking for collated copies. So, here's a table (sorry, the spacing will probably come out wrong):

cpdftocps PPD Collate Copies
mine foomatic True 2
mine foomatic False 2
mine BR-Script3 True 4
mine BR-Script3 False 2
2ubuntu3 foomatic True 2
2ubuntu3 foomatic False 2
2ubuntu3 BR-Script3 True 2
2ubuntu3 BR-Script3 False 1

The basic problem is that when there is a chain of filters, each filter has a shot at multiplying by the number of copies. In principle these scripts need to arrange things so that only one script makes a given modification. The scripts actually attempt to do this (some never multiply copies, some look at the PPD and decide whether they'll do it or let someone later do it). But the logic for doing this is not in shared code, so they can make different decisions. And in practice maybe it's hard to know where you are in the chain. It's not clear to me why something other than the last filter in the chain should be creating multiple copies and/or collating. That way all the logic would be in one place, and to make 10 copies of something you would delay pushing around a file that's 10 times as large as the original until the last possible moment (if at all).

Clearly the simple reversion of the patch is the wrong thing (this was clear from that start). Getting it right will be complicated I think. Presumably upstream doesn't have this problem (?), but I suspect there was some logic to switching to this PDF filter backend in Debian/Ubuntu.