| 1 |
On 29/12/17 16:13, Alan McKinnon wrote: |
| 2 |
> The only "correct" place for papersize nowadays is in whatever the user |
| 3 |
> is using to get something to print. And there are lots of those. |
| 4 |
> Something like CUPS ought to make it all so much easier but I find CUPS |
| 5 |
> just makes my life insanely difficult. So I mail my docs to my wife and |
| 6 |
> she prints them from Windows for me |
| 7 |
|
| 8 |
Exactly! |
| 9 |
|
| 10 |
I think the problem is all the layers of indirection and pipes. If you |
| 11 |
*pipe* a print job, it is very difficult to pass metadata such as |
| 12 |
papersize along. So the only place the printing back end can get this |
| 13 |
information from is the defaults. And if you've got something like a |
| 14 |
photo-printer when half the time the paper is different from the |
| 15 |
default, you're up a gum tree ... and of course you can't have the app |
| 16 |
change the defaults because you can't guarantee that by the time that |
| 17 |
job hits the printer some other app hasn't come along and changed them |
| 18 |
to something different ... |
| 19 |
|
| 20 |
It would be fine, of course, if all apps used the CUPS printer dialog, |
| 21 |
but my experience is that a lot of cross-platform apps use their own |
| 22 |
because CUPS isn't there for a lot of their target market ... on Windows |
| 23 |
they can guarantee the windows dialog, on Apple they can guarantee CUPS, |
| 24 |
but on linux? It's *usually* - but not always - there so they need to be |
| 25 |
able to cope if it's missing, so they just assume it isn't ... |
| 26 |
|
| 27 |
(Plus, of course, so much development is done for the American market, |
| 28 |
so they don't realise how hard it is to get a change like A4 to stick :-( |
| 29 |
|
| 30 |
Cheers, |
| 31 |
Wol |
Archives