summaryrefslogtreecommitdiff
path: root/docs-xml/Samba3-HOWTO/TOSHARG-CUPS-printing.xml
blob: 9b12e4cac59ef8f9d95ef5036ad6b37405e4b749 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="CUPS-printing">

<chapterinfo>

	<author>
		<firstname>Kurt</firstname><surname>Pfeifle</surname>
		<affiliation>
			<orgname>Danka Deutschland GmbH </orgname>
                        <address><email>kpfeifle@danka.de</email></address>
		</affiliation>
	</author>
	<author>
		<firstname>Ciprian</firstname><surname>Vizitiu</surname>
		<affiliation>
			<address><email>CVizitiu@gbif.org</email></address>
		</affiliation>
		<contrib>drawings</contrib>
	</author>

	<author>&person.jelmer;<contrib>drawings</contrib></author>

	<pubdate> (27 Jan 2004) </pubdate>
</chapterinfo>

<title>CUPS Printing Support</title>

<sect1>

	<title>Introduction</title>

	<sect2>
		<title>Features and Benefits</title>

		<para>
<indexterm><primary>default printing</primary></indexterm>
		The Common UNIX Print System (<ulink url="http://www.cups.org/">CUPS</ulink>)
		has become quite popular. All major Linux distributions now ship it as their default printing
		system. To many, it is still a mystical tool. Mostly, it just works.  People tend to regard
		it as a <quote>black box</quote> that they do not want to look into as long as it works. But once
		there is a little problem, they have trouble finding out where to start debugging it. Refer to
		<link linkend="classicalprinting">Classical Printing</link>, which contains much information
		that is also relevant to CUPS.
		</para>

		<para>
<indexterm><primary>CUPS</primary></indexterm>
		CUPS sports quite a few unique and powerful features. While its basic functions may be grasped quite
		easily, they are also new. Because it is different from other, more traditional printing systems, it is best
		not to try to apply any prior knowledge about printing to this new system. Rather, try to understand CUPS from
		the beginning. This documentation will lead you to a complete understanding of CUPS. Let's start with the most
		basic things first.
		</para>

	</sect2>

	<sect2>
	<title>Overview</title>

	<para>
<indexterm><primary>print spooling system</primary></indexterm>
<indexterm><primary>CUPS</primary></indexterm>
<indexterm><primary>printer management system</primary></indexterm>
<indexterm><primary>IETF</primary></indexterm>
<indexterm><primary>Internet Printing Protocol</primary><see>IPP</see></indexterm>
<indexterm><primary>Internet Engineering Task Force</primary><see>IETF</see></indexterm>
<indexterm><primary>GUI</primary></indexterm>
<indexterm><primary>KDEPrint</primary></indexterm>
	CUPS is more than just a print spooling system. It is a complete printer management system that
	complies with the new Internet Printing Protocol (IPP). IPP is an industry and Internet Engineering Task Force
	(IETF) standard for network printing. Many of its functions can be managed remotely (or locally) via a Web
	browser (giving you platform-independent access to the CUPS print server). Additionally, it has the
	traditional command line and several more modern GUI interfaces (GUI interfaces developed by third parties,
	like KDE's overwhelming <ulink url="http://printing.kde.org/">KDEPrint</ulink>).
	</para>

	<para>
<indexterm><primary>raw printers</primary></indexterm>
<indexterm><primary>smart printers</primary></indexterm>
	CUPS allows creation of <emphasis>raw</emphasis> printers (i.e., no print file format translation) as
	well as <emphasis>smart</emphasis> printers (i.e., CUPS does file format conversion as required for the
	printer). In many ways, this gives CUPS capabilities similar to the MS Windows print monitoring system. Of
	course, if you are a CUPS advocate, you would argue that CUPS is better! In any case, let us now explore how
	to configure CUPS for interfacing with MS Windows print clients via Samba.
	</para>

	</sect2>

</sect1>

<sect1>
	<title>Basic CUPS Support Configuration</title>

	<para>
<indexterm><primary>CUPS</primary></indexterm>
<indexterm><primary>cupsd.conf</primary></indexterm>
<indexterm><primary>/etc/printcap</primary></indexterm>
<indexterm><primary>Printcap</primary></indexterm>
<indexterm><primary>PrintcapFormat</primary></indexterm>
Printing with CUPS in the most basic &smb.conf; setup in Samba-3.0 (as was true for 2.2.x) requires just two
parameters: <smbconfoption name="printing">cups</smbconfoption> and <smbconfoption
name="printcap">cups</smbconfoption>. CUPS does not need a printcap file.  However, the
<filename>cupsd.conf</filename> configuration file knows of two related directives that control how such a
file will be automatically created and maintained by CUPS for the convenience of third-party applications
(example: <parameter>Printcap /etc/printcap</parameter> and <parameter>PrintcapFormat BSD</parameter>).
Legacy programs often require the existence of a printcap file containing printer names or they will refuse to
print. Make sure CUPS is set to generate and maintain a printcap file. For details, see <command>man
cupsd.conf</command> and other CUPS-related documentation, like the wealth of documents regarding the CUPS
server itself available from the <ulink noescape="1"
url="http://localhost:631/documentation.html">CUPS</ulink> web site.
	</para>

	<sect2>
	<title>Linking smbd with libcups.so</title>

	<para>
<indexterm><primary>libcups.so</primary></indexterm>
	Samba has a special relationship to CUPS. Samba can be compiled with CUPS library support.
	Most recent installations have this support enabled. By default, CUPS linking is compiled
	into smbd and other Samba binaries. Of course, you can use CUPS even
	if Samba is not linked against <filename>libcups.so</filename> &smbmdash; but
	there are some differences in required or supported configuration.
	</para>

	<para>
<indexterm><primary>libcups</primary></indexterm>
<indexterm><primary>ldd</primary></indexterm>
	When Samba is compiled and linked with <filename>libcups</filename>, <smbconfoption name="printcap">cups</smbconfoption>
	uses the CUPS API to list printers, submit jobs, query queues, and so on. Otherwise it maps to the System V
	commands with an additional <command>-oraw</command> option for printing. On a Linux
	system, you can use the <command>ldd</command> utility to find out if smbd has been linked with the
	libcups library (<command>ldd</command> may not be present on other OS platforms, or its function may be embodied
	by a different command):
<screen>
&rootprompt;<userinput>ldd `which smbd`</userinput>
libssl.so.0.9.6 =&gt; /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 =&gt; /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 =&gt; /usr/lib/libcups.so.2 (0x40123000)
[....]
</screen>
	</para>

	<para>
<indexterm><primary>libcups.so.2</primary></indexterm>
	The line <computeroutput>libcups.so.2 =&gt; /usr/lib/libcups.so.2 (0x40123000)</computeroutput> shows
	there is CUPS support compiled into this version of Samba. If this is the case, and printing = cups
	is set, then <emphasis>any otherwise manually set print command in &smb.conf; is ignored</emphasis>.
	This is an important point to remember!
	</para>

	<tip><para> Should it be necessary, for any reason, to set your own print commands, you can do this by setting
	<smbconfoption name="printing">sysv</smbconfoption>. However, you will lose all the benefits
	of tight CUPS-Samba integration. When you do this, you must manually configure the printing system commands
	(most important: 
	<smbconfoption name="print command"/>; other commands are
	<smbconfoption name="lppause command"/>,
	<smbconfoption name="lpresume command"/>,
	<smbconfoption name="lpq command"/>,
	<smbconfoption name="lprm command"/>,
	<smbconfoption name="queuepause command"/> and
	<smbconfoption name="queue resume command"/>).
	</para></tip>

	</sect2>

	<sect2>
	<title>Simple &smb.conf; Settings for CUPS</title>

	<para>
	To summarize, <link linkend="cups-exam-simple">the Simplest Printing-Related 
	&smb.conf; file</link> shows the simplest printing-related setup for &smb.conf; to 
	enable basic CUPS support:
	</para>

	<example id="cups-exam-simple">
	<title>Simplest Printing-Related smb.conf</title>
	<smbconfblock>
	<smbconfsection name="[global]"/>
	<smbconfoption name="load printers">yes</smbconfoption>
	<smbconfoption name="printing">cups</smbconfoption>
	<smbconfoption name="printcap name">cups</smbconfoption>

	<smbconfsection name="[printers]"/>
	<smbconfoption name="comment">All Printers</smbconfoption>
	<smbconfoption name="path">/var/spool/samba</smbconfoption>
	<smbconfoption name="browseable">no</smbconfoption>
	<smbconfoption name="public">yes</smbconfoption>
	<smbconfoption name="guest ok">yes</smbconfoption>
	<smbconfoption name="writable">no</smbconfoption>
	<smbconfoption name="printable">yes</smbconfoption>
	<smbconfoption name="printer admin">root, @ntadmins</smbconfoption>
	</smbconfblock>
	</example>

	<para>
<indexterm><primary>PDF</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>printer driver</primary></indexterm>
	This is all you need for basic printing setup for CUPS. It will print all graphic, text, PDF, and PostScript
	files submitted from Windows clients. However, most of your Windows users would not know how to send these
	kinds of files to print without opening a GUI application. Windows clients tend to have local printer drivers
	installed, and the GUI application's print buttons start a printer driver. Your users also rarely send files
	from the command line. Unlike UNIX clients, they rarely submit graphic, text, or PDF formatted files directly
	to the spooler. They nearly exclusively print from GUI applications with a <quote>printer driver</quote>
	hooked between the application's native format and the print data stream. If the backend printer is not a
	PostScript device, the print data stream is <quote>binary,</quote> sensible only for the target printer. Read
	on to learn what problem this may cause and how to avoid it.
	</para>

	</sect2>

	<sect2>
	<title>More Complex CUPS &smb.conf; Settings</title>

	<para>
	<link linkend="overridesettings">The Overriding Global CUPS Settings for One Printer example</link> 
	is a slightly more complex printing-related setup for &smb.conf;. It enables general CUPS printing
	support for all printers, but defines one printer share, which is set up differently. 
	</para>

	<example id="overridesettings">
	<title>Overriding Global CUPS Settings for One Printer</title>
	<smbconfblock>
	<smbconfsection name="[global]"/>
	<smbconfoption name="printing">cups</smbconfoption>
	<smbconfoption name="printcap name">cups</smbconfoption>
	<smbconfoption name="load printers">yes</smbconfoption>

	<smbconfsection name="[printers]"/>
	<smbconfoption name="comment">All Printers</smbconfoption>
	<smbconfoption name="path">/var/spool/samba</smbconfoption>
	<smbconfoption name="public">yes</smbconfoption>
	<smbconfoption name="guest ok">yes</smbconfoption>
	<smbconfoption name="writable">no</smbconfoption>
	<smbconfoption name="printable">yes</smbconfoption>
	<smbconfoption name="printer admin">root, @ntadmins</smbconfoption>

	<smbconfsection name="[special_printer]"/>
	<smbconfoption name="comment">A special printer with his own settings</smbconfoption>
	<smbconfoption name="path">/var/spool/samba-special</smbconfoption>
	<smbconfoption name="printing">sysv</smbconfoption>
	<smbconfoption name="printcap">lpstat</smbconfoption>
	<smbconfoption name="print command">echo "NEW: `date`: printfile %f" >> /tmp/smbprn.log ; echo "     `date`: p-%p s-%s f-%f" >> /tmp/smbprn.log ; echo "     `date`: j-%j J-%J z-%z c-%c" >> /tmp/smbprn.log ; rm %f </smbconfoption>
	<smbconfoption name="public">no</smbconfoption>
	<smbconfoption name="guest ok">no</smbconfoption>
	<smbconfoption name="writable">no</smbconfoption>
	<smbconfoption name="printable">yes</smbconfoption>
	<smbconfoption name="printer admin">kurt</smbconfoption>
	<smbconfoption name="hosts deny">0.0.0.0</smbconfoption>
	<smbconfoption name="hosts allow">turbo_xp, 10.160.50.23, 10.160.51.60</smbconfoption>
	</smbconfblock>
	</example>

	<para>
	This special share is only for testing purposes. It does not write the print job to a file. It just logs the job parameters
	known to Samba into the <filename>/tmp/smbprn.log</filename> file and deletes the job-file. Moreover, the
	<smbconfoption name="printer admin"/> of this share is <quote>kurt</quote> (not the <quote>@ntadmins</quote> group),
	guest access is not allowed, the share isn't published to the Network Neighborhood (so you need to know it is there), and it
	allows access from only three hosts. To prevent CUPS from kicking in and taking over the print jobs for that share, we need to set
	<smbconfoption name="printing">sysv</smbconfoption> and <smbconfoption name="printcap">lpstat</smbconfoption>.
	</para>

	</sect2>

</sect1>

<sect1>
	<title>Advanced Configuration</title>

	<para>
	Before we delve into all the configuration options, let us clarify a few points. <emphasis>Network printing
	needs to be organized and set up correctly</emphasis>. This frequently doesn't happen. Legacy systems or small
	business LAN environments often lack design and good housekeeping.
	</para>


	<sect2>
	<title>Central Spooling vs. <quote>Peer-to-Peer</quote> Printing</title>


	<para>
<indexterm><primary>spooling</primary></indexterm>
	<indexterm><primary>spooling</primary><secondary>central</secondary></indexterm>
	<indexterm><primary>spooling</primary><secondary>peer-to-peer</secondary></indexterm>
	Many small office or home networks, as well as badly organized larger environments, allow each client a direct
	access to available network printers. This is generally a bad idea. It often blocks one client's access to the
	printer when another client's job is printing. It might freeze the first client's application while it is
	waiting to get rid of the job. Also, there are frequent complaints about various jobs being printed with their
	pages mixed with each other. A better concept is the use of a print server: it routes all jobs through one
	central system, which responds immediately, takes jobs from multiple concurrent clients, and transfers them to
	the printer(s) in the correct order.
	</para>

	</sect2>

	<sect2>
	<title>Raw Print Serving: Vendor Drivers on Windows Clients</title>

	<para>
	<indexterm><primary>spooling-only</primary></indexterm>
	<indexterm><primary>raw printing</primary></indexterm>
	Most traditionally configured UNIX print servers acting on behalf of
	Samba's Windows clients represented a really simple setup. Their only
	task was to manage the <quote>raw</quote> spooling of all jobs handed to them by
	Samba. This approach meant that the Windows clients were expected to
	prepare the print job file that is ready to be sent to the printing
	device. In this case, a native (vendor-supplied) Windows printer driver needs to
	be installed on each and every client for the target device.
	</para>

	<para>
<indexterm><primary>render</primary></indexterm>
<indexterm><primary>vendor-provided drivers</primary></indexterm>
	It is possible to configure CUPS, Samba, and your Windows clients in the
	same traditional and simple way. When CUPS printers are configured
	for raw print-through mode operation, it is the responsibility of the
	Samba client to fully render the print job (file). The file must be
	sent in a format that is suitable for direct delivery to the
	printer. Clients need to run the vendor-provided drivers to do
	this. In this case, CUPS will not do any print file format conversion
	work.
	</para>

	<para>
	The easiest printing configuration possible is raw print-through.
	This is achieved by installation of the printer as if it were physically
	attached to the Windows client. You then redirect output to a raw network
	print queue. This procedure may be followed to achieve this:
	</para>

	<procedure>
	<title>Configuration Steps for Raw CUPS Printing Support</title>

		<step><para>
<indexterm><primary>/etc/cups/mime.types</primary></indexterm>
		Edit <filename>/etc/cups/mime.types</filename> to uncomment the line
		near the end of the file that has:
<screen>
#application/octet-...
</screen>
		</para></step>

		<step><para>
<indexterm><primary>/etc/cups/mime.convs</primary></indexterm>
		Do the same for the file <filename>/etc/cups/mime.convs</filename>.
		</para></step>

		<step><para>
		Add a raw printer using the Web interface. Point your browser at
		<constant>http://localhost:631</constant>. Enter Administration, and add
		the printer following the prompts. Do not install any drivers for it.
		Choose Raw. Choose queue name <constant>Raw Queue</constant>.
		</para></step>

		<step><para>
		In the &smb.conf; file <constant>[printers]</constant> section add
		<smbconfoption name="use client driver">Yes</smbconfoption>,
		and in the <constant>[global]</constant> section add
		<smbconfoption name="printing">CUPS</smbconfoption>, plus
		<smbconfoption name="printcap">CUPS</smbconfoption>.
		</para></step>

		<step><para>
		Install the printer as if it is a local printer, that is, Printing to <constant>LPT1:</constant>.
		</para></step>

		<step><para>
		Edit the configuration under the <guimenu>Detail</guimenu> tab and create a
		<constant>local port</constant> that points to the raw printer queue that
		you have configured above. Example: <constant>\\server\raw_q</constant>.
		Here, the name <constant>raw_q</constant> is the name you gave the print
		queue in the CUPS environment.
		</para></step>
	</procedure>

	</sect2>

	<sect2>
	<title>Installation of Windows Client Drivers</title>

	<para>
	The printer drivers on the Windows clients may be installed
	in two functionally different ways:
	</para>

	<itemizedlist>
	<listitem><para>Manually install the drivers locally on each client,
	one by one; this yields the old LanMan style
	printing and uses a <filename>\\sambaserver\printershare</filename>
	type of connection.</para></listitem>


	<listitem><para>
	<indexterm><primary>point 'n' print</primary></indexterm>
			Deposit and prepare the drivers (for later download) on
			the print server (Samba); this enables the clients to use
	<quote>Point'n'Print</quote> to get drivers semi-automatically installed the
	first time they access the printer; with this method NT/200x/XP
	clients use the <emphasis>SPOOLSS/MS-RPC</emphasis>
	type printing calls.</para></listitem>
	</itemizedlist>

	<para>
	The second method is recommended for use over the first.
	</para>
	</sect2>

	<sect2 id="cups-raw">
	<title>Explicitly Enable <quote>raw</quote> Printing for <emphasis>application/octet-stream</emphasis></title>


	<para>
	<indexterm><primary>application/octet-stream</primary></indexterm>
	<indexterm><primary>raw printing</primary></indexterm>
	<indexterm><primary>MIME</primary><secondary>raw</secondary></indexterm>
	If you use the first option (drivers are installed on the client
	side), there is one setting to take care of: CUPS needs to be told
	that it should allow <quote>raw</quote> printing of deliberate (binary) file
	formats. The CUPS files that need to be correctly set for raw mode
	printers to work are:
	</para>

	<itemizedlist>
		<listitem><para><filename>/etc/cups/mime.types</filename></para></listitem>
		<listitem><para><filename>/etc/cups/mime.convs</filename></para></listitem>
	</itemizedlist>

	<para>
	Both contain entries (at the end of the respective files) that must be uncommented to allow RAW mode
	operation.  In <filename>/etc/cups/mime.types</filename>, make sure this line is present:
<programlisting>
application/octet-stream
</programlisting>
	<indexterm><primary>/etc/cups/mime.convs</primary></indexterm>
	<indexterm><primary>/etc/cups/mime.types</primary></indexterm>
	In <filename>/etc/cups/mime.convs</filename>, have this line:
	<indexterm><primary>application/vnd.cups-raw</primary></indexterm>
<programlisting>
application/octet-stream   application/vnd.cups-raw   0   - 
</programlisting>
	If these two files are not set up correctly for raw Windows client
	printing, you may encounter the dreaded <computeroutput>Unable to
	convert file 0</computeroutput> in your CUPS <filename>error_log</filename> file. 
	</para>

	<note><para>
	Editing the <filename>mime.convs</filename> and the <filename>mime.types</filename> file does
	not <emphasis>enforce</emphasis> <quote>raw</quote> printing, it only <emphasis>allows</emphasis> it.
	</para></note>

	<formalpara><title>Background</title>

	<para>
	<indexterm><primary>application/octet-stream</primary></indexterm>
<indexterm><primary>MIME type</primary></indexterm>
	That CUPS is a more security-aware printing system than traditional ones does not by default allow a user to
	send deliberate (possibly binary) data to printing devices. This could be easily abused to launch a
	<quote>Denial of Service</quote> attack on your printer(s), causing at least the loss of a lot of paper and
	ink. <quote>Unknown</quote> data are tagged by CUPS as <parameter>MIME type: application/octet-stream</parameter>
	and not allowed to go to the printer. By default, you can only send other (known) MIME types <quote>raw.</quote>
	Sending data <quote>raw</quote> means that CUPS does not try to convert them and passes them to the printer
	untouched.
	</para>
	</formalpara>

	<para>
	This is all you need to know to get the CUPS/Samba combo printing
	<quote>raw</quote> files prepared by Windows clients, which have vendor drivers
	locally installed. If you are not interested in background information about
	more advanced CUPS/Samba printing, simply skip the remaining sections
	of this chapter.
	</para>

	</sect2>

	<sect2>
	<title>Driver Upload Methods</title>

	<para>
	This section describes three familiar methods, plus one new one, by which
	printer drivers may be uploaded.
	</para>

	<para>
	<indexterm><primary>point'n'print</primary></indexterm>
	If you want to use the MS-RPC-type printing, you must upload the
	drivers onto the Samba server first (<smbconfsection name="[print$]"/>
	share). For a discussion on how to deposit printer drivers on the
	Samba host (so the Windows clients can download and use them via
	<quote>Point'n'Print</quote>), please refer to the <link linkend="classicalprinting">Classical Printing
	chapter</link> of this book. There you will find a description or reference to
	three methods of preparing the client drivers on the Samba server:
	</para>

	<itemizedlist>
		<listitem><para>
		<indexterm><primary>add printer wizard</primary></indexterm>
		The GUI, <quote>Add Printer Wizard</quote> <emphasis>upload-from-a-Windows-client</emphasis> method.
		</para></listitem>

		<listitem><para>
		The command line, <quote>smbclient/rpcclient</quote> upload-from-a-UNIX-workstation method.
		</para></listitem>

		<listitem><para>
		<indexterm><primary>imprints</primary></indexterm>
		The Imprints tool set method.
		</para></listitem>
	</itemizedlist>

	<para> 
<indexterm><primary>cupsaddsmb</primary></indexterm>
	These three methods apply to CUPS all the same. The <command>cupsaddsmb</command> utility is a new and more
	convenient way to load the Windows drivers into Samba and is provided if you use CUPS.
	</para>

	<para>
	<command>cupsaddsmb</command> is discussed in much detail later in this chapter. But we first
	explore the CUPS filtering system and compare the Windows and UNIX printing architectures.
	</para>

	</sect2>

</sect1>

<sect1>
	<title>Advanced Intelligent Printing with PostScript Driver Download</title>

	<para>
	<indexterm><primary>PostScript</primary><seealso>Ghostscript</seealso></indexterm>
	We now know how to set up a <quote>dump</quote> print server, that is, a server that spools
	print jobs <quote>raw</quote>, leaving the print data untouched.
	</para>

	<para>
	You might need to set up CUPS in a smarter way. The reasons could be manifold:
	</para>

<indexterm><primary>print statistics</primary></indexterm>
<indexterm><primary>average print run</primary></indexterm>
<indexterm><primary>print quota</primary></indexterm>
	<itemizedlist>
	<listitem><para>Maybe your boss wants to get monthly statistics: Which
	printer did how many pages? What was the average data size of a job?
	What was the average print run per day? What are the typical hourly
	peaks in printing? Which department prints how much?</para></listitem>

	<listitem><para>Maybe you are asked to set up a print quota system:
	Users should not be able to print more jobs once they have surpassed
	a given limit per period.</para></listitem>

	<listitem><para>Maybe your previous network printing setup is a mess
	and must be re-organized from a clean beginning.</para></listitem>

	<listitem><para>Maybe you are experiencing too many <quote>blue screens</quote>
	originating from poorly debugged printer drivers running in NT <quote>kernel mode</quote>?</para></listitem>
	</itemizedlist>

	<para>
	These goals cannot be achieved by a raw print server. To build a
	server meeting these requirements, you'll first need to learn
	how CUPS works and how you can enable its features.
	</para>

	<para>
	What follows is the comparison of some fundamental concepts for
	Windows and UNIX printing, then a description of the
	CUPS filtering system, how it works, and how you can tweak it.
	</para>

	<sect2 id="gdipost">
	<title>GDI on Windows, PostScript on UNIX</title>

	<para>
	<indexterm><primary>GDI</primary></indexterm>
	<indexterm><primary>PostScript</primary></indexterm>
	Network printing is one of the most complicated and error-prone
	day-to-day tasks any user or administrator may encounter. This is
	true for all OS platforms, and there are reasons it is so.
	</para>


	<para>
	<indexterm><primary>PCL</primary></indexterm>
	<indexterm><primary>PDL</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>Adobe</primary></indexterm>
<indexterm><primary>page description languages</primary><see>PDL</see></indexterm>
	You can't expect to throw just any file format at a printer and have it get printed. A file format conversion
	must take place. The problem is that there is no common standard for print file formats across all
	manufacturers and printer types. While PostScript (trademark held by Adobe) and, to an extent, PCL (trademark
	held by Hewlett-Packard) have developed into semi-official <quote>standards</quote> by being the most widely
	used page description languages (PDLs), there are still many manufacturers who <quote>roll their own</quote>
	(their reasons may be unacceptable license fees for using printer-embedded PostScript interpreters, and so on).
	</para>

	</sect2>

	<sect2>
	<title>Windows Drivers, GDI, and EMF</title>

	<para>
	<indexterm><primary>GDI</primary></indexterm>
	<indexterm><primary>EMF</primary></indexterm>
	<indexterm><primary>WYSIWYG</primary></indexterm>
<indexterm><primary>Enhanced MetaFile</primary><see>EMF</see></indexterm>
	In Windows OS, the format conversion job is done by the printer drivers. On MS Windows OS platforms all
	application programmers have at their disposal a built-in API, the graphical device interface (GDI), as part
	and parcel of the OS itself to base themselves on. This GDI core is used as one common unified ground for all
	Windows programs to draw pictures, fonts, and documents <emphasis>on screen</emphasis> as well as <emphasis>on
	paper</emphasis> (print). Therefore, printer driver developers can standardize on a well-defined GDI output
	for their own driver input. Achieving WYSIWYG (What You See Is What You Get) is relatively easy, because the
	on-screen graphic primitives, as well as the on-paper drawn objects, come from one common source. This source,
	the GDI, often produces a file format called Enhanced MetaFile (EMF). The EMF is processed by the printer
	driver and converted to the printer-specific file format.
	</para>

	<note><para>
	<indexterm><primary>PDF</primary></indexterm>
<indexterm><primary>Xprint</primary></indexterm>
<indexterm><primary>core graphic engine</primary></indexterm>
	To the GDI foundation in MS Windows, Apple has chosen to put paper and screen output on a common foundation
	for its (BSD-UNIX-based, did you know?) Mac OS X and Darwin operating <indexterm><primary>X Window
	System</primary></indexterm> <indexterm><primary>PostScript</primary></indexterm>
	<indexterm><primary>PCL</primary></indexterm> <indexterm><primary>Xprint</primary></indexterm> systems.
	Apple's <emphasis>core graphic engine</emphasis> uses a <emphasis>PDF</emphasis> derivative for all display work.
	</para></note>

	<para>
	The example in <link linkend="1small">Windows Printing to a Local Printer</link> illustrates local Windows
	printing.
	</para>

	<figure id="1small">
		<title>Windows Printing to a Local Printer.</title>
		<imagefile>1small</imagefile>
	</figure>

	</sect2>

	<sect2>
	<title>UNIX Printfile Conversion and GUI Basics</title>

	<para>
	<indexterm><primary>X Window System</primary></indexterm>
	<indexterm><primary>PostScript</primary></indexterm>
	<indexterm><primary>PCL</primary></indexterm>
	<indexterm><primary>Xprint</primary></indexterm>
	In UNIX and Linux, there is no comparable layer built into the OS kernel(s) or the X (screen display) server.
	Every application is responsible for itself to create its print output. Fortunately, most use PostScript and
	that at least gives some common ground. Unfortunately, there are many different levels of quality for this
	PostScript. And worse, there is a huge difference (and no common root) in the way the same document is
	displayed on screen and how it is presented on paper. WYSIWYG is more difficult to achieve. This goes back to
	the time, decades ago, when the predecessors of X.org, designing the UNIX foundations and protocols for
	graphical user interfaces, refused to take responsibility for <quote>paper output</quote>, as some had
	demanded at the time, and restricted itself to <quote>on-screen only.</quote> (For some years now, the
	<quote>Xprint</quote> project has been under development, attempting to build printing support into the X
	framework, including a PostScript and a PCL driver, but it is not yet ready for prime time.) You can see this
	unfavorable inheritance up to the present day by looking into the various <quote>font</quote> directories on
	your system; there are separate ones for fonts used for X display and fonts to be used on paper.
	</para>

	<formalpara>
	<title>Background</title>

	<para>
	<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>color</primary></indexterm>
<indexterm><primary>linewidth</primary></indexterm>
<indexterm><primary>scale</primary></indexterm>
<indexterm><primary>distort</primary></indexterm>
<indexterm><primary>rotate</primary></indexterm>
<indexterm><primary>shift</primary></indexterm>
<indexterm><primary>raster images</primary></indexterm>
<indexterm><primary>display PostScript</primary></indexterm>
<indexterm><primary>graphical objects</primary></indexterm>
	The PostScript programming language is an <quote>invention</quote> by Adobe, but its specifications have been
	published extensively. Its strength lies in its powerful abilities to describe graphical objects (fonts,
	shapes, patterns, lines, curves, and dots), their attributes (color, linewidth), and the way to manipulate
	(scale, distort, rotate, shift) them. Because of its open specification, anybody with the skill can start
	writing his or her own implementation of a PostScript interpreter and use it to display PostScript files on
	screen or on paper. Most graphical output devices are based on the concept of <quote>raster images</quote> or
	<quote>pixels</quote> (one notable exception is pen plotters). Of course, you can look at a PostScript file in
	its textual form and you will be reading its PostScript code, the language instructions that need to be
	interpreted by a rasterizer. Rasterizers produce pixel images, which may be displayed on screen by a viewer
	program or on paper by a printer.
	</para>
	</formalpara>
	</sect2>

	<sect2 id="post-and-ghost">
	<title>PostScript and Ghostscript</title>

	<para>
	<indexterm><primary>PostScript</primary></indexterm>
	<indexterm><primary>GhostScript</primary><seealso>PostScript</seealso></indexterm>
	<indexterm><primary>PostScript</primary><secondary>RIP</secondary></indexterm>
<indexterm><primary>PostScript interpreter</primary></indexterm>
<indexterm><primary>raster image processor</primary><see>RIP</see></indexterm>
	So UNIX is lacking a common ground for printing on paper and displaying on screen. Despite this unfavorable
	legacy for UNIX, basic printing is fairly easy if you have PostScript printers at your disposal. The reason is
	that these devices have a built-in PostScript language <quote>interpreter,</quote> also called a raster image
	processor (RIP), (which makes them more expensive than other types of printers; throw PostScript toward them,
	and they will spit out your printed pages. The RIP does all the hard work of converting the PostScript drawing
	commands into a bitmap picture as you see it on paper, in a resolution as done by your printer. This is no
	different than PostScript printing a file from a Windows origin.
	</para>

	<note><para>
	<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>PPD-aware</primary></indexterm>
<indexterm><primary>PostScript Printer Description</primary><see>PPD</see></indexterm>
	Traditional UNIX programs and printing systems &smbmdash; while using PostScript &smbmdash; are largely not
	PPD-aware. PPDs are <quote>PostScript Printer Description</quote> files. They enable you to specify and
	control all options a printer supports: duplexing, stapling, and punching. Therefore, UNIX users for a long
	time couldn't choose many of the supported device and job options, unlike Windows or Apple users. But now
	there is CUPS. as illustrated in <link linkend="2small">Printing to a PostScript Printer</link>.
	</para>
	</note>

	<figure id="2small">
		<title>Printing to a PostScript Printer.</title>
		<imagefile>2small</imagefile>
	</figure>

	<para>
	<indexterm><primary>PDL</primary></indexterm>
	However, there are other types of printers out there. These do not know how to print PostScript. They use
	their own PDL, often proprietary. To print to them is much more demanding. Since your UNIX applications mostly
	produce PostScript, and since these devices do not understand PostScript, you need to convert the print files
	to a format suitable for your printer on the host before you can send it away.
	</para>

	</sect2>

	<sect2>
	<title>Ghostscript: The Software RIP for Non-PostScript Printers</title>

	<para>
	<indexterm><primary>GhostScript</primary></indexterm>
	Here is where Ghostscript kicks in. Ghostscript is the traditional (and quite powerful) PostScript interpreter
	used on UNIX platforms. It is a RIP in software, capable of doing a <emphasis>lot</emphasis> of file format
	conversions for a very broad spectrum of hardware devices as well as software file formats.  Ghostscript
	technology and drivers are what enable PostScript printing to non-PostScript hardware. This is shown in
	<link linkend="3small">Ghostscript as a RIP for Non-PostScript Printers</link>.
	</para>

	<figure id="3small">
		<title>Ghostscript as a RIP for Non-PostScript Printers.</title>
		<imagefile>3small</imagefile>
	</figure>

	<tip><para>
<indexterm><primary>PNG</primary></indexterm>
<indexterm><primary>AFPL</primary></indexterm>
<indexterm><primary>ESP</primary></indexterm>
	Use the <quote>gs -h</quote> command to check for all built-in <quote>devices</quote> on your Ghostscript
	version. If you specify a parameter of <parameter>-sDEVICE=png256</parameter> on your Ghostscript command
	line, you are asking Ghostscript to convert the input into a PNG file. Naming a <quote>device</quote> on the
	command line is the most important single parameter to tell Ghostscript exactly how it should render the
	input. New Ghostscript versions are released at fairly regular intervals, now by artofcode LLC. They are
	initially put under the <quote>AFPL</quote> license, but re-released under the GNU GPL as soon as the next
	AFPL version appears. GNU Ghostscript is probably the version installed on most Samba systems. But it has some
	deficiencies.  <indexterm><primary>Ghostscript</primary><secondary>ESP</secondary><see>ESP
	GhostScript</see></indexterm> Therefore, ESP Ghostscript was developed as an enhancement over GNU Ghostscript,
	with lots of bug-fixes, additional devices, and improvements. It is jointly maintained by developers from
	CUPS, Gimp-Print, MandrakeSoft, SuSE, Red Hat, and Debian. It includes the <quote>cups</quote> device
	(essential to print to non-PS printers from CUPS).
	</para></tip>

	</sect2>

	<sect2>
	<title>PostScript Printer Description (PPD) Specification</title>

	<para>
	<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>PDL</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
	While PostScript in essence is a PDL to represent the page layout in a device-independent way, real-world
	print jobs are always ending up being output on hardware with device-specific features. To take care of all
	the differences in hardware and to allow for innovations, Adobe has specified a syntax and file format for
	PostScript Printer Description (PPD) files. Every PostScript printer ships with one of these files.
	</para>

	<para>
	PPDs contain all the information about general and special features of the
	given printer model: Which different resolutions can it handle? Does
	it have a duplexing unit? How many paper trays are there? What media
	types and sizes does it take? For each item, it also names the special
	command string to be sent to the printer (mostly inside the PostScript
	file) in order to enable it.
	</para>

	<para>
	Information from these PPDs is meant to be taken into account by the
	printer drivers. Therefore, installed as part of the Windows
	PostScript driver for a given printer is the printer's PPD. Where it
	makes sense, the PPD features are presented in the drivers' UI dialogs
	to display to the user a choice of print options. In the end, the
	user selections are somehow written (in the form of special
	PostScript, PJL, JCL, or vendor-dependent commands) into the PostScript
	file created by the driver.
	</para>

	<warning><para>
	<indexterm><primary>PDF</primary></indexterm>
<indexterm><primary>PDF distilling</primary></indexterm>
	A PostScript file that was created to contain device-specific commands
	for achieving a certain print job output (e.g., duplexed, stapled, and
	punched) on a specific target machine may not print as expected, or
	may not be printable at all on other models; it also may not be fit
	for further processing by software (e.g., by a PDF distilling program).
	</para></warning>
	</sect2>

	<sect2>
	<title>Using Windows-Formatted Vendor PPDs</title>

	<para>
<indexterm><primary>CUPS</primary></indexterm>
<indexterm><primary>PPDs</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
	CUPS can handle all spec-compliant PPDs as supplied by the manufacturers for their PostScript models. Even if
	a vendor does not mention our favorite OS in his or her manuals and brochures, you can safely trust this:
	<emphasis>If you get the Windows NT version of the PPD, you can use it unchanged in CUPS</emphasis> and thus
	access the full power of your printer just like a Windows NT user could!
	</para>

	<tip><para>
	To check the spec compliance of any PPD online, go to <ulink noescape="1"
	url="http://www.cups.org/testppd.php">http://www.cups.org/testppd.php</ulink> and upload your PPD. You will
	see the results displayed immediately. CUPS in all versions after 1.1.19 has a much stricter internal PPD
	parsing and checking code enabled; in case of printing trouble, this online resource should be one of your
	first pit stops.
	</para></tip>

	<warning><para>
	<indexterm><primary>foomatic</primary></indexterm>
	<indexterm><primary>cupsomatic</primary></indexterm>
	For real PostScript printers, <emphasis>do not</emphasis> use the <emphasis>Foomatic</emphasis> or
	<emphasis>cupsomatic</emphasis> PPDs from Linuxprinting.org. With these devices, the original vendor-provided
	PPDs are always the first choice.
	</para></warning>

	<tip><para>
<indexterm><primary>W32X86/2</primary></indexterm>
	If you are looking for an original vendor-provided PPD of a specific device, and you know that an NT4 box (or
	any other Windows box) on your LAN has the PostScript driver installed, just use <command>smbclient
	//NT4-box/print\$ -U username</command> to access the Windows directory where all printer driver files are
	stored. First look in the <filename>W32X86/2</filename> subdirectory for the PPD you are seeking.
	</para></tip>
	</sect2>

	<sect2>
	<title>CUPS Also Uses PPDs for Non-PostScript Printers</title>

	<para>
<indexterm><primary>non-PostScript</primary></indexterm>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>CUPS filtering</primary></indexterm>
	CUPS also uses specially crafted PPDs to handle non-PostScript printers. These PPDs are usually not available
	from the vendors (and no, you can't just take the PPD of a PostScript printer with the same model name and
	hope it works for the non-PostScript version too). To understand how these PPDs work for non-PS printers, we
	first need to dive deeply into the CUPS filtering and file format conversion architecture. Stay tuned.
	</para>

	</sect2>

</sect1>

<sect1>
<title>The CUPS Filtering Architecture</title>

<para>
<indexterm><primary>CUPS filtering</primary></indexterm>
<indexterm><primary>Ghostscript</primary></indexterm>
<indexterm><primary>MIME type</primary></indexterm>
<indexterm><primary>MIME recognition</primary></indexterm>
<indexterm><primary>MIME conversion rules</primary></indexterm>
The core of the CUPS filtering system is based on Ghostscript. In addition to Ghostscript, CUPS uses some
other filters of its own. You (or your OS vendor) may have plugged in even more filters. CUPS handles all data
file formats under the label of various MIME types. Every incoming print file is subjected to an initial
autotyping. The autotyping determines its given MIME type. A given MIME type implies zero or more possible
filtering chains relevant to the selected target printer. This section discusses how MIME types recognition
and conversion rules interact. They are used by CUPS to automatically set up a working filtering chain for any
given input data format.
</para>

<para>
If CUPS rasterizes a PostScript file natively to a bitmap, this is done in two stages:
</para>

<itemizedlist>
	<listitem><para>
<indexterm><primary>generic raster format</primary></indexterm>
<indexterm><primary>CUPS raster</primary></indexterm>
	The first stage uses a Ghostscript device named <quote>cups</quote>
	(this is since version 1.1.15) and produces a generic raster format
	called <quote>CUPS raster</quote>.
	</para></listitem>

	<listitem><para>
<indexterm><primary>raster driver</primary></indexterm>
	The second stage uses a <quote>raster driver</quote> that converts
	the generic CUPS raster to a device-specific raster.
	</para></listitem>
</itemizedlist>

<para>
<indexterm><primary>Ghostscript</primary></indexterm>
<indexterm><primary>GNU Ghostscript</primary></indexterm>
<indexterm><primary>ESP Ghostscript</primary></indexterm>
Make sure your Ghostscript version has the <quote>cups</quote> device compiled in (check with <command>gs -h |
grep cups</command>). Otherwise you may encounter the dreaded <computeroutput>Unable to convert file
0</computeroutput> in your CUPS error_log file. To have <quote>cups</quote> as a device in your Ghostscript,
you either need to patch GNU Ghostscript and recompile or use
<indexterm><primary>ESP</primary><secondary>Ghostscript</secondary></indexterm><ulink
url="http://www.cups.org/ghostscript.php">ESP Ghostscript</ulink>. The superior alternative is ESP
Ghostscript. It supports not just CUPS, but 300 other devices (while GNU Ghostscript supports only about 180).
Because of this broad output device support, ESP Ghostscript is the first choice for non-CUPS spoolers, too.
It is now recommended by Linuxprinting.org for all spoolers.
</para>

<para>
<indexterm><primary>cupsomatic</primary></indexterm>
<indexterm><primary>foomatic</primary></indexterm>
<indexterm><primary>foomatic-rip</primary></indexterm>
<indexterm><primary>ESP Ghostscript</primary></indexterm>
CUPS printers may be set up to use external rendering paths. One of the most common is provided by the
Foomatic/cupsomatic concept from <ulink url="http://www.linuxprinting.org/">Linuxprinting.org</ulink>. This
uses the classical Ghostscript approach, doing everything in one step.  It does not use the
<quote>cups</quote> device, but one of the many others. However, even for Foomatic/cupsomatic usage, best
results and <indexterm><primary>ESP</primary><secondary>Ghostscript</secondary></indexterm> broadest printer
model support is provided by ESP Ghostscript (more about Foomatic/cupsomatic, particularly the new version
called now <emphasis>foomatic-rip</emphasis>, follows).
</para>

	<sect2>
	<title>MIME Types and CUPS Filters</title>


	<para>
	<indexterm><primary>MIME</primary><secondary>filters</secondary></indexterm>
	<indexterm><primary>MIME</primary></indexterm>
<indexterm><primary>mime.types</primary></indexterm>
<indexterm><primary>application/pdf</primary></indexterm>
<indexterm><primary>autotyping</primary></indexterm>
	CUPS reads the file <filename>/etc/cups/mime.types</filename> (and all other files carrying a
	<filename>*.types</filename> suffix in the same directory) upon startup. These files contain the MIME type
	recognition rules that are applied when CUPS runs its autotyping routines. The rule syntax is explained in the
	man page for <filename>mime.types</filename> and in the comments section of the
	<filename>mime.types</filename> file itself. A simple rule reads like this:
	<indexterm><primary>application/pdf</primary></indexterm>
<programlisting>
application/pdf         pdf string(0,%PDF)
</programlisting>
<indexterm><primary>%PDF</primary></indexterm>
<indexterm><primary>.pdf</primary></indexterm>
	This means if a filename has a <filename>.pdf</filename> suffix or if the magic string
	<emphasis>%PDF</emphasis> is right at the beginning of the file itself (offset 0 from the start), then it is a
	PDF file (<parameter>application/pdf</parameter>).  Another rule is this:
<programlisting>
application/postscript  ai eps ps string(0,%!) string(0,&lt;04&gt;%!)
</programlisting>
<indexterm><primary>suffixes</primary></indexterm>
<indexterm><primary>.ai</primary></indexterm>
<indexterm><primary>.eps</primary></indexterm>
<indexterm><primary>.ps</primary></indexterm>
<indexterm><primary>generic PostScript</primary></indexterm>
<indexterm><primary>application/postscript</primary></indexterm>
	If the filename has one of the suffixes <filename>.ai</filename>, <filename>.eps</filename>,
	<filename>.ps</filename>, or if the file itself starts with one of the strings <emphasis>%!</emphasis> or
	<emphasis><![CDATA[<04>%!]]></emphasis>, it is a generic PostScript file
	(<parameter>application/postscript</parameter>).
	</para>

	<warning><para>
<indexterm><primary>/etc/cups/</primary></indexterm>
	Don't confuse the other mime.types files your system might be using
	with the one in the <filename>/etc/cups/</filename> directory.
	</para></warning>

	<note><para>
<indexterm><primary>application/postscript</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>filter</primary></indexterm>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>transformation</primary></indexterm>
	There is an important difference between two similar MIME types in CUPS: one is
	<parameter>application/postscript</parameter>, the other is
	<parameter>application/vnd.cups-postscript</parameter>. While <parameter>application/postscript</parameter> is
	meant to be device-independent, job options for the file are still outside the PS file content, embedded in
	command-line or environment variables by CUPS, <parameter>application/vnd.cups-postscript</parameter> may have
	the job options inserted into the PostScript data itself (where applicable). The transformation of the generic
	PostScript (<parameter>application/postscript</parameter>) to the device-specific version
	(<parameter>application/vnd.cups-postscript</parameter>) is the responsibility of the CUPS
	<parameter>pstops</parameter> filter. pstops uses information contained in the PPD to do the transformation.
	</para></note>

	<para>
<indexterm><primary>ASCII</primary></indexterm>
<indexterm><primary>HP-GL</primary></indexterm>
<indexterm><primary>PDF</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>DVI</primary></indexterm>
<indexterm><primary>GIF</primary></indexterm>
<indexterm><primary>PNG</primary></indexterm>
<indexterm><primary>TIFF</primary></indexterm>
<indexterm><primary>JPEG</primary></indexterm>
<indexterm><primary>Photo-CD</primary></indexterm>
<indexterm><primary>SUN-Raster</primary></indexterm>
<indexterm><primary>PNM</primary></indexterm>
<indexterm><primary>PBM</primary></indexterm>
<indexterm><primary>SGI-RGB</primary></indexterm>
<indexterm><primary>MIME</primary></indexterm>
<indexterm><primary>filters</primary></indexterm>
	CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI, and
	many image formats (GIF, PNG, TIFF, JPEG, Photo-CD, SUN-Raster,
	PNM, PBM, SGI-RGB, and more) and their associated MIME types
	with its filters.
	</para>

	</sect2>

	<sect2>
	<title>MIME Type Conversion Rules</title>


	<para>
	<indexterm><primary>MIME</primary></indexterm>
	<indexterm><primary>application/pdf</primary></indexterm>
<indexterm><primary>/etc/cups/mime.convs</primary></indexterm>
<indexterm><primary>application/pdf</primary></indexterm>
<indexterm><primary>application/postscript</primary></indexterm>
	CUPS reads the file <filename>/etc/cups/mime.convs</filename>
	(and all other files named with a <filename>*.convs</filename>
	suffix in the same directory) upon startup. These files contain
	lines naming an input MIME type, an output MIME type, a format
	conversion filter that can produce the output from the input type,
	and virtual costs associated with this conversion. One example line
	reads like this:
<programlisting>
application/pdf         application/postscript   33   pdftops
</programlisting>
<indexterm><primary>pdftops</primary></indexterm>
	This means that the <parameter>pdftops</parameter> filter will take
	<parameter>application/pdf</parameter> as input and produce
	<parameter>application/postscript</parameter> as output; the virtual
	cost of this operation is 33 CUPS-$. The next filter is more
	expensive, costing 66 CUPS-$:
	<indexterm><primary>pdf</primary></indexterm>
<programlisting>
application/vnd.hp-HPGL application/postscript   66   hpgltops
</programlisting>
<indexterm><primary>hpgltops</primary></indexterm>
	This is the <parameter>hpgltops</parameter>, which processes HP-GL
	plotter files to PostScript.
	<indexterm><primary>application/octet-stream</primary></indexterm>
<programlisting>
application/octet-stream
</programlisting>
	Here are two more examples: 
	<indexterm><primary>text/plain</primary></indexterm>
<indexterm><primary>application/x-shell</primary></indexterm>
<indexterm><primary>text/plain</primary></indexterm>
<indexterm><primary>texttops</primary></indexterm>
<programlisting>
application/x-shell     application/postscript   33    texttops
text/plain              application/postscript   33    texttops
</programlisting>
<indexterm><primary>application/x-shell</primary></indexterm>
	The last two examples name the <parameter>texttops</parameter> filter to work on
	<parameter>text/plain</parameter> as well as on <parameter>application/x-shell</parameter>. (Hint: This
	differentiation is needed for the syntax highlighting feature of <parameter>texttops</parameter>).
	</para>
	</sect2>

	<sect2>
	<title>Filtering  Overview</title>

	<para>
	<indexterm><primary>MIME</primary></indexterm>
	There are many more combinations named in <filename>mime.convs</filename>. However, you are not limited to use
	the ones predefined there. You can plug in any filter you like to the CUPS framework. It must meet, or must be
	made to meet, some minimal requirements. If you find (or write) a cool conversion filter of some kind, make
	sure it complies with what CUPS needs and put in the right lines in <filename>mime.types</filename> and
	<filename>mime.convs</filename>; then it will work seamlessly inside CUPS.
	</para>

	<sect3>
	<title>Filter Requirements</title>

	<para>
	The <quote>CUPS requirements</quote> for filters are simple. Take filenames or <filename>stdin</filename> as
	input and write to <filename>stdout</filename>. They should take these arguments:
	</para>

	<variablelist>
		<varlistentry><term>printer</term>
			<listitem><para>
			The name of the printer queue (normally this is the name of the filter being run).
			</para></listitem>
		</varlistentry>

		<varlistentry><term>job</term>
			<listitem><para>
			The numeric job ID for the job being printed.
			</para></listitem>
		</varlistentry>

		<varlistentry><term>user</term>
			<listitem><para>
			The string from the originating-user-name attribute.
			</para></listitem>
		</varlistentry>

		<varlistentry><term>title</term>
			<listitem><para>
			The string from the job-name attribute.
			</para></listitem>
		</varlistentry>

		<varlistentry><term>copies</term>
			<listitem><para>
			The numeric value from the number-copies attribute.
			</para></listitem>
		</varlistentry>

		<varlistentry><term>options</term>
			<listitem><para>
			The job options.
			</para></listitem>
		</varlistentry>

		<varlistentry><term>filename</term>
			<listitem><para>
			(optionally) The print request file (if missing, filters expected data
			fed through <filename>stdin</filename>). In most cases, it is easy to
			write a simple wrapper script around existing filters to make them work with CUPS.
			</para></listitem>
		</varlistentry>
	</variablelist>

	</sect3>

	</sect2>

	<sect2>
	<title>Prefilters</title>

	<para>
	<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>non-PostScript printers</primary></indexterm>
<indexterm><primary>raster</primary></indexterm>
	As previously stated, PostScript is the central file format to any UNIX-based
	printing system. From PostScript, CUPS generates raster data to feed
	non-PostScript printers.
	</para>

	<para>
<indexterm><primary>prefilters</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>ASCII text</primary></indexterm>
<indexterm><primary>PDF</primary></indexterm>
<indexterm><primary>DVI</primary></indexterm>
<indexterm><primary>HP-GL.</primary></indexterm>
<indexterm><primary>MIME type</primary></indexterm>
<indexterm><primary>application/postscript</primary></indexterm>
<indexterm><primary>pstops</primary></indexterm>
<indexterm><primary>application/vnd.cups-postscript</primary></indexterm>
	But what happens if you send one of the supported non-PS formats to print? Then CUPS runs
	<quote>prefilters</quote> on these input formats to generate PostScript first. There are prefilters to create
	PostScript from ASCII text, PDF, DVI, or HP-GL. The outcome of these filters is always of MIME type
	<parameter>application/postscript</parameter> (meaning that any device-specific print options are not yet
	embedded into the PostScript by CUPS and that the next filter to be called is pstops). Another prefilter is
	running on all supported image formats, the <parameter>imagetops</parameter> filter. Its outcome is always of
	MIME type <parameter>application/vnd.cups-postscript</parameter> (not application/postscript), meaning it has
	the print options already embedded into the file. This is shown in <link linkend="4small">Prefiltering in
	CUPS to Form PostScript</link>.
	</para>

	<figure id="4small">
		<title>Prefiltering in CUPS to Form PostScript.</title>
		<imagefile scale="25">4small</imagefile>
	</figure>

	</sect2>

	<sect2>
	<title>pstops</title>

	<para>
<indexterm><primary>pstops</primary></indexterm>
<indexterm><primary>application/postscript</primary></indexterm>
<indexterm><primary>application/vnd.cups-postscript</primary></indexterm>
<indexterm><primary>output duplexing</primary></indexterm>
<indexterm><primary>stapling</primary></indexterm>
<indexterm><primary>punching</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
	<emphasis>pstops</emphasis> is a filter that is used to convert <parameter>application/postscript</parameter> to
	<parameter>application/vnd.cups-postscript</parameter>. As stated earlier, this filter inserts all
	device-specific print options (commands to the printer to ask for the duplexing of output, or stapling and
	punching it, and so on) into the PostScript file. An example is illustrated in <link
	linkend="5small">Adding Device-Specific Print Options</link>.
	</para>

	<figure id="5small">
		<title>Adding Device-Specific Print Options.</title>
		<imagefile scale="25">5small</imagefile>
	</figure>

	<para>
	This is not all. Other tasks performed by it are:
	</para>

	<itemizedlist>
		<listitem><para>
		Selecting the range of pages to be printed (e.g., you can choose to
		print only pages <quote>3, 6, 8-11, 16, and 19-21</quote>, or only odd-numbered
		pages).
		</para></listitem>

		<listitem><para>
		Putting two or more logical pages on one sheet of paper (the
		so-called <quote>number-up</quote> function).
		</para></listitem>

		<listitem><para>Counting the pages of the job to insert the accounting
		information into the <filename>/var/log/cups/page_log</filename>.
		</para></listitem>
	</itemizedlist>
	</sect2>

	<sect2>
	<title>pstoraster</title>

	<para>
<indexterm><primary>pstoraster</primary></indexterm>
<indexterm><primary>rasterization</primary></indexterm>
<indexterm><primary>raster drivers</primary></indexterm>
	<parameter>pstoraster</parameter> is at the core of the CUPS filtering system. It is responsible for the first
	stage of the rasterization process. Its input is of MIME type application/vnd.cups-postscript; its output is
	application/vnd.cups-raster. This output format is not yet meant to be printable. Its aim is to serve as a
	general-purpose input format for more specialized <emphasis>raster drivers</emphasis> that are able to
	generate device-specific printer data. This is shown in <link linkend="cups-raster">the PostScript to
	Intermediate Raster Format diagram</link>.
	</para>

	<figure id="cups-raster">
		<title>PostScript to Intermediate Raster Format.</title>
		<imagefile scale="25">6small</imagefile>
	</figure>

	<para>
<indexterm><primary>CUPS raster</primary></indexterm>
<indexterm><primary>generic raster</primary></indexterm>
<indexterm><primary>IANA</primary></indexterm>
<indexterm><primary>raster drivers</primary></indexterm>
	CUPS raster is a generic raster format with powerful features. It is able to include per-page information,
	color profiles, and more, to be used by the downstream raster drivers. Its MIME type is registered with IANA
	and its specification is, of course, completely open. It is designed to make it quite easy and inexpensive for
	manufacturers to develop Linux and UNIX raster drivers for their printer models should they choose to do so.
	CUPS always takes care of the first stage of rasterization so these vendors do not need to care about
	Ghostscript complications (in fact, there are currently more than one vendor financing the development of CUPS
	raster drivers). This is illustrated in <link linkend="cups-raster2">the CUPS-Raster Production Using
	Ghostscript illustration</link>.
	</para>

	<figure id="cups-raster2">
		<title>CUPS-Raster Production Using Ghostscript.</title>
		<imagefile>7small</imagefile>
	</figure>

	<para>
<indexterm><primary>pstoraster</primary></indexterm>
<indexterm><primary>GNU Ghostscript</primary></indexterm>
<indexterm><primary>AFPL Ghostscript</primary></indexterm>
<indexterm><primary>standalone filter</primary></indexterm>
	CUPS versions before version 1.1.15 shipped a binary (or source code) standalone filter, named
	<parameter>pstoraster</parameter>. <parameter>pstoraster</parameter>, which was derived from GNU Ghostscript
	5.50 and could be installed instead of and in addition to any GNU or AFPL Ghostscript package without
	conflicting.
	</para>

	<para>
	Since version 1.1.15, this feature has changed. The functions for this filter have been integrated back
	into Ghostscript (now based on GNU Ghostscript version 7.05). The <parameter>pstoraster</parameter> filter is
	now a simple shell script calling <command>gs</command> with the <command>-sDEVICE=cups</command> parameter.
	If your Ghostscript fails when this command is executed: <command>gs -h |grep cups</command>, you might not 
	be able to print, update your Ghostscript.
	</para>
	</sect2>

	<sect2>
	<title>imagetops and imagetoraster</title>

	<para>
<indexterm><primary>prefilter</primary></indexterm>
<indexterm><primary>imagetoraster</primary></indexterm>
	In the section about prefilters, we mentioned the prefilter
	that generates PostScript from image formats. The <parameter>imagetoraster</parameter>
	filter is used to convert directly from image to raster, without the
	intermediate PostScript stage. It is used more often than the previously
	mentioned prefilters. We summarize in a flowchart the image file
	filtering in <link linkend="small8">the Image Format to CUPS-Raster Format Conversion illustration</link>.
	</para>

	<figure id="small8">
		<title>Image Format to CUPS-Raster Format Conversion.</title>
		<imagefile>8small</imagefile>
	</figure>

	</sect2>

	<sect2>
	<title>rasterto [printers specific]</title>

	<para>
<indexterm><primary>rastertoalps</primary></indexterm>
<indexterm><primary>rastertobj</primary></indexterm>
<indexterm><primary>rastertoepson</primary></indexterm>
<indexterm><primary>rastertoescp</primary></indexterm>
<indexterm><primary>rastertopcl</primary></indexterm>
<indexterm><primary>rastertoturboprint</primary></indexterm>
<indexterm><primary>rastertoescp</primary></indexterm>
<indexterm><primary>rastertohp</primary></indexterm>
<indexterm><primary>rastertoprinter</primary></indexterm>
<indexterm><primary>rastertoprinter</primary></indexterm>
<indexterm><primary>Gimp-Print</primary></indexterm>
	CUPS ships with quite a variety of raster drivers for processing CUPS raster. On my system, I find in
	/usr/lib/cups/filter/ the following: <parameter>rastertoalps</parameter>, <parameter>rastertobj</parameter>,
	<parameter>rastertoepson</parameter>, <parameter>rastertoescp</parameter>, <parameter>rastertopcl</parameter>,
	<parameter>rastertoturboprint</parameter>, <parameter>rastertoapdk</parameter>,
	<parameter>rastertodymo</parameter>, <parameter>rastertoescp</parameter>, <parameter>rastertohp</parameter>,
	and <parameter>rastertoprinter</parameter>. Don't worry if you have fewer drivers than this; some of these are
	installed by commercial add-ons to CUPS (like <parameter>rastertoturboprint</parameter>), and others (like
	<parameter>rastertoprinter</parameter>) by third-party driver development projects (such as Gimp-Print)
	wanting to cooperate as closely as possible with CUPS. See <link linkend="small9">the Raster to
	Printer-Specific Formats illustration</link>.
	</para>

		<figure id="small9">
			<title>Raster to Printer-Specific Formats.</title>
			<imagefile>9small</imagefile>
		</figure>
	</sect2>

	<sect2>
	<title>CUPS Backends</title>

	<para>
<indexterm><primary>CUPS filtering chain</primary></indexterm>
<indexterm><primary>print queue</primary></indexterm>
	The last part of any CUPS filtering chain is a backend. Backends
	are special programs that send the print-ready file to the final
	device. There is a separate backend program for any transfer
	protocol for sending print jobs over the network, and one for every local
	interface. Every CUPS print queue needs to have a CUPS <quote>device-URI</quote>
	associated with it. The device URI is the way to encode the backend
	used to send the job to its destination. Network device-URIs use
	two slashes in their syntax, local device URIs only one, as you can
	see from the following list. Keep in mind that local interface names
	may vary greatly from my examples, if your OS is not Linux:
	</para>

	<variablelist>
		<varlistentry><term>usb</term>
		<listitem><para>
		This backend sends print files to USB-connected printers. An
		example for the CUPS device-URI to use is
		<filename>usb:/dev/usb/lp0</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>serial</term>
		<listitem><para>
		This backend sends print files to serially connected printers.
		An example for the CUPS device-URI to use is
		<filename>serial:/dev/ttyS0?baud=11500</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>parallel</term>
		<listitem><para>
		This backend sends print files to printers connected to the
		parallel port. An example for the CUPS device-URI to use is
		<filename>parallel:/dev/lp0</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>SCSI</term>
		<listitem><para>
		This backend sends print files to printers attached to the
		SCSI interface. An example for the CUPS device-URI to use is
		<filename>scsi:/dev/sr1</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>lpd</term>
		<listitem><para>
		This backend sends print files to LPR/LPD-connected network
		printers. An example for the CUPS device-URI to use is
		<filename>lpd://remote_host_name/remote_queue_name</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>AppSocket/HP JetDirect</term>
		<listitem><para>
		This backend sends print files to AppSocket (a.k.a., HP
		JetDirect) connected network printers. An example for the CUPS
		device-URI to use is
		<filename>socket://10.11.12.13:9100</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>ipp</term>
		<listitem><para>
		This backend sends print files to IPP-connected network
		printers (or to other CUPS servers). Examples for CUPS device-URIs
		to use are
		<filename>ipp:://192.193.194.195/ipp</filename>
		(for many HP printers) and
		<filename>ipp://remote_cups_server/printers/remote_printer_name</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>http</term>
		<listitem><para>
		This backend sends print files to HTTP-connected printers.
		(The http:// CUPS backend is only a symlink to the ipp:// backend.)
		Examples for the CUPS device-URIs to use are
		<filename>http:://192.193.194.195:631/ipp</filename>
		(for many HP printers) and
		<filename>http://remote_cups_server:631/printers/remote_printer_name</filename>.
		</para></listitem></varlistentry>

		<varlistentry><term>smb</term>
		<listitem><para>
		This backend sends print files to printers shared by a Windows
		host. Examples of CUPS device-URIs that may be used includes:
		</para>

		<para>
		<simplelist>
		<member><filename>smb://workgroup/server/printersharename</filename></member>
		<member><filename>smb://server/printersharename</filename></member>
		<member><filename>smb://username:password@workgroup/server/printersharename</filename></member>
		<member><filename>smb://username:password@server/printersharename</filename></member>
		</simplelist>
		</para>

		<para>
		The smb:// backend is a symlink to the Samba utility
		<parameter>smbspool</parameter> (does not ship with CUPS). If the
		symlink is not present in your CUPS backend directory, have your
		root user create it: <command>ln -s `which smbspool'
		/usr/lib/cups/backend/smb</command>.
		</para></listitem></varlistentry>
	</variablelist>

	<para>
	It is easy to write your own backends as shell or Perl scripts if you
	need any modification or extension to the CUPS print system. One
	reason could be that you want to create <quote>special</quote> printers that send
	the print jobs as email (through a <quote>mailto:/</quote> backend), convert them to
	PDF (through a <quote>pdfgen:/</quote> backend) or dump them to <quote>/dev/null</quote>. (In
	fact, I have the systemwide default printer set up to be connected to
	a devnull:/ backend: there are just too many people sending jobs
	without specifying a printer, and scripts and programs that do not name
	a printer. The systemwide default deletes the job and sends a polite
	email back to the $USER asking him or her to always specify the correct
	printer name.)
	</para>

	<para>
<indexterm><primary>lpinfo</primary></indexterm>
<indexterm><primary>CUPS backends</primary></indexterm>
	Not all of the mentioned backends may be present on your system or
	usable (depending on your hardware configuration). One test for all
	available CUPS backends is provided by the <emphasis>lpinfo</emphasis>
	utility. Used with the <option>-v</option> parameter, it lists
	all available backends:
	</para>

	<para><screen>
	&prompt;<userinput>lpinfo -v</userinput>
	</screen></para>
	</sect2>

	<sect2>
	<title>The Role of <parameter>cupsomatic/foomatic</parameter></title>

	<para>
	<indexterm><primary>cupsomatic</primary></indexterm>
	<indexterm><primary>foomatic</primary></indexterm>
<indexterm><primary>PPDs</primary></indexterm>
<indexterm><primary>Foomatic Printer</primary></indexterm>
<indexterm><primary>Linuxprinting.org</primary></indexterm>
	<parameter>cupsomatic</parameter> filters may be the most widely used on CUPS
	installations. You must be clear that these were not
	developed by the CUPS people. They are a third-party add-on to
	CUPS. They utilize the traditional Ghostscript devices to render jobs
	for CUPS. When troubleshooting, you should know about the
	difference. Here the whole rendering process is done in one stage,
	inside Ghostscript, using an appropriate device for the target
	printer. <parameter>cupsomatic</parameter> uses PPDs that are generated from the Foomatic
	Printer &amp; Driver Database at Linuxprinting.org.
	</para>

	<para>
	You can recognize these PPDs from the line calling the
	<parameter>cupsomatic</parameter> filter:
<programlisting>
*cupsFilter: "application/vnd.cups-postscript  0  cupsomatic"
</programlisting>
	You may find this line among the first 40 or so lines of the PPD
	file. If you have such a PPD installed, the printer shows up in the
	CUPS Web interface with a <parameter>foomatic</parameter> namepart for
	the driver description. <parameter>cupsomatic</parameter> is a Perl script that runs
	Ghostscript with all the complicated command-line options
	autoconstructed from the selected PPD and command line options give to
	the print job.
	</para>

	<para>
	<indexterm><primary>point'n'print</primary></indexterm>
<indexterm><primary>foomatic-rip</primary></indexterm>
<indexterm><primary>Adobe specifications</primary></indexterm>
<indexterm><primary>hi-res photo</primary></indexterm>
<indexterm><primary>normal color</primary></indexterm>
<indexterm><primary>grayscale</primary></indexterm>
<indexterm><primary>draft</primary></indexterm>
<indexterm><primary>media type</primary></indexterm>
<indexterm><primary>resolution</primary></indexterm>
<indexterm><primary>inktype</primary></indexterm>
<indexterm><primary>dithering algorithm</primary></indexterm>
	However, <parameter>cupsomatic</parameter> is now deprecated. Its PPDs (especially the first
	generation of them, still in heavy use out there) are not meeting the
	Adobe specifications. You might also suffer difficulties when you try
	to download them with <quote>Point'n'Print</quote> to Windows clients. A better
	and more powerful successor is now in a stable beta-version: it is called <parameter>foomatic-rip</parameter>. To use
	<parameter>foomatic-rip</parameter> as a filter with CUPS, you need the new type of PPDs, which
	have a similar but different line:
<programlisting>
*cupsFilter: "application/vnd.cups-postscript  0  foomatic-rip"
</programlisting>
	The PPD-generating engine at Linuxprinting.org has been revamped.
	The new PPDs comply with the Adobe spec. They also provide a
	new way to specify different quality levels (hi-res photo, normal
	color, grayscale, and draft) with a single click, whereas before you
	could have required five or more different selections (media type,
	resolution, inktype, and dithering algorithm). There is support for
	custom-size media built in. There is support to switch
	print options from page to page in the middle of a job. And the
	best thing is that the new <constant>foomatic-rip</constant> works seamlessly with all
	legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR, and so on), providing
	for them access to use PPDs for their printing.
	</para>
	</sect2>

	<sect2>
	<title>The Complete Picture</title>

	<para>
	If you want to see an overview of all the filters and how they
	relate to each other, the complete picture of the puzzle is at the end
	of this chapter.
	</para>
	</sect2>

	<sect2>
	<title><filename>mime.convs</filename></title>

	<para>
	CUPS autoconstructs all possible filtering chain paths for any given
	MIME type and every printer installed. But how does it decide in
	favor of or against a specific alternative?  (There may be cases
	where there is a choice of two or more possible filtering chains for
	the same target printer.) Simple. You may have noticed the figures in
	the third column of the mime.convs file. They represent virtual costs
	assigned to this filter. Every possible filtering chain will sum up to
	a total <quote>filter cost.</quote> CUPS decides for the most <quote>inexpensive</quote> route.
	</para>

	<tip><para>
<indexterm><primary>cupsd.conf</primary></indexterm>
<indexterm><primary>FilterLimit</primary></indexterm>
	Setting <parameter>FilterLimit 1000</parameter> in
	<filename>cupsd.conf</filename> will not allow more filters to
	run concurrently than will consume a total of 1000 virtual filter
	cost. This is an efficient way to limit the load of any CUPS
	server by setting an appropriate <quote>FilterLimit</quote> value. A FilterLimit of
	200 allows roughly one job at a time, while a FilterLimit of 1000 allows
	approximately five jobs maximum at a time.
	</para></tip>
	</sect2>

	<sect2>
	<title><quote>Raw</quote> Printing</title>

	<para>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>lpadmin</primary></indexterm>
<indexterm><primary>rawprinter</primary></indexterm>
	You can tell CUPS to print (nearly) any file <quote>raw</quote>. <quote>Raw</quote> means it will not be
	filtered. CUPS will send the file to the printer <quote>as is</quote> without bothering if the printer is able
	to digest it. Users need to take care themselves that they send sensible data formats only. Raw printing can
	happen on any queue if the <quote><parameter>-o raw</parameter></quote> option is specified on the command
	line. You can also set up raw-only queues by simply not associating any PPD with it. This command:
<screen>
&prompt;<userinput>lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E</userinput>
</screen>
	sets up a queue named <quote>rawprinter</quote>, connected via the <quote>socket</quote> protocol (a.k.a.
	<quote>HP JetDirect</quote>) to the device at IP address 11.12.1.3.14, using port 9100. (If you had added a
	PPD with <command>-P /path/to/PPD</command> to this command line, you would have installed a
	<quote>normal</quote> print queue.)
	</para>

	<para>
	CUPS will automatically treat each job sent to a queue as a <quote>raw</quote> one
	if it can't find a PPD associated with the queue. However, CUPS will
	only send known MIME types (as defined in its own mime.types file) and
	refuse others.
	</para>
	</sect2>

	<sect2>
	<title>application/octet-stream Printing</title>

	<para>
<indexterm><primary>/etc/cups/mime.types</primary></indexterm>
<indexterm><primary>application/octet-stream</primary></indexterm>
	Any MIME type with no rule in the <filename>/etc/cups/mime.types</filename> file is regarded as unknown
	or <parameter>application/octet-stream</parameter> and will not be
	sent. Because CUPS refuses to print unknown MIME types by default,
	you will probably have experienced that print jobs originating
	from Windows clients were not printed. You may have found an error
	message in your CUPS logs like:
	</para>

	<para><computeroutput>
	 Unable to convert file 0 to printable format for job
	</computeroutput></para>

	<para>
	To enable the printing of <parameter>application/octet-stream</parameter> files, edit
	these two files:
	</para>

	<itemizedlist>
		<listitem><para><filename>/etc/cups/mime.convs</filename></para></listitem>

		<listitem><para><filename>/etc/cups/mime.types</filename></para></listitem>
	</itemizedlist>

	<para>
<indexterm><primary>raw mode</primary></indexterm>
	Both contain entries (at the end of the respective files) that must be uncommented to allow raw mode
	operation for <parameter>application/octet-stream</parameter>. In <filename>/etc/cups/mime.types</filename>
	make sure this line is present:
	<indexterm><primary>application/octet-stream</primary></indexterm>
<programlisting>
application/octet-stream
</programlisting>
	This line (with no specific autotyping rule set) makes all files
	not otherwise auto-typed a member of <parameter>application/octet-stream</parameter>. In
	<filename>/etc/cups/mime.convs</filename>, have this
	line: 
<programlisting>
application/octet-stream   application/vnd.cups-raw   0   -
</programlisting>
	<indexterm><primary>MIME</primary></indexterm>
	This line tells CUPS to use the <emphasis>Null Filter</emphasis>
	(denoted as <quote>-</quote>, doing nothing at all) on
	<parameter>application/octet-stream</parameter>, and tag the result as
	<parameter>application/vnd.cups-raw</parameter>. This last one is
	always a green light to the CUPS scheduler to now hand the file over
	to the backend connecting to the printer and sending it over.
	</para>

	<note><para>
	Editing the <filename>mime.convs</filename> and the <filename>mime.types</filename> file does not
	<emphasis>enforce</emphasis> <quote>raw</quote> printing, it only <emphasis>allows</emphasis> it.
	</para></note>

	<formalpara>
	<title>Background</title>

	<para>
<indexterm><primary>security-aware</primary></indexterm>
<indexterm><primary>MIME type</primary></indexterm>
<indexterm><primary>/etc/cups/mime.types</primary></indexterm>
<indexterm><primary>/etc/cups/mime.convs</primary></indexterm>
	That CUPS is a more security-aware printing system than traditional ones
	does not by default allow one to send deliberate (possibly binary)
	data to printing devices. (This could be easily abused to launch a
	Denial of Service attack on your printer(s), causing at least the loss
	of a lot of paper and ink.) <quote>Unknown</quote> data are regarded by CUPS
	as <emphasis>MIME type</emphasis> <emphasis>application/octet-stream</emphasis>. While you
	<emphasis>can</emphasis> send data <quote>raw</quote>, the MIME type for these must
	be one that is known to CUPS and allowed by it. The file
	<filename>/etc/cups/mime.types</filename> defines the <quote>rules</quote> of how CUPS
	recognizes MIME types. The file <filename>/etc/cups/mime.convs</filename> decides which file
	conversion filter(s) may be applied to which MIME types.
	</para>
	</formalpara>
	</sect2>

	<sect2>
	<title>PostScript Printer Descriptions for Non-PostScript Printers</title>

	<para>
	<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>non-PostScript</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>RIP</primary></indexterm>
<indexterm><primary>Ghostscript</primary></indexterm>
<indexterm><primary>device-specific commands</primary></indexterm>
	Originally PPDs were meant to be used for PostScript printers
	only. Here, they help to send device-specific commands and settings
	to the RIP, which processes the job file. CUPS has extended this
	scope for PPDs to cover non-PostScript printers too. This was not
	difficult, because it is a standardized file format. In a way
	it was logical too: CUPS handles PostScript and uses a PostScript
	RIP (Ghostscript) to process the job files. The only difference is that
	a PostScript printer has the RIP built-in, for other types of
	printers the Ghostscript RIP runs on the host computer.
	</para>

	<para>
	PPDs for a non-PostScript printer have a few lines that are unique to
	CUPS. The most important one looks similar to this:
	<indexterm><primary>application/vnd.cups-raster</primary></indexterm>
<programlisting>
*cupsFilter: application/vnd.cups-raster  66   rastertoprinter
</programlisting>
	It is the last piece in the CUPS filtering puzzle. This line tells the
	CUPS daemon to use as a last filter <parameter>rastertoprinter</parameter>. This filter
	should be served as input an <parameter>application/vnd.cups-raster</parameter> MIME type
	file. Therefore, CUPS should autoconstruct a filtering chain, which
	delivers as its last output the specified MIME type. This is then
	taken as input to the specified <parameter>rastertoprinter</parameter> filter. After
	the last filter has done its work (<parameter>rastertoprinter</parameter> is a Gimp-Print
	filter), the file should go to the backend, which sends it to the
	output device.
	</para>

	<para>
	CUPS by default ships only a few generic PPDs, but they are good for
	several hundred printer models. You may not be able to control
	different paper trays, or you may get larger margins than your
	specific model supports. See Table 21.1<link linkend="cups-ppds"></link> for summary information.
	</para>

	<table frame="all" id="cups-ppds">
		<title>PPDs Shipped with CUPS</title>
		<tgroup cols="2" align="left">
			<colspec align="left"/>
			<colspec align="justify" colwidth="1*"/>
			<thead><row><entry>PPD file</entry><entry>Printer type</entry></row></thead>
			<tbody>
			<row><entry>deskjet.ppd</entry><entry>older HP inkjet printers and compatible</entry></row>

			<row><entry>deskjet2.ppd</entry> <entry>newer HP inkjet printers and compatible </entry> </row>

			<row><entry>dymo.ppd</entry> <entry>label printers </entry> </row>

			<row><entry>epson9.ppd</entry> <entry>Epson 24-pin impact printers and compatible </entry> </row>

			<row><entry>epson24.ppd</entry> <entry>Epson 24-pin impact printers and compatible </entry> </row>

			<row><entry>okidata9.ppd</entry> <entry>Okidata 9-pin impact printers and compatible </entry> </row>

			<row><entry>okidat24.ppd</entry> <entry>Okidata 24-pin impact printers and compatible </entry> </row>

			<row><entry>stcolor.ppd</entry> <entry>older Epson Stylus Color printers </entry> </row>

			<row><entry>stcolor2.ppd</entry> <entry>newer Epson Stylus Color printers </entry> </row>

			<row><entry>stphoto.ppd</entry> <entry>older Epson Stylus Photo printers </entry> </row>

			<row><entry>stphoto2.ppd</entry> <entry>newer Epson Stylus Photo printers </entry> </row>

			<row><entry>laserjet.ppd</entry> <entry>all PCL printers </entry> </row>

			</tbody>
		</tgroup>
	</table>

	</sect2>

	<sect2>
	<title><emphasis>cupsomatic/foomatic-rip</emphasis> Versus <emphasis>Native CUPS</emphasis> Printing</title>

	<para>
	<indexterm><primary>cupsomatic</primary></indexterm>
	<indexterm><primary>foomatic-rip</primary></indexterm>
	Native CUPS rasterization works in two steps:
	</para>

	<itemizedlist>
		<listitem><para>
<indexterm><primary>pstoraster</primary></indexterm>
		First is the <parameter>pstoraster</parameter> step. It uses the special CUPS
		<indexterm><primary>ESP</primary><secondary>Ghostscript</secondary></indexterm>
		device from ESP Ghostscript 7.05.x as its tool.
		</para></listitem>

		<listitem><para>
		Second is the <parameter>rasterdriver</parameter> step. It uses various
		device-specific filters; there are several vendors who provide good
		quality filters for this step. Some are free software, some are
		shareware, and some are proprietary.
		</para></listitem>
	</itemizedlist>

	<para>
	Often this produces better quality (and has several more advantages) than other methods.
	This is shown in <link linkend="cupsomatic-dia"> the cupsomatic/foomatic Processing Versus Native CUPS
	illustration</link>.
	</para>

	<figure id="cupsomatic-dia">
		<title>cupsomatic/foomatic Processing Versus Native CUPS.</title>
		<imagefile>10small</imagefile>
	</figure>

	<para>
	One other method is the <parameter>cupsomatic/foomatic-rip</parameter>
	way. Note that <parameter>cupsomatic</parameter> is <emphasis>not</emphasis> made by the CUPS
	developers. It is an independent contribution to printing development,
	made by people from Linuxprinting.org.<footnote><para>See also <ulink
	noescape="1" url="http://www.cups.org/cups-help.html">http://www.cups.org/cups-help.html</ulink></para></footnote>
	<parameter>cupsomatic</parameter> is no longer developed, maintained, or supported. It now been
	replaced by <parameter>foomatic-rip</parameter>. <parameter>foomatic-rip</parameter> is a complete rewrite
	of the old <parameter>cupsomatic</parameter> idea, but very much improved and generalized to
	other (non-CUPS) spoolers. An upgrade to <parameter>foomatic-rip</parameter> is strongly
	advised, especially if you are upgrading to a recent version of CUPS,
	too.
	</para>

	<para>
	<indexterm><primary>cupsomatic</primary></indexterm>
	<indexterm><primary>foomatic</primary></indexterm>
	Like the old <parameter>cupsomatic</parameter> method, the <parameter>foomatic-rip</parameter> (new) method
	from Linuxprinting.org uses the traditional Ghostscript print file processing, doing everything in a single
	step. It therefore relies on all the other devices built into Ghostscript. The quality is as good (or bad) as
	Ghostscript rendering is in other spoolers. The advantage is that this method supports many printer models not
	supported (yet) by the more modern CUPS method.
	</para>

	<para>
	Of course, you can use both methods side by side on one system (and even for one printer, if you set up
	different queues) and find out which works best for you.
	</para>

	<para>
<indexterm><primary>cupsomatic</primary></indexterm>
<indexterm><primary>pstoraster</primary></indexterm>
<indexterm><primary>rastertosomething</primary></indexterm>
<indexterm><primary>rasterization</primary></indexterm>
<indexterm><primary>Foomatic/cupsomatic</primary></indexterm>
<indexterm><primary>rendering</primary></indexterm>
	<parameter>cupsomatic</parameter> kidnaps the print file after the
	<parameter>application/vnd.cups-postscript</parameter> stage and deviates it through the CUPS-external,
	systemwide Ghostscript installation. Therefore, the print file bypasses the <parameter>pstoraster</parameter>
	filter (and also bypasses the CUPS raster drivers <parameter>rastertosomething</parameter>). After Ghostscript
	finished its rasterization, <parameter>cupsomatic</parameter> hands the rendered file directly to the CUPS
	backend. <link linkend="cupsomatic-dia">cupsomatic/foomatic Processing Versus Native
	CUPS</link>, illustrates the difference between native CUPS rendering and the
	<parameter>Foomatic/cupsomatic</parameter> method.
	</para>
	</sect2>

	<sect2>
	<title>Examples for Filtering Chains</title>

	<para>
	Here are a few examples of commonly occurring filtering chains to
	illustrate the workings of CUPS.
	</para>

	<para>
<indexterm><primary>HP JetDirect</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>two-up</primary></indexterm>
<indexterm><primary>duplex</primary></indexterm>
	Assume you want to print a PDF file to an HP JetDirect-connected
	PostScript printer, but you want to print pages 3-5, 7, and 11-13
	only, and you want to print them <quote>two-up</quote> and <quote>duplex</quote>:
	</para>

	<itemizedlist>
	<listitem><para>Your print options (page selection as required, two-up,
	duplex) are passed to CUPS on the command line.</para></listitem>

	<listitem><para>The (complete) PDF file is sent to CUPS and autotyped as
	<parameter>application/pdf</parameter>.</para></listitem>

	<listitem><para>The file therefore must first pass the
	<parameter>pdftops</parameter> prefilter, which produces PostScript
	MIME type <parameter>application/postscript</parameter> (a preview here
	would still show all pages of the original PDF).</para></listitem>

	<listitem><para>The file then passes the <parameter>pstops</parameter>
	filter that applies the command-line options: it selects pages
	2-5, 7, and 11-13, creates the imposed layout <quote>two pages on one sheet</quote>, and
	inserts the correct <quote>duplex</quote> command (as defined in the printer's
	PPD) into the new PostScript file; the file is now of PostScript MIME
	type
	<parameter>application/vnd.cups-postscript</parameter>.</para></listitem>

	<listitem><para>The file goes to the <parameter>socket</parameter>
	backend, which transfers the job to the printers.</para></listitem>
	</itemizedlist>

	<para>
	The resulting filter chain, therefore, is as shown in <link linkend="pdftosocket">the PDF to socket chain
	illustration</link>.
	</para>

<indexterm><primary>pdftosocket</primary></indexterm>
	<figure id="pdftosocket">
		<title>PDF to Socket Chain.</title>
		<imagefile>pdftosocket</imagefile>
	</figure>

	<para>
<indexterm><primary>USB</primary></indexterm>
<indexterm><primary>Epson Stylus</primary></indexterm>
<indexterm><primary>stphoto2.ppd</primary></indexterm>
	Assume you want to print the same filter to an USB-connected Epson Stylus Photo Printer installed with the CUPS
	<filename>stphoto2.ppd</filename>. The first few filtering stages are nearly the same:
	</para>

	<itemizedlist>
		<listitem><para>
		Your print options (page selection as required, two-up,
		duplex) are passed to CUPS on the command line.
		</para></listitem>

		<listitem><para>
		The (complete) PDF file is sent to CUPS and autotyped as
		<parameter>application/pdf</parameter>.
		</para></listitem>

		<listitem><para>
<indexterm><primary>pdftops</primary></indexterm>
<indexterm><primary>PDF</primary></indexterm>
		The file must first pass the <parameter>pdftops</parameter> prefilter, which produces PostScript
		MIME type <parameter>application/postscript</parameter> (a preview here would still show all
		pages of the original PDF).
		</para></listitem>

		<listitem><para>
<indexterm><primary>pstops</primary></indexterm>
<indexterm><primary>duplex printing</primary></indexterm>
		The file then passes the <quote>pstops</quote> filter that applies
		the command-line options: it selects the pages 2-5, 7, and 11-13,
		creates the imposed layout <quote>two pages on one sheet,</quote> and inserts the
		correct <quote>duplex</quote> command (oops &smbmdash; this printer and PPD
		do not support duplex printing at all, so this option will
		be ignored) into the new PostScript file; the file is now of PostScript
		MIME type <parameter>application/vnd.cups-postscript</parameter>.
		</para></listitem>

		<listitem><para>
		The file then passes the <parameter>pstoraster</parameter> stage and becomes MIME type
		<parameter>application/cups-raster</parameter>.
		</para></listitem>

		<listitem><para>
<indexterm><primary>rastertoepson</primary></indexterm>
		Finally, the <parameter>rastertoepson</parameter> filter
		does its work (as indicated in the printer's PPD), creating the
		printer-specific raster data and embedding any user-selected
		print options into the print data stream.
		</para></listitem>

		<listitem><para>
		The file goes to the <parameter>usb</parameter> backend, which transfers the job to the printers.
		</para></listitem>
	</itemizedlist>

	<para>
	The resulting filter chain therefore is as shown in <link linkend="pdftoepsonusb">the PDF to USB Chain
	illustration</link>.
	</para>

	<figure id="pdftoepsonusb">
		<title>PDF to USB Chain.</title>
		<imagefile>pdftoepsonusb</imagefile>
	</figure>
	</sect2>

	<sect2>
	<title>Sources of CUPS Drivers/PPDs</title>

	<para>
	On the Internet you can now find many thousands of CUPS-PPD files
	(with their companion filters), in many national languages
	supporting more than 1,000 non-PostScript models.
	</para>

	<itemizedlist>
		<indexterm><primary>ESP</primary><secondary>Print Pro</secondary></indexterm>
		<indexterm><primary>PrintPro</primary><see>ESP Print Pro</see></indexterm>
		<listitem><para>
		<ulink url="http://www.easysw.com/printpro/">ESP PrintPro</ulink>
		(commercial, non-free) is packaged with more than 3,000 PPDs, ready for
		successful use <quote>out of the box</quote> on Linux, Mac OS X, IBM-AIX,
		HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital UNIX, and
		other commercial Unices (it is written by the CUPS developers
		themselves and its sales help finance the further development of
		CUPS, as they feed their creators).
		</para></listitem>

		<listitem><para>
		The <ulink url="http://gimp-print.sourceforge.net/">Gimp-Print Project</ulink>
		(GPL, free software) provides around 140 PPDs (supporting nearly 400 printers, many driven
		to photo quality output), to be used alongside the Gimp-Print CUPS filters.
		</para></listitem>

		<listitem><para>
		<ulink url="http://www.turboprint.de/english.html/">TurboPrint </ulink> (shareware, non-free) supports
		roughly the same number of printers in excellent quality.
		</para></listitem>

		<listitem><para>
		<ulink url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI </ulink>
		(LPGL, free) is a package made by IBM, now containing support for more
		than 400 printers, stemming from the inheritance of IBM OS/2 know-how
		ported over to Linux (CUPS support is in a beta stage at present).
		</para></listitem>

		<listitem><para>
		<ulink url="http://hpinkjet.sourceforge.net/">HPIJS </ulink> (BSD-style licenses, free)
		supports approximately 150 of HP's own printers and also provides
		excellent print quality now (currently available only via the Foomatic path).
		</para></listitem>

		<listitem><para>
		<ulink url="http://www.linuxprinting.org/">Foomatic/cupsomatic </ulink>
		(LPGL, free) from Linuxprinting.org provide PPDs for practically every Ghostscript
		filter known to the world (including Omni, Gimp-Print, and HPIJS).
		</para></listitem>
	</itemizedlist>

	</sect2>

	<sect2>
	<title>Printing with Interface Scripts</title>

	<para>
<indexterm><primary>PCL</primary></indexterm>
<indexterm><primary>lpadmin</primary></indexterm>
	CUPS also supports the use of <quote>interface scripts</quote> as known from
	System V AT&amp;T printing systems. These are often used for PCL
	printers, from applications that generate PCL print jobs. Interface
	scripts are specific to printer models. They have a role similar to
	PPDs for PostScript printers. Interface scripts may inject the Escape
	sequences as required into the print data stream if the user, for example, selects
	a certain paper tray, or changes paper orientation, or uses A3
	paper. Interface scripts are practically unknown in the Linux
	realm. On HP-UX platforms they are more often used. You can use any
	working interface script on CUPS too. Just install the printer with
	the <command>-i</command> option:
<screen>
&rootprompt;<userinput>lpadmin -p pclprinter -v socket://11.12.13.14:9100 \
          -i /path/to/interface-script</userinput>
</screen></para>

	<para>
	Interface scripts might be the <quote>unknown animal</quote> to many. However,
	with CUPS they provide the easiest way to plug in your own custom-written filtering
	script or program into one specific print queue (some information about the traditional
	use of interface scripts is found at
	<ulink noescape="1" url="http://playground.sun.com/printing/documentation/interface.html">
	http://playground.sun.com/printing/documentation/interface.html</ulink>).
	</para>
	</sect2>
</sect1>

<sect1>
<title>Network Printing (Purely Windows)</title>

<para>
Network printing covers a lot of ground. To understand what exactly
goes on with Samba when it is printing on behalf of its Windows
clients, let's first look at a <quote>purely Windows</quote> setup: Windows clients
with a Windows NT print server.
</para>

<sect2>
<title>From Windows Clients to an NT Print Server</title>

<para>
Windows clients printing to an NT-based print server have two
options. They may:
<indexterm><primary>GDI</primary></indexterm>
<indexterm><primary>EMF</primary></indexterm>
</para>


<itemizedlist>
	<listitem><para>Execute the driver locally and render the GDI output
			(EMF) into the printer-specific format on their own.
	</para></listitem>

	<listitem><para>Send the GDI output (EMF) to the server, where the
	driver is executed to render the printer-specific output.
	</para></listitem>
</itemizedlist>

<para>
Both print paths are shown in the flowcharts in <link linkend="small11">
Print Driver Execution on the Client</link>, and
<link linkend="small12">Print Driver Execution on the Server</link>.
</para>
</sect2>

<sect2>
<title>Driver Execution on the Client</title>

<para>
In the first case, the print server must spool the file as raw, meaning it shouldn't touch the job file and try
to convert it in any way. This is what a traditional UNIX-based print server can do too, and at a better
performance and more reliably than an NT print server. This is what most Samba administrators probably are
familiar with. One advantage of this setup is that this <quote>spooling-only</quote> print server may be used
even if no driver(s) for UNIX is available. It is sufficient to have the Windows client drivers available and
installed on the clients. This is illustrated in <link linkend="small11">the Print Driver Execution on the
Client diagram</link>.
</para>

<figure id="small11">
	<title>Print Driver Execution on the Client.</title>
	<imagefile>11small</imagefile>
</figure>

</sect2>

<sect2>
<title>Driver Execution on the Server</title>


<para>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>PCL</primary></indexterm>
<indexterm><primary>ESC/P</primary></indexterm>
<indexterm><primary>EMF</primary></indexterm>
<indexterm><primary>GDI</primary></indexterm>
The other path executes the printer driver on the server. The client transfers print files in EMF format to
the server. The server uses the PostScript, PCL, ESC/P, or other driver to convert the EMF file into the
printer-specific language. It is not possible for UNIX to do the same. Currently, there is no program or
method to convert a Windows client's GDI output on a UNIX server into something a printer could understand.
This is illustrated in <link linkend="small12">the Print Driver Execution on the Server diagram</link>.
</para>

	<figure id="small12">
		<title>Print Driver Execution on the Server.</title>
		<imagefile>12small</imagefile>
	</figure>

<para>
However, something similar is possible with CUPS, so read on.
</para>
</sect2>
</sect1>

<sect1>
<title>Network Printing (Windows Clients and UNIX/Samba Print
Servers)</title>

<para>
Since UNIX print servers <emphasis>cannot</emphasis> execute the Win32
program code on their platform, the picture is somewhat
different. However, this does not limit your options all that
much. On the contrary, you may have a way here to implement printing
features that are not possible otherwise.
</para>

<sect2>
<title>From Windows Clients to a CUPS/Samba Print Server</title>

<para>
Here is a simple recipe showing how you can take advantage of CUPS's
powerful features for the benefit of your Windows network printing
clients:
</para>

<itemizedlist>
	<listitem><para>Let the Windows clients send PostScript to the CUPS
	server.</para></listitem>

	<listitem><para>Let the CUPS server render the PostScript into device-specific raster format.</para></listitem>
</itemizedlist>

<para>
This requires the clients to use a PostScript driver (even if the
printer is a non-PostScript model. It also requires that you have a
driver on the CUPS server.
</para>

<para>
First, to enable CUPS-based printing through Samba, the following options should be set in your &smb.conf;
file <parameter>[global]</parameter> section:
</para>

<smbconfblock>
<smbconfoption name="printing">cups</smbconfoption>
<smbconfoption name="printcap">cups</smbconfoption>
</smbconfblock>

<para>
When these parameters are specified, all manually set print directives (like <smbconfoption name="print
command"/> or <smbconfoption name="lppause command"/>) in &smb.conf; (as well as in Samba itself) will be
ignored. Instead, Samba will directly interface with CUPS through its application program interface (API), as
long as Samba has been compiled with CUPS library (libcups) support. If Samba has not been compiled with CUPS
support, and if no other print commands are set up, then printing will use the <emphasis>System V</emphasis>
AT&amp;T command set, with the -oraw option automatically passing through (if you want your own defined print
commands to work with a Samba server that has CUPS support compiled in, simply use <smbconfoption
name="classicalprinting">sysv</smbconfoption>). This is illustrated in <link linkend="13small">the Printing via
CUPS/Samba Server diagram</link>.
</para>

	<figure id="13small">
		<title>Printing via CUPS/Samba Server.</title>
		<imagefile>13small</imagefile>
	</figure>
</sect2>

<sect2>
<title>Samba Receiving Job-Files and Passing Them to CUPS</title>

<para>
Samba <emphasis>must</emphasis> use its own spool directory (it is set by a line similar to <smbconfoption
name="path">/var/spool/samba</smbconfoption>, in the <smbconfsection name="[printers]"/> or <smbconfsection
name="[printername]"/> section of &smb.conf;). Samba receives the job in its own spool space and passes it
into the spool directory of CUPS (the CUPS spool directory is set by the <parameter>RequestRoot</parameter>
directive in a line that defaults to <parameter>RequestRoot /var/spool/cups</parameter>). CUPS checks the
access rights of its spool directory and resets it to healthy values with every restart. We have seen quite a
few people who used a common spooling space for Samba and CUPS, and struggled for weeks with this
<quote>problem.</quote>
</para>

<para>
A Windows user authenticates only to Samba (by whatever means is
configured). If Samba runs on the same host as CUPS, you only need to
allow <quote>localhost</quote> to print. If it runs on different machines, you
need to make sure the Samba host gets access to printing on CUPS.
</para>
</sect2>
</sect1>

<sect1>
<title>Network PostScript RIP</title>

<para>
This section discusses the use of CUPS filters on the server &smbmdash; configuration where
clients make use of a PostScript driver with CUPS-PPDs.
</para>


<para>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>PCL</primary></indexterm>
<indexterm><primary>PJL</primary></indexterm>
PPDs can control all print device options. They are usually provided by the manufacturer &smbmdash; if you own
a PostScript printer, that is. PPD files are always a component of PostScript printer drivers on MS Windows or
Apple Mac OS systems. They are ASCII files containing user-selectable print options, mapped to appropriate
PostScript, PCL, or PJL commands for the target printer. Printer driver GUI dialogs translate these options
<quote>on the fly</quote> into buttons and drop-down lists for the user to select.
</para>

<para>
CUPS can load, without any conversions, the PPD file from any Windows (NT is recommended) PostScript driver
and handle the options. There is a Web browser interface to the print options (select <ulink noescape="1"
url="http://localhost:631/printers/">http://localhost:631/printers/</ulink> and click on one
<guibutton>Configure Printer</guibutton> button to see it) or a command-line interface (see <command>man
lpoptions</command> or see if you have <command>lphelp</command> on your system). There are also some
different GUI front-ends on Linux/UNIX, which can present PPD options to users. PPD options are normally meant
to be evaluated by the PostScript RIP on the real PostScript printer.
</para>

<sect2>
<title>PPDs for Non-PS Printers on UNIX</title>


<para>
<indexterm><primary>PPD</primary></indexterm>
CUPS does not limit itself to <quote>real</quote> PostScript printers in its use of PPDs. The CUPS developers
have extended the scope of the PPD concept to also describe available device and driver options for
non-PostScript printers through CUPS-PPDs.
</para>

<para>
This is logical, because CUPS includes a fully featured PostScript interpreter (RIP). This RIP is based on
Ghostscript. It can process all received PostScript (and additionally many other file formats) from clients.
All CUPS-PPDs geared to non-PostScript printers contain an additional line, starting with the keyword
<parameter>*cupsFilter</parameter>. This line tells the CUPS print system which printer-specific filter to use
for the interpretation of the supplied PostScript. Thus CUPS lets all its printers appear as PostScript
devices to its clients, because it can act as a PostScript RIP for those printers, processing the received
PostScript code into a proper raster print format.
</para>
</sect2>

<sect2>
<title>PPDs for Non-PS Printers on Windows</title>

<para>
<indexterm><primary>PPD</primary></indexterm>
CUPS-PPDs can also be used on Windows clients, on top of a <quote>core</quote> PostScript driver (now
recommended is the CUPS PostScript Driver for Windows NT/200x/XP; you can also use the Adobe one, with
limitations). This feature enables CUPS to do a few tricks no other spooler can do:
</para>

<itemizedlist>
	<listitem><para>
	Act as a networked PostScript RIP handling print files from all client platforms in a uniform way.
	</para></listitem>

	<listitem><para>
	Act as a central accounting and billing server, since all files are passed through the pstops filter and are therefore
	logged in the CUPS <filename>page_log</filename> file.  <emphasis>Note:</emphasis> this cannot happen with
	<quote>raw</quote> print jobs, which always remain unfiltered per definition.
	</para></listitem>

	<listitem><para>
	Enable clients to consolidate on a single PostScript driver, even for many different target printers.
	</para></listitem>
</itemizedlist>

<para>
Using CUPS PPDs on Windows clients enables them to control all print job settings just as a UNIX client can do.
</para>
</sect2>
</sect1>

<sect1>
<title>Windows Terminal Servers (WTS) as CUPS Clients</title>

<para>
This setup may be of special interest to people experiencing major problems in WTS environments. WTS often
need a multitude of non-PostScript drivers installed to run their clients' variety of different printer
models. This often imposes the price of much increased instability.
</para>

<sect2>
<title>Printer Drivers Running in <quote>Kernel Mode</quote> Cause Many
Problems</title>

<para>
Windows NT printer drivers, which run in <quote>kernel mode</quote>, introduce a high risk for the stability
of the system if the driver is not really stable and well-tested. And there are a lot of bad drivers out
there! Especially notorious is the example of the PCL printer driver that had an additional sound module
running to notify users via soundcard of their finished jobs. Do I need to say that this one was also reliably
causing <quote>blue screens of death</quote> on a regular basis?
</para>

<para>
PostScript drivers are generally well-tested. They are not known to cause any problems, even though they also
run in kernel mode. This might be because until now there have been only two different PostScript drivers: the
one from Adobe and the one from Microsoft. Both are well-tested and are as stable as you can imagine on
Windows. The CUPS driver is derived from the Microsoft one.
</para>
</sect2>

<sect2>
<title>Workarounds Impose Heavy Limitations</title>

<para>
In an attempt to work around problems, site administrators have resorted to restricting the
allowed drivers installed on their WTS to one generic PCL and one PostScript driver. This, however, restricts
the number of printer options available for clients to use. Often they can't get out more than simplex
prints from one standard paper tray, while their devices could do much better if driven by a different driver!
</para>
</sect2>

<sect2>
<title>CUPS: A <quote>Magical Stone</quote>?</title>

<para>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
Using a PostScript driver, enabled with a CUPS-PPD, seems to be a very elegant way to overcome all these
shortcomings. There are, depending on the version of Windows OS you use, up to three different PostScript
drivers now available: Adobe, Microsoft, and CUPS PostScript drivers. None of them is known to cause major
stability problems on WTS (even if used with many different PPDs). The clients will be able to (again) choose
paper trays, duplex printing, and other settings. However, there is a certain price for this too: a CUPS
server acting as a PostScript RIP for its clients requires more CPU and RAM than when just acting as a
<quote>raw spooling</quote> device. Plus, this setup is not yet widely tested, although the first feedbacks
look very promising.
</para>
</sect2>

<sect2>
<title>PostScript Drivers with No Major Problems, Even in Kernel
Mode</title>

<para>
<indexterm><primary>DDK</primary></indexterm>
<indexterm><primary>W32X86</primary></indexterm>
<indexterm><primary>PostScript</primary></indexterm>
<indexterm><primary>Visual Studio</primary></indexterm>
<indexterm><primary>Microsoft driver</primary></indexterm>
<indexterm><primary>Adobe</primary></indexterm>
More recent printer drivers on W200x and XP no longer run in kernel mode (unlike Windows NT). However, both
operating systems can still use the NT drivers, running in kernel mode (you can roughly tell which is which as
the drivers in subdirectory <quote>2</quote> of <quote>W32X86</quote> are <quote>old</quote> ones). As was
said before, the Adobe as well as the Microsoft PostScript drivers are not known to cause any stability
problems. The CUPS driver is derived from the Microsoft one. There is a simple reason for this: the MS DDK
(Device Development Kit) for Windows NT (which used to be available at no cost to licensees of Visual Studio)
includes the source code of the Microsoft driver, and licensees of Visual Studio are allowed to use and modify
it for their own driver development efforts. This is what the CUPS people have done. The license does not
allow them to publish the whole of the source code.  However, they have released the <quote>diff</quote> under
the GPL, and if you are the owner of an <quote>MS DDK for Windows NT,</quote> you can check the driver
yourself.
</para>
</sect2>
</sect1>

<sect1>
<title>Configuring CUPS for Driver Download</title>

<para>
As we have said before, all previously known methods to prepare client printer drivers on the Samba server for
download and Point'n'Print convenience of Windows workstations are working with CUPS, too. These methods were
described in <link linkend="classicalprinting">Classical Printing</link>. In reality, this is a pure Samba
business and relates only to the Samba-Windows client relationship.
</para>

<sect2>
<title><emphasis>cupsaddsmb</emphasis>: The Unknown Utility</title>


<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
The <parameter>cupsaddsmb</parameter> utility (shipped with all current CUPS versions) is an alternative
method to transfer printer drivers into the Samba <smbconfsection name="[print$]"/> share. Remember, this
share is where clients expect drivers deposited and set up for download and installation. It makes the sharing
of any (or all) installed CUPS printers quite easy. <command>cupsaddsmb</command> can use the Adobe PostScript
driver as well as the newly developed CUPS PostScript driver for Windows NT/200x/XP.
<parameter>cupsaddsmb</parameter> does <emphasis>not</emphasis> work with arbitrary vendor printer drivers,
but only with the <emphasis>exact</emphasis> driver files that are named in its man page.
</para>

<para>
The CUPS printer driver is available from the CUPS download site. Its package name is
<filename>cups-samba-[version].tar.gz</filename>. It is preferred over the Adobe drivers because it has a
number of advantages:
</para>

<itemizedlist>
	<listitem><para>It supports a much more accurate page accounting.</para></listitem>

	<listitem><para>It supports banner pages and page labels on all printers.</para></listitem>

	<listitem><para>It supports the setting of a number of job IPP attributes
	(such as job priority, page label, and job billing).</para></listitem>
</itemizedlist>

<para>
However, currently only Windows NT, 2000, and XP are supported by the
CUPS drivers. You will also need to get the respective part of the Adobe driver
if you need to support Windows 95, 98, and Me clients.
</para>
</sect2>

<sect2>
<title>Prepare Your &smb.conf; for <command>cupsaddsmb</command></title>

<para>
Prior to running <command>cupsaddsmb</command>, you need the settings in
&smb.conf; as shown in <link linkend="cupsadd-ex">the &smb.conf; for cupsaddsmb Usage</link>.
</para>

<example id="cupsadd-ex">
<title>smb.conf for cupsaddsmb Usage</title>
<smbconfblock>
<smbconfsection name="[global]"/>
<smbconfoption name="load printers">yes</smbconfoption>
<smbconfoption name="printing">cups</smbconfoption>
<smbconfoption name="printcap name">cups</smbconfoption>

<smbconfsection name="[printers]"/>
<smbconfoption name="comment">All Printers</smbconfoption>
<smbconfoption name="path">/var/spool/samba</smbconfoption>
<smbconfoption name="browseable">no</smbconfoption>
<smbconfoption name="public">yes</smbconfoption>
<smbconfcomment>setting depends on your requirements</smbconfcomment>
<smbconfoption name="guest ok">yes</smbconfoption>
<smbconfoption name="writable">no</smbconfoption>
<smbconfoption name="printable">yes</smbconfoption>
<smbconfoption name="printer admin">root</smbconfoption>
 <smbconfsection name="[print$]"/>
<smbconfoption name="comment">Printer Drivers</smbconfoption>
<smbconfoption name="path">/etc/samba/drivers</smbconfoption>
<smbconfoption name="browseable">yes</smbconfoption>
<smbconfoption name="guest ok">no</smbconfoption>
<smbconfoption name="read only">yes</smbconfoption>
<smbconfoption name="write list">root</smbconfoption>
</smbconfblock>
</example>
</sect2>

<sect2>
<title>CUPS <quote>PostScript Driver for Windows NT/200x/XP</quote></title>

<para>
<indexterm><primary>PostScript</primary></indexterm>
CUPS users may get the exact same package from <ulink noescape="1"
url="http://www.cups.org/software.html">http://www.cups.org/software.html</ulink>.  It is a separate package
from the CUPS-based software files, tagged as CUPS 1.1.x Windows NT/200x/XP Printer Driver for Samba (tar.gz,
192k). The filename to download is <filename>cups-samba-1.1.x.tar.gz</filename>. Upon untar and unzipping, it
will reveal these files:
<screen>
&rootprompt;<userinput>tar xvzf cups-samba-1.1.19.tar.gz</userinput>
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss
</screen></para>

<para>
<indexterm><primary>ESP</primary><secondary>meta packager</secondary></indexterm>
<indexterm><primary>EPM</primary><see>ESP meta packager</see></indexterm>
These have been packaged with the ESP meta-packager software EPM. The <filename>*.install</filename> and
<filename>*.remove</filename> files are simple shell scripts, which untar the <filename>*.ss</filename> (the
<filename>*.ss</filename> is nothing else but a tar archive, which can be untarred by <quote>tar</quote> too).
Then it puts the content into <filename>/usr/share/cups/drivers/</filename>. This content includes three
files:
<screen>
&rootprompt;<userinput>tar tv cups-samba.ss</userinput>
cupsdrvr.dll
cupsui.dll
cups.hlp  
</screen></para>

<para>
The <parameter>cups-samba.install</parameter> shell scripts are easy to
handle:
<screen>
&rootprompt;<userinput>./cups-samba.install</userinput>
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.       
</screen></para>

<para>
The script should automatically put the driver files into the
<filename>/usr/share/cups/drivers/</filename> directory:
<screen>
&rootprompt;<userinput>cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/</userinput>
</screen></para>

<warning><para>
Due to a bug, one recent CUPS release puts the <filename>cups.hlp</filename> driver file
into<filename>/usr/share/drivers/</filename> instead of <filename>/usr/share/cups/drivers/</filename>. To work
around this, copy/move the file (after running the <command>./cups-samba.install</command> script) manually to
the correct place.
</para></warning>

<para>
<indexterm><primary>DDK</primary></indexterm>
This new CUPS PostScript driver is currently binary only, but free of charge. No complete source code is
provided (yet). The reason is that it has been developed with the help of the Microsoft DDK and compiled with
Microsoft Visual Studio 6. Driver developers are not allowed to distribute the whole of the source code as
free software. However, CUPS developers released the <quote>diff</quote> in source code under the GPL, so
anybody with a license for Visual Studio and a DDK will be able to compile for himself or herself.
</para>
</sect2>

<sect2>
<title>Recognizing Different Driver Files</title>

<para>
The CUPS drivers do not support the older Windows 95/98/Me, but only the Windows NT/2000/XP client.
</para>

<para>Windows NT, 2000, and XP are supported by:</para>

<itemizedlist>
	<listitem><para>cups.hlp</para></listitem>
	<listitem><para>cupsdrvr.dll</para></listitem>
	<listitem><para>cupsui.dll</para></listitem>
</itemizedlist>

<para>
Adobe drivers are available for the older Windows 95/98/Me as well as
for Windows NT/2000/XP clients. The set of files is different from the
different platforms.
</para>

<para>Windows 95, 98, and ME are supported by:</para>

<itemizedlist>
	<listitem><para>ADFONTS.MFM</para></listitem>
	<listitem><para>ADOBEPS4.DRV</para></listitem>
	<listitem><para>ADOBEPS4.HLP</para></listitem>
	<listitem><para>DEFPRTR2.PPD</para></listitem>
	<listitem><para>ICONLIB.DLL</para></listitem>
	<listitem><para>PSMON.DLL</para></listitem>
</itemizedlist>

<para>Windows NT, 2000, and XP are supported by:</para>

<itemizedlist>
	<listitem><para>ADOBEPS5.DLL</para></listitem>
	<listitem><para>ADOBEPSU.DLL</para></listitem>
	<listitem><para>ADOBEPSU.HLP</para></listitem>
</itemizedlist>

<note><para>
<indexterm><primary>Adobe driver files</primary></indexterm>
If both the Adobe driver files and the CUPS driver files for the support of Windows NT/200x/XP are presently
installed on the server, the Adobe files will be ignored and the CUPS files will be used. If you prefer
&smbmdash; for whatever reason &smbmdash; to use Adobe-only drivers, move away the three CUPS driver files.
The Windows 9x/Me clients use the Adobe drivers in any case.
</para></note>
</sect2>

<sect2>
<title>Acquiring the Adobe Driver Files</title>

<para>
Acquiring the Adobe driver files seems to be unexpectedly difficult for many users. They are not available on
the Adobe Web site as single files, and the self-extracting and/or self-installing Windows-.exe is not easy to
locate either. You probably need to use the included native installer and run the installation process on one
client once. This will install the drivers (and one generic PostScript printer) locally on the client. When
they are installed, share the generic PostScript printer. After this, the client's <smbconfsection
name="[print$]"/> share holds the Adobe files, which you can get with smbclient from the CUPS host.
</para>
</sect2>

<sect2>
<title>ESP Print Pro PostScript Driver for Windows NT/200x/XP</title>

<para>
<indexterm><primary>ESP</primary><secondary>Print Pro</secondary></indexterm>
Users of the ESP Print Pro software are able to install the ESP print drivers package as an alternative to the
Adobe PostScript drivers.  To do so, retrieve the driver files from the normal download area of the ESP Print
Pro software at <ulink noescape="1" url="http://www.easysw.com/software.html">Easy Software</ulink> web site.
You need to locate the link labeled <quote>SAMBA</quote> among the <guilabel>Download Printer Drivers for ESP
Print Pro 4.x</guilabel> area and download the package. Once installed, you can prepare any driver by simply
highlighting the printer in the Printer Manager GUI and selecting <guilabel>Export Driver...</guilabel> from
the menu. Of course, you need to have prepared Samba beforehand to handle the driver files; that is, set up
the <smbconfsection name="[print$]"/> share, and so on. The ESP Print Pro package includes the CUPS driver
files as well as a (licensed) set of Adobe drivers for the Windows 95/98/Me client family.
</para>
</sect2>

<sect2>
<title>Caveats to Be Considered</title>


<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<indexterm><primary>cups.hlp</primary></indexterm>
<indexterm><primary>WIN40</primary></indexterm>
<indexterm><primary>W32X86</primary></indexterm>
Once you have run the install script (and possibly manually moved the <filename>cups.hlp</filename> file to
<filename>/usr/share/cups/drivers/</filename>), the driver is ready to be put into Samba's <smbconfsection
name="[print$]"/> share (which often maps to <filename>/etc/samba/drivers/</filename> and contains a
subdirectory tree with <emphasis>WIN40</emphasis> and <emphasis>W32X86</emphasis> branches). You do this by
running <command>cupsaddsmb</command> (see also <command>man cupsaddsmb</command> for CUPS since release
1.1.16).
</para>

<tip><para>
<indexterm><primary>Single Sign-On</primary></indexterm>
<indexterm><primary>Domain Controller</primary></indexterm>
You may need to put root into the smbpasswd file by running <command>smbpasswd</command>; this is especially
important if you should run this whole procedure for the first time and are not working in an environment
where everything is configured for <emphasis>single sign-on</emphasis> to a Windows Domain Controller.
</para></tip>

<para>
Once the driver files are in the <smbconfsection name="[print$]"/> share and are initialized, they are ready
to be downloaded and installed by the Windows NT/200x/XP clients.
</para>

<note><para>
Win 9x/Me clients will not work with the CUPS PostScript driver. For these you still need to use the
<filename>ADOBE*.*</filename> drivers, as previously stated.
</para></note>

<note>
<para>
It is not harmful if you still have the <filename>ADOBE*.*</filename> driver files from previous installations
in the <filename>/usr/share/cups/drivers/</filename> directory. The new <command>cupsaddsmb</command> (from
1.1.16) will automatically prefer its own drivers if it finds both.
</para></note>

<note><para>
<indexterm><primary>"Printers" folder</primary></indexterm>
<indexterm><primary>Adobe PostScript</primary></indexterm>
Should your Windows clients have had the old <filename>ADOBE*.*</filename> files for the Adobe PostScript
driver installed, the download and installation of the new CUPS PostScript driver for Windows NT/200x/XP will
fail at first. You need to wipe the old driver from the clients first. It is not enough to
<quote>delete</quote> the printer, because the driver files will still be kept by the clients and re-used if
you try to re-install the printer. To really get rid of the Adobe driver files on the clients, open the
<guilabel>Printers</guilabel> folder (possibly via <guilabel>Start -> Settings -> Control Panel ->
Printers</guilabel>), right-click on the folder background, and select <guimenuitem>Server
Properties</guimenuitem>. When the new dialog opens, select the <guilabel>Drivers</guilabel> tab. On the list
select the driver you want to delete and click the <guilabel>Delete</guilabel> button. This will only work if
there is not one single printer left that uses that particular driver. You need to <quote>delete</quote> all
printers using this driver in the <guilabel>Printers</guilabel> folder first. You will need Administrator
privileges to do this.
</para></note>

<note><para>
<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
<indexterm><primary>CUPS PostScript</primary></indexterm>
Once you have successfully downloaded the CUPS PostScript driver to a client, you can easily switch all
printers to this one by proceeding as described in <link linkend="classicalprinting">Classical Printing
Support</link>. Either change a driver for an existing printer by running the <guilabel>Printer
Properties</guilabel> dialog, or use <command>rpcclient</command> with the <command>setdriver</command>
subcommand.
</para></note>
</sect2>

<sect2>
<title>Windows CUPS PostScript Driver Versus Adobe Driver</title>

<para>
Are you interested in a comparison between the CUPS and the Adobe PostScript drivers? For our purposes, these
are the most important items that weigh in favor of CUPS:
</para>

<itemizedlist>
	<listitem><para>No hassle with the Adobe EULA.</para></listitem>

	<listitem><para>No hassle with the question, <quote>Where do I
	get the ADOBE*.* driver files?</quote></para></listitem>

	<listitem><para>
	<indexterm><primary>PJL</primary></indexterm>
	The Adobe drivers (on request of the printer PPD associated with them) often put a PJL header in front of the
	main PostScript part of the print file. Thus, the print file starts with <parameter>&lt;1B
	&gt;%-12345X</parameter> or <parameter>&lt;escape&gt;%-12345X</parameter> instead of
	<parameter>%!PS</parameter>. This leads to the CUPS daemon autotyping the incoming file as a print-ready file,
	not initiating a pass through the <parameter>pstops</parameter> filter (to speak more technically, it is not
	regarded as the generic MIME-type <indexterm><primary>application/postscript</primary></indexterm>
	<parameter>application/postscript</parameter>, but as the more special MIME type
	<indexterm><primary>application/cups.vnd-postscript</primary></indexterm>
	<parameter>application/cups.vnd-postscript</parameter>), which therefore also leads to the page accounting in
	<parameter>/var/log/cups/page_log</parameter> not receiving the exact number of pages; instead the dummy page
	number of <quote>1</quote> is logged in a standard setup).
	</para></listitem>

	<listitem><para>The Adobe driver has more options to misconfigure the
<indexterm><primary>Adobe driver</primary></indexterm>
	PostScript generated by it (like setting it inadvertently to
	<guilabel>Optimize for Speed</guilabel> instead of
	<guilabel>Optimize for Portability</guilabel>, which
	could lead to CUPS being unable to process it).</para></listitem>

	<listitem><para>The CUPS PostScript driver output sent by Windows
<indexterm><primary>CUPS PostScript driver</primary></indexterm>
	clients to the CUPS server is guaranteed to autotype 
	as the generic MIME type <parameter>application/postscript</parameter>,
	thus passing through the CUPS <parameter>pstops</parameter> filter and logging the
	correct number of pages in the <filename>page_log</filename> for
	accounting and quota purposes.</para></listitem>

	<listitem><para>
	<indexterm><primary>banner pages</primary></indexterm>
	The CUPS PostScript driver supports the sending of additional standard (IPP) print options by Windows
	NT/200x/XP clients. Such additional print options are naming the CUPS standard <emphasis>banner
	pages</emphasis> (or the custom ones, should they be installed at the time of driver download), using the CUPS
	page-label option, setting a job priority, and setting the scheduled time of printing (with the option to
	support additional useful IPP job attributes in the future).
	</para></listitem>

	<listitem><para>The CUPS PostScript driver supports the inclusion of
	the new <parameter>*cupsJobTicket</parameter> comments at the
	beginning of the PostScript file (which could be used in the future
	for all sorts of beneficial extensions on the CUPS side, but which will
	not disturb any other applications because they will regard it as a comment
	and simply ignore it).</para></listitem>

	<listitem><para>The CUPS PostScript driver will be the heart of the
	fully fledged CUPS IPP client for Windows NT/200x/XP to be released soon
	(probably alongside the first beta release for CUPS 1.2).</para></listitem>
</itemizedlist>

</sect2>

<sect2>
<title>Run cupsaddsmb (Quiet Mode)</title>


<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<indexterm><primary>point 'n' print</primary></indexterm>
The <command>cupsaddsmb</command> command copies the needed files into your <smbconfsection name="[print$]"/>
share. Additionally, the PPD associated with this printer is copied from <filename>/etc/cups/ppd/</filename>
to <smbconfsection name="[print$]"/>. There the files wait for convenient Windows client installations via
Point'n'Print. Before we can run the command successfully, we need to be sure that we can authenticate toward
Samba. If you have a small network, you are probably using user-level security (<smbconfoption
name="security">user</smbconfoption>).
</para>

<para>
Here is an example of a successfully run <command>cupsaddsmb</command> command: 
<indexterm><primary>banner pages</primary></indexterm>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<screen>
&rootprompt;<userinput>cupsaddsmb -U root infotec_IS2027</userinput>
Password for root required to access localhost via Samba: <userinput>['secret']</userinput>
</screen></para>

<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
To share <emphasis>all</emphasis> printers and drivers, use the
<option>-a</option> parameter instead of a printer name. Since
<command>cupsaddsmb</command> <quote>exports</quote> the printer drivers to Samba, it should be
obvious that it only works for queues with a CUPS driver associated.
</para>
</sect2>

<sect2>
<title>Run cupsaddsmb with Verbose Output</title>


<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
Probably you want to see what's going on. Use the
<option>-v</option> parameter to get a more verbose output. The
output below was edited for better readability: all <quote>\</quote> at the end of
a line indicate that I inserted an artificial line break plus some
indentation here:
<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
<screen>
&rootprompt;<userinput>cupsaddsmb -U root -v infotec_2105</userinput>
Password for root required to access localhost via &example.server.samba;:
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
    -c 'mkdir W32X86; \
    put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \
	put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \
    put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \
    put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp
  
Running command: rpcclient localhost -N -U'root%secret' 
   -c 'adddriver "Windows NT x86"   \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
    RAW:NULL"'
cmd = adddriver "Windows NT x86" \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
	RAW:NULL"
Printer Driver infotec_2105 successfully installed.
  
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
-c 'mkdir WIN40; \
    put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \
	put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;   \
    put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \
    put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \
    put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \
	put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \
	put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
  Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
  NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
  putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD
  putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM
  putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV
  putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP
  putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD
  putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL
  putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL
  
  Running command: rpcclient localhost -N -U'root%secret' \
   -c 'adddriver "Windows 4.0"      \
   "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
   PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
    ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
	cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:\
	infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\
	infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\
	ICONLIB.DLL"
  Printer Driver infotec_2105 successfully installed.
  
  Running command: rpcclient localhost -N -U'root%secret'  \
   -c 'setdriver infotec_2105 infotec_2105'
  cmd = setdriver infotec_2105 infotec_2105
  Successfully set infotec_2105 to driver infotec_2105.
</screen></para>

<warning><para>
You will see the root password for the Samba account printed on screen. 
</para></warning>

<para>
If you look closely, you'll discover your root password was transferred unencrypted over the wire, so beware!
Also, if you look further, you may discover error messages like NT_STATUS_OBJECT_NAME_COLLISION in the output.
This will occur when the directories WIN40 and W32X86 already existed in the <smbconfsection name="[print$]"/>
driver download share (from a previous driver installation). These are harmless warning messages.
</para>
</sect2>

<sect2>
<title>Understanding cupsaddsmb</title>

<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
What has happened? What did <command>cupsaddsmb</command> do? There are five stages of the procedure:
</para>

<orderedlist>
	<listitem><para>
	<indexterm><primary>IPP</primary></indexterm>
	Call the CUPS server via IPP and request the driver files and the PPD file for the named printer.</para></listitem>

	<listitem><para>Store the files temporarily in the local TEMPDIR (as defined in <filename>cupsd.conf</filename>).</para></listitem>

	<listitem><para>Connect via smbclient to the Samba server's <smbconfsection name="[print$]"/> share and put the files into the
	 share's WIN40 (for Windows 9x/Me) and W32X86 (for Windows NT/200x/XP) subdirectories.</para></listitem>

	<listitem><para>
	<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
	Connect via rpcclient to the Samba server and execute the <command>adddriver</command> command with the correct parameters.
	</para></listitem>

	<listitem><para>
	<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
	Connect via rpcclient to the Samba server a second time and execute the <command>setdriver</command> command.</para></listitem>
</orderedlist>

<note>
<para>
You can run the <command>cupsaddsmb</command> utility with parameters to specify one remote host as Samba host
and a second remote host as CUPS host. Especially if you want to get a deeper understanding, it is a good idea
to try it and see more clearly what is going on (though in real life most people will have their CUPS and
Samba servers run on the same host):
<screen>
&rootprompt;<userinput>cupsaddsmb -H sambaserver -h cupsserver -v printer</userinput>
</screen>
</para></note>

</sect2>

<sect2>
<title>How to Recognize If cupsaddsmb Completed Successfully</title>

<para>
You <emphasis>must</emphasis> always check if the utility completed
successfully in all fields. You need at minimum these three messages
among the output:
</para>

<orderedlist>
	<listitem><para><emphasis>Printer Driver infotec_2105 successfully
	installed.</emphasis> # (for the W32X86 == Windows NT/200x/XP
	architecture).</para></listitem>

	<listitem><para><emphasis>Printer Driver infotec_2105 successfully
	installed.</emphasis> # (for the WIN40 == Windows 9x/Me
	architecture).</para></listitem>

	<listitem><para><emphasis>Successfully set [printerXPZ] to driver
	[printerXYZ].</emphasis></para></listitem>
</orderedlist>

<para>
These messages are probably not easily recognized in the general
output. If you run <command>cupsaddsmb</command> with the <option>-a</option>
parameter (which tries to prepare <emphasis>all</emphasis> active CUPS
printer drivers for download), you might miss if individual printer
drivers had problems installing properly. A redirection of the
output will help you analyze the results in retrospective.
</para>

<para>
If you get:
<screen>
SetPrinter call failed!
result was WERR_ACCESS_DENIED
</screen>
it means that you might have set <smbconfoption name="use client driver">yes</smbconfoption> for this printer. 
Setting it to <quote>no</quote> will solve the problem. Refer to the &smb.conf; man page for explanation of 
the <parameter>use client driver</parameter>.
</para>

<note><para>
It is impossible to see any diagnostic output if you do not run <command>cupsaddsmb</command> in verbose mode.
Therefore, we strongly recommend against use of the default quiet mode. It will hide any problems from you that
might occur.
</para></note>
</sect2>

<sect2>
<title>cupsaddsmb with a Samba PDC</title>

<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<indexterm><primary>PDC</primary></indexterm>
Can't get the standard <command>cupsaddsmb</command> command to run on a Samba PDC?  Are you asked for the
password credential again and again, and the command just will not take off at all? Try one of these
variations:
</para>

<para><screen>
&rootprompt;<userinput>cupsaddsmb -U &example.workgroup;\\root -v printername</userinput>
&rootprompt;<userinput>cupsaddsmb -H &example.pdc.samba; -U &example.workgroup;\\root -v printername</userinput>
&rootprompt;<userinput>cupsaddsmb -H &example.pdc.samba; -U &example.workgroup;\\root -h cups-server -v printername</userinput>
</screen></para>

<para>
(Note the two backslashes: the first one is required to <quote>escape</quote> the second one).
</para>
</sect2>

<sect2>
<title>cupsaddsmb Flowchart</title>

<para>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<indexterm><primary>raw print</primary></indexterm>
<link linkend="small14">The cupsaddsmb Flowchart</link> shows a chart about the procedures, command flows, and
data flows of the <command>cupaddsmb</command> command. Note again: cupsaddsmb is
not intended to, and does not work with, raw print queues!
</para>

	<figure id="small14">
		<title>cupsaddsmb Flowchart.</title>
		<imagefile>14small</imagefile></figure>
</sect2>

<sect2>
<title>Installing the PostScript Driver on a Client</title>

<para>
<indexterm><primary>point'n'print</primary></indexterm>
<indexterm><primary>cupsaddsmb</primary></indexterm>
After <command>cupsaddsmb</command> is completed, your driver is prepared for the clients to use. Here are the
steps you must perform to download and install it via Point'n'Print. From a Windows client, browse to the
CUPS/Samba server:
</para>

<itemizedlist>

	<listitem><para>
	<indexterm><primary>"Printers" folder</primary></indexterm>
	Open the <guilabel>Printers</guilabel> share of Samba in Network Neighborhood.</para></listitem>

	<listitem><para>Right-click on the printer in question.</para></listitem>

	<listitem><para>From the opening context menu select
	<guimenuitem>Install...</guimenuitem> or 
	<guimenuitem>Connect...</guimenuitem> (depending on the Windows version you use).</para></listitem>
</itemizedlist>

<para>
After a few seconds, there should be a new printer in your client's <emphasis>local</emphasis>
<guilabel>Printers</guilabel> folder. On Windows XP it will follow a naming convention of
<emphasis>PrinterName on SambaServer</emphasis>. (In my current case it is infotec_2105 on kde-bitshop). If
you want to test it and send your first job from an application like Winword, the new printer appears in a
<filename>\\SambaServer\PrinterName</filename> entry in the drop-down list of available printers.
</para>

<para>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>Adobe PostScript driver</primary></indexterm>
<indexterm><primary>net use lpt1:</primary></indexterm>
<command>cupsaddsmb</command> will only reliably work with CUPS version 1.1.15 or higher and with Samba
version 2.2.4, or later. If it does not work, or if the automatic printer driver download to the clients does
not succeed, you can still manually install the CUPS printer PPD on top of the Adobe PostScript driver on
clients. Then point the client's printer queue to the Samba printer share for a UNC type of connection:
<screen>
&dosprompt;<userinput>net use lpt1: \\sambaserver\printershare /user:ntadmin</userinput>
</screen>
should you desire to use the CUPS networked PostScript RIP functions. (Note that user <quote>ntadmin</quote>
needs to be a valid Samba user with the required privileges to access the printershare.) This sets up the
printer connection in the traditional LanMan way (not using MS-RPC).
</para>
</sect2>

<sect2 id="cups-avoidps1">
<title>Avoiding Critical PostScript Driver Settings on the Client</title>

<para>
Printing works, but there are still problems. Most jobs print well, some do not print at all. Some jobs have
problems with fonts, which do not look very good. Some jobs print fast and some are dead-slow. Many of these
problems can be greatly reduced or even completely eliminated if you follow a few guidelines. Remember, if
your print device is not PostScript-enabled, you are treating your Ghostscript installation on your CUPS host
with the output your client driver settings produce. Treat it well:
</para>

<itemizedlist>
	<listitem><para>
	Avoid the PostScript Output Option: Optimize for Speed setting. Use the Optimize for Portability instead
	(Adobe PostScript driver).</para></listitem>

	<listitem><para>
	Don't use the Page Independence: NO setting. Instead, use Page Independence: YES (CUPS PostScript Driver).
	</para></listitem>

	<listitem><para>
	Recommended is the True Type Font Downloading Option: Native True Type over Automatic and Outline; 
	you should by all means avoid Bitmap (Adobe PostScript Driver).</para></listitem>

	<listitem><para>
	Choose True Type Font: Download as Softfont into Printer over the default Replace by Device
	Font (for exotic fonts, you may need to change it back to get a printout at all; Adobe).</para></listitem>

	<listitem><para>
	Sometimes you can choose PostScript Language Level: in case of problems try 2
	instead of 3 (the latest ESP Ghostscript package handles Level 3 PostScript very well; Adobe).
	</para></listitem>

	<listitem><para>
	Say Yes to PostScript Error Handler (Adobe).</para></listitem>
</itemizedlist>

</sect2>
</sect1>

<sect1>
<title>Installing PostScript Driver Files Manually Using rpcclient</title>

<para>
Of course, you can run all the commands that are embedded into the
cupsaddsmb convenience utility yourself, one by one, and upload
and prepare the driver files for future client downloads.
</para>

<orderedlist>
	<listitem><para>Prepare Samba (a CUPS print queue with the name of the
	printer should be there. We are providing the driver now).</para></listitem>

	<listitem><para>Copy all files to <smbconfsection name="[print$]"/>.</para></listitem>

	<listitem><para>
	<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
	Run <command>rpcclient adddriver</command>
	(for each client architecture you want to support).</para></listitem>

	<listitem><para>
	<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
	Run <command>rpcclient setdriver.</command></para></listitem>
</orderedlist>

<para>
<indexterm><primary>rpcclient</primary><secondary>enumports</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>enumdrivers</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
We are going to do this now. First, read the man page on <parameter>rpcclient</parameter> to get a first idea.
Look at all the printing-related subcommands: <command>enumprinters</command>, <command>enumdrivers</command>,
<command>enumports</command>, <command>adddriver</command>, and <command>setdriver</command> are among the
most interesting ones. <parameter>rpcclient</parameter> implements an important part of the MS-RPC protocol.
You can use it to query (and command) a Windows NT (or 200x/XP) PC, too. MS-RPC is used by Windows clients,
among other things, to benefit from the Point'n'Print features. Samba can now mimic this as well.
</para>

<sect2>
<title>A Check of the rpcclient man Page</title>

<para>
First let's check the <parameter>rpcclient</parameter> man page. Here are two relevant passages:
</para>

<para>
<indexterm><primary>adddriver</primary></indexterm>
<indexterm><primary>AddPrinterDriver()</primary></indexterm>
<indexterm><primary>getdriverdir</primary></indexterm>
<command>adddriver &lt;arch&gt; &lt;config&gt;</command> Execute an <command>AddPrinterDriver()</command> RPC
to install the printer driver information on the server. The driver files should already exist in the
directory returned by <command>getdriverdir</command>. Possible values for <parameter>arch</parameter> are the
same as those for the <command>getdriverdir</command> command. The <parameter>config</parameter> parameter is
defined as follows:
<screen>
Long Printer Name:\
Driver File Name:\
Data File Name:\
Config File Name:\
Help File Name:\
Language Monitor Name:\
Default Data Type:\
Comma Separated list of Files
</screen></para>

<para>
Any empty fields should be entered as the string <quote>NULL</quote>. 
</para>

<para>
Samba does not need to support the concept of print monitors, since these only apply to local printers whose
drivers can use a bidirectional link for communication. This field should be <quote>NULL</quote>.  On a remote
NT print server, the print monitor for a driver must already be installed before adding the driver or else the
RPC will fail.
</para>

<para>
<indexterm><primary>setdriver</primary></indexterm>
<indexterm><primary>SetPrinter()</primary></indexterm>
<command>setdriver &lt;printername&gt; &lt;drivername&gt;</command> Execute a <command>SetPrinter()</command>
command to update the printer driver associated with an installed printer. The printer driver must already be
correctly installed on the print server.
</para>

<para>
<indexterm><primary>enumprinters</primary></indexterm>
<indexterm><primary>enumdrivers</primary></indexterm>
See also the <command>enumprinters</command> and <command>enumdrivers</command> commands to
obtain a list of installed printers and drivers.
</para>

</sect2>

<sect2>
<title>Understanding the rpcclient man Page</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
The <emphasis>exact</emphasis> format isn't made too clear by the man page, since you have to deal with some
parameters containing spaces. Here is a better description for it. We have line-broken the command and
indicated the breaks with <quote>\</quote>. Usually you would type the command in one line without the line
breaks:
<screen>
adddriver "Architecture" \
   "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
   LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"
</screen></para>

<para>
What the man pages denote as a simple <parameter>&lt;config&gt;</parameter> keyword in reality consists of
eight colon-separated fields. The last field may take multiple (in some very insane cases, even 20 different
additional) files. This might sound confusing at first.  What the man pages call the
<quote>LongPrinterName</quote> in reality should be called the <quote>Driver Name</quote>. You can name it
anything you want, as long as you use this name later in the <command>rpcclient ... setdriver</command>
command. For practical reasons, many name the driver the same as the printer.
</para>

<para>
It isn't simple at all. I hear you asking: <quote>How do I know which files are Driver File</quote>,
<quote>Data File</quote>, <quote>Config File</quote>, <quote>Help File</quote> and <quote>Language Monitor
File in each case?</quote> For an answer, you may want to have a look at how a Windows NT box with a shared
printer presents the files to us. Remember that this whole procedure has to be developed by the Samba Team by
listening to the traffic caused by Windows computers on the wire. We may as well turn to a Windows box now and
access it from a UNIX workstation. We will query it with <command>rpcclient</command> to see what it tells us
and try to understand the man page more clearly.
</para>
</sect2>

<sect2>
<title>Producing an Example by Querying a Windows Box</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>getdriver</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>getprinter</secondary></indexterm>
We could run <command>rpcclient</command> with a <command>getdriver</command> or a
<command>getprinter</command> subcommand (in level 3 verbosity) against it. Just sit down at a UNIX or Linux
workstation with the Samba utilities installed, then type the following command:
<screen>
&rootprompt;<userinput>rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'</userinput>
</screen></para>

<para>
From the result it should become clear which is which. Here is an example from my installation:
<indexterm><primary>rpcclient</primary><secondary>getdriver</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -U'Danka%xxxx' W200xSERVER \
    -c'getdriver "DANKA InfoStream Virtual Printer" 3'</userinput>
    cmd = getdriver "DANKA InfoStream Virtual Printer" 3

 [Windows NT x86]
 Printer Driver Info 3:
         Version: [2]
         Driver Name: [DANKA InfoStream]
         Architecture: [Windows NT x86]
         Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
         Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
         Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
         Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]
 
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
 
         Monitorname: []
         Defaultdatatype: []
</screen></para>

<para>
Some printer drivers list additional files under the label <parameter>Dependentfiles</parameter>, and these
would go into the last field <parameter>ListOfFiles,Comma-separated</parameter>. For the CUPS PostScript
drivers, we do not need any (nor would we for the Adobe PostScript driver); therefore, the field will get a
<quote>NULL</quote> entry.
</para>
</sect2>

<sect2>
<title>Requirements for adddriver and setdriver to Succeed</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
<indexterm><primary>cupsaddsmb</primary></indexterm>
<indexterm><primary>setdriver</primary></indexterm>
From the man page (and from the quoted output of <command>cupsaddsmb</command> above) it becomes clear that
you need to have certain conditions in order to make the manual uploading and initializing of the driver files
succeed. The two <command>rpcclient</command> subcommands (<command>adddriver</command> and
<command>setdriver</command>) need to encounter the following preconditions to complete successfully:
</para>

<itemizedlist>
	<listitem><para>You are connected as <smbconfoption name="printer admin"/> or root (this is
	<emphasis>not</emphasis> the <quote>Printer Operators</quote> group in NT, but the <emphasis>printer
	admin</emphasis> group as defined in the <smbconfsection name="[global]"/> section of &smb.conf;).
	</para></listitem>

	<listitem><para>Copy all required driver files to <filename>\\SAMBA\print$\w32x86</filename> and
	<filename>\\SAMBA\print$\win40</filename> as appropriate. They will end up in the <quote>0</quote> respective
	<quote>2</quote> subdirectories later. For now, <emphasis>do not</emphasis> put them there; they'll be
	automatically used by the <command>adddriver</command> subcommand. (If you use <command>smbclient</command> to
	put the driver files into the share, note that you need to escape the <quote>$</quote>: <command>smbclient
	//sambaserver/print\$ -U root.</command>)</para></listitem>

	<listitem><para>The user you're connecting as must be able to write to
	the <smbconfsection name="[print$]"/> share and create
	subdirectories.</para></listitem>

	<listitem><para>The printer you are going to set up for the Windows
	clients needs to be installed in CUPS already.</para></listitem>

	<listitem><para>
	<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
	<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
	The CUPS printer must be known to Samba; otherwise the <command>setdriver</command> subcommand fails with an
	NT_STATUS_UNSUCCESSFUL error. To check if the printer is known by Samba, you may use the
	<command>enumprinters</command> subcommand to <command>rpcclient</command>. A long-standing bug prevented a
	proper update of the printer list until every smbd process had received a SIGHUP or was restarted. Remember
	this in case you've created the CUPS printer just recently and encounter problems: try restarting Samba.
	</para></listitem>
</itemizedlist>
</sect2>

<sect2>
<title>Manual Driver Installation in 15 Steps</title>

<para>
We are going to install a printer driver now by manually executing all
required commands. Because this may seem a rather complicated process at
first, we go through the procedure step by step, explaining every
single action item as it comes up.
</para>

<procedure>
<title>Manual Driver Installation</title>

	<step>
	<title>Install the printer on CUPS.</title>

	<para><screen>
	&rootprompt;<userinput>lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E \
				-P canonIR85.ppd</userinput>
	</screen></para>

	<para>
	This installs a printer with the name <parameter>mysmbtstprn</parameter>
	to the CUPS system. The printer is accessed via a socket
	(a.k.a. JetDirect or Direct TCP/IP) connection. You need to be root
	for this step.
	</para>
	</step>

	<step>
	<title>(Optional.) Check if the printer is recognized by Samba.</title>

	<para>
	<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'enumprinters' localhost \
  | grep -C2 mysmbtstprn</userinput>
flags:[0x800000]
name:[\\kde-bitshop\mysmbtstprn]
description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn]
comment:[mysmbtstprn]
</screen>
	</para>

	<para>
	This should show the printer in the list. If not, stop and restart the Samba daemon (smbd) or send a HUP signal: 
<screen>
&rootprompt;<userinput>kill -HUP `pidof smbd`</userinput>
</screen>
	Check again. Troubleshoot and repeat until successful. Note the <quote>empty</quote> field between the two
	commas in the <quote>description</quote> line. The driver name would appear here if there was one already. You
	need to know root's Samba password (as set by the <command>smbpasswd</command> command) for this step and most
	of the following steps. Alternatively, you can authenticate as one of the users from the <quote>write
	list</quote> as defined in &smb.conf; for <smbconfsection name="[print$]"/>.
	</para>
	</step>

	<step>
	<title>(Optional.) Check if Samba knows a driver for the printer.</title>

	<para>
	<indexterm><primary>rpcclient</primary><secondary>getprinter</secondary></indexterm>
	<indexterm><primary>rpcclient</primary><secondary>getdriver</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2'\
 localhost | grep driver </userinput>

drivername:[]

&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' \
 localhost | grep -C4 driv</userinput>

servername:[\\kde-bitshop]
printername:[\\kde-bitshop\mysmbtstprn]
sharename:[mysmbtstprn]
portname:[Samba Printer Port]
drivername:[]
comment:[mysmbtstprn]
location:[]
sepfile:[]
printprocessor:[winprint]
 
&rootprompt;<userinput>rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost</userinput>
 result was WERR_UNKNOWN_PRINTER_DRIVER
</screen></para>

<para>
None of the three commands shown above should show a driver.
This step was done for the purpose of demonstrating this condition. An
attempt to connect to the printer at this stage will prompt a
message along the lines of, <quote>The server does not have the required printer
driver installed.</quote>
</para>
</step>

<step>
<title>Put all required driver files into Samba's
[print$].</title>

<para><screen>
&rootprompt;<userinput>smbclient //localhost/print\$ -U 'root%xxxx' \
	-c 'cd W32X86; \
	put /etc/cups/ppd/mysmbtstprn.ppd mysmbtstprn.PPD; \ 
	put /usr/share/cups/drivers/cupsui.dll cupsui.dll; \
	put /usr/share/cups/drivers/cupsdrvr.dll cupsdrvr.dll; \
	put /usr/share/cups/drivers/cups.hlp cups.hlp'</userinput>
</screen></para>

<para>
(This command should be entered in one long single line. Line breaks and the line ends indicated by
<quote>\</quote> have been inserted for readability reasons.) This step is <emphasis>required</emphasis> for
the next one to succeed. It makes the driver files physically present in the <smbconfsection name="[print$]"/>
share. However, clients would still not be able to install them, because Samba does not yet treat them as
driver files. A client asking for the driver would still be presented with a <quote>not installed here</quote>
message.
</para>
</step>

<step>
<title>Verify where the driver files are now.</title>

<para><screen>
&rootprompt;<userinput>ls -l /etc/samba/drivers/W32X86/</userinput>
total 669
drwxr-sr-x    2 root     ntadmin       532 May 25 23:08 2
drwxr-sr-x    2 root     ntadmin       670 May 16 03:15 3
-rwxr--r--    1 root     ntadmin     14234 May 25 23:21 cups.hlp
-rwxr--r--    1 root     ntadmin    278380 May 25 23:21 cupsdrvr.dll
-rwxr--r--    1 root     ntadmin    215848 May 25 23:21 cupsui.dll
-rwxr--r--    1 root     ntadmin    169458 May 25 23:21 mysmbtstprn.PPD
</screen></para>

<para>
The driver files now are in the W32X86 architecture <quote>root</quote> of
<smbconfsection name="[print$]"/>.
</para>
</step>

<step>
<title>Tell Samba that these are driver files (<command>adddriver</command>).</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>adddriver</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'adddriver "Windows NT x86" \
	"mydrivername:cupsdrvr.dll:mysmbtstprn.PPD: \
  cupsui.dll:cups.hlp:NULL:RAW:NULL"' \
  localhost</userinput>
Printer Driver mydrivername successfully installed.
</screen></para>

<para>
You cannot repeat this step if it fails. It could fail even as a result of a simple typo. It will most likely
have moved a part of the driver files into the <quote>2</quote> subdirectory. If this step fails, you need to
go back to the fourth step and repeat it before you can try this one again. In this step, you need to choose a
name for your driver. It is normally a good idea to use the same name as is used for the printer name;
however, in big installations you may use this driver for a number of printers that obviously have different
names, so the name of the driver is not fixed.
</para>
</step>

<step>
<title>Verify where the driver files are now.</title>

<para><screen>
&rootprompt;<userinput>ls -l /etc/samba/drivers/W32X86/</userinput>
total 1
drwxr-sr-x    2 root     ntadmin       532 May 25 23:22 2
drwxr-sr-x    2 root     ntadmin       670 May 16 03:15 3

&rootprompt;<userinput>ls -l /etc/samba/drivers/W32X86/2</userinput>
total 5039
[....]
-rwxr--r--    1 root     ntadmin     14234 May 25 23:21 cups.hlp
-rwxr--r--    1 root     ntadmin    278380 May 13 13:53 cupsdrvr.dll
-rwxr--r--    1 root     ntadmin    215848 May 13 13:53 cupsui.dll
-rwxr--r--    1 root     ntadmin    169458 May 25 23:21 mysmbtstprn.PPD
</screen></para>

<para>
Notice how step 6 also moved the driver files to the appropriate
subdirectory. Compare this with the situation after step 5.
</para>
</step>

<step>
<title>(Optional.) Verify if Samba now recognizes the driver.</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>enumdrivers</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'enumdrivers 3' \
	localhost | grep -B2 -A5 mydrivername</userinput>
Printer Driver Info 3:
Version: [2]
Driver Name: [mydrivername]
Architecture: [Windows NT x86]
Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
</screen></para>

<para>
Remember, this command greps for the name you chose for the
driver in step 6. This command must succeed before you can proceed.
</para>
</step>

<step>
<para><title>Tell Samba which printer should use these driver files (<command>setdriver</command>).</title></para>

<para>
<indexterm><primary>rpcclient</primary><secondary>setdriver</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' \
	localhost</userinput>
Successfully set mysmbtstprn to driver mydrivername
</screen></para>

<para>
Since you can bind any printer name (print queue) to any driver, this is a convenient way to set up many
queues that use the same driver. You do not need to repeat all the previous steps for the setdriver command to
succeed. The only preconditions are that <command>enumdrivers</command> must find the driver and
<command>enumprinters</command> must find the printer.
</para>
</step>

<step>
<title>(Optional) Verify if Samba has recognized this association.</title>

<para>
<indexterm><primary>rpcclient</primary><secondary>getprinter</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>getdriver</secondary></indexterm>
<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \
  | grep driver</userinput>
drivername:[mydrivername]
 
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \
  | grep -C4 driv</userinput>
servername:[\\kde-bitshop]
printername:[\\kde-bitshop\mysmbtstprn]
sharename:[mysmbtstprn]
portname:[Done]
drivername:[mydrivername]
comment:[mysmbtstprn]
location:[]
sepfile:[]
printprocessor:[winprint]
 
&rootprompt;<userinput>rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost</userinput>
[Windows NT x86]
Printer Driver Info 3:
     Version: [2]
     Driver Name: [mydrivername]
     Architecture: [Windows NT x86]
     Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
     Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
     Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
     Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
     Monitorname: []
     Defaultdatatype: [RAW]
     Monitorname: []
     Defaultdatatype: [RAW]
 
&rootprompt;<userinput>rpcclient -Uroot%xxxx -c 'enumprinters' localhost \
	| grep mysmbtstprn</userinput>
     name:[\\kde-bitshop\mysmbtstprn]
     description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn]
     comment:[mysmbtstprn]

</screen></para>

<para>
<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
Compare these results with the ones from steps 2 and 3. Every one of these commands show the driver is installed. Even
the <command>enumprinters</command> command now lists the driver
on the <quote>description</quote> line.
</para>
</step>

<step>
<title>(Optional.) Tickle the driver into a correct
device mode.</title>

<para>
<indexterm><primary>"Printers" folder</primary></indexterm>
You certainly know how to install the driver on the client. In case
you are not particularly familiar with Windows, here is a short
recipe: Browse the Network Neighborhood, go to the Samba server, and look
for the shares. You should see all shared Samba printers.
Double-click on the one in question. The driver should get
installed and the network connection set up. Another way is to
open the <guilabel>Printers (and Faxes)</guilabel> folder, right-click on the printer in
question, and select <guilabel>Connect</guilabel> or <guilabel>Install</guilabel>. As a result, a new printer
should appear in your client's local <guilabel>Printers (and Faxes)</guilabel>
folder, named something like <guilabel>printersharename on Sambahostname</guilabel>.
</para>

<para>
It is important that you execute this step as a Samba printer admin
(as defined in &smb.conf;). Here is another method
to do this on Windows XP. It uses a command line, which you may type
into the <quote>DOS box</quote> (type root's smbpassword when prompted):
</para>

<para><screen>
&dosprompt;<userinput>runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry \
	/in /n \\sambaserver\mysmbtstprn"</userinput>
</screen></para>

<para>
Change any printer setting once (like changing <emphasis><guilabel>portrait</guilabel> to
<guilabel>landscape</guilabel></emphasis>), click on <guibutton>Apply</guibutton>, and change the setting back.
</para>
</step>

<step>
<title>Install the printer on a client (Point'n'Print).</title>

<para>
<indexterm significance="preferred"><primary>point 'n' print</primary></indexterm>
<screen>
&dosprompt;<userinput>rundll32 printui.dll,PrintUIEntry /in /n &quot;\\sambaserver\mysmbtstprn&quot;</userinput>
</screen>
If it does not work, it could be a permissions problem with the <smbconfsection name="[print$]"/> share.
</para>
</step>

<step>
<title>(Optional) Print a test page.</title>

<indexterm><primary>rundll32</primary></indexterm>
<para><screen>
&dosprompt;<userinput>rundll32 printui.dll,PrintUIEntry /p /n "\\sambaserver\mysmbtstprn"</userinput>
</screen></para>

<para>
Then hit [TAB] five times, [ENTER] twice, [TAB] once, and [ENTER] again, and march to the printer.
</para>
</step>

<step>
<title>(Recommended.) Study the test page.</title>

<para>
Hmmm. Just kidding! By now you know everything about printer installations and you do not need to read a word.
Just put it in a frame and bolt it to the wall with the heading "MY FIRST RPCCLIENT-INSTALLED PRINTER"
&smbmdash; why not just throw it away!
</para>
</step>

<step>
<title>(Obligatory.) Enjoy. Jump. Celebrate your success.</title>

<para><screen>
&rootprompt;<userinput>echo "Cheeeeerioooooo! Success..." &gt;&gt; /var/log/samba/log.smbd</userinput>
</screen></para>
</step>
</procedure>
</sect2>

<sect2>
<title>Troubleshooting Revisited</title>

<para>
<indexterm><primary>adddriver</primary></indexterm>
The setdriver command will fail if in Samba's mind the queue is not
already there. A successful installation displys the promising message that the:
<screen>
Printer Driver ABC successfully installed.
</screen>
following the <command>adddriver</command> parts of the procedure.  But you may also see
a disappointing message like this one:
<computeroutput>
result was NT_STATUS_UNSUCCESSFUL
</computeroutput></para>

<para>
<indexterm><primary>lpstat</primary></indexterm>
<indexterm><primary>rpcclient</primary></indexterm>
It is not good enough that you can see the queue in CUPS, using the <command>lpstat -p ir85wm</command>
command. A bug in most recent versions of Samba prevents the proper update of the queue list. The recognition
of newly installed CUPS printers fails unless you restart Samba or send a HUP to all smbd processes. To verify
if this is the reason why Samba does not execute the <command>setdriver</command> command successfully, check
if Samba <quote>sees</quote> the printer:
<indexterm><primary>rpcclient</primary><secondary>enumprinters</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm</userinput>
        printername:[ir85wm]
</screen></para>

<para>
An alternate command could be this: 
<indexterm><primary>rpcclient</primary><secondary>getprinter</secondary></indexterm>
<screen>
&rootprompt;<userinput>rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' </userinput>
        cmd = getprinter ir85wm
        flags:[0x800000]
        name:[\\transmeta\ir85wm]
        description:[\\transmeta\ir85wm,ir85wm,DPD]
        comment:[CUPS PostScript-Treiber for Windows NT/200x/XP]
</screen></para>

<para>
By the way, you can use these commands, plus a few more, of course, to install drivers on remote Windows NT print servers too!
</para>
</sect2>
</sect1>

<sect1>
<title>The Printing <filename>*.tdb</filename> Files</title>

<para>
<indexterm><primary>TDB</primary></indexterm>
<indexterm><primary>connections.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>printing.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>share_info.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>ntdrivers.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>unexpected.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>brlock.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>locking.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>ntforms.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>messages.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>ntprinters.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>sessionid.tdb</primary><seealso>TDB</seealso></indexterm>
<indexterm><primary>secrets.tdb</primary><seealso>TDB</seealso></indexterm>
Some mystery is associated with the series of files with a tdb suffix appearing in every Samba installation.
They are <filename>connections.tdb</filename>, <filename>printing.tdb</filename>,
<filename>share_info.tdb</filename>, <filename>ntdrivers.tdb</filename>, <filename>unexpected.tdb</filename>,
<filename>brlock.tdb</filename>, <filename>locking.tdb</filename>, <filename>ntforms.tdb</filename>,
<filename>messages.tdb</filename> , <filename>ntprinters.tdb</filename>, <filename>sessionid.tdb</filename>,
and <filename>secrets.tdb</filename>. What is their purpose?
</para>

<sect2>
<title>Trivial Database Files</title>

<para>
<indexterm><primary>TDB</primary></indexterm>
A Windows NT (print) server keeps track of all information needed to serve its duty toward its clients by
storing entries in the Windows registry. Client queries are answered by reading from the registry,
Administrator or user configuration settings that are saved by writing into the registry. Samba and UNIX
obviously do not have such a Registry. Samba instead keeps track of all client-related information in a series
of <filename>*.tdb</filename> files. (TDB stands for trivial data base). These are often located in
<filename>/var/lib/samba/</filename> or <filename>/var/lock/samba/</filename>. The printing-related files are
<filename>ntprinters.tdb</filename>, <filename>printing.tdb</filename>,<filename>ntforms.tdb</filename>, and
<filename>ntdrivers.tdb</filename>.
</para>
</sect2>

<sect2>
<title>Binary Format</title>

<para>
<filename>*.tdb</filename> files are not human readable. They are written in a binary format. <quote>Why not
ASCII?</quote>, you may ask. <quote>After all, ASCII configuration files are a good and proven tradition on
UNIX.</quote> The reason for this design decision by the Samba Team is mainly performance. Samba needs to be
fast; it runs a separate <command>smbd</command> process for each client connection, in some environments many
thousands of them. Some of these <command>smbds</command> might need to write-access the same
<filename>*.tdb</filename> file <emphasis>at the same time</emphasis>. The file format of Samba's
<filename>*.tdb</filename> files allows for this provision. Many smbd processes may write to the same
<filename>*.tdb</filename> file at the same time. This wouldn't be possible with pure ASCII files.
</para>
</sect2>

<sect2>
<title>Losing <filename>*.tdb</filename> Files</title>

<para>
It is very important that all <filename>*.tdb</filename> files remain consistent over all write and read
accesses. However, it may happen that these files <emphasis>do</emphasis> get corrupted. (A <command>kill -9
`pidof smbd'</command> while a write access is in progress could do the damage, as could a power interruption,
etc.). In cases of trouble, a deletion of the old printing-related <filename>*.tdb</filename> files may be the
only option. After that, you need to re-create all print-related setups unless you have made a backup of the
<filename>*.tdb</filename> files in time.
</para>
</sect2>

<sect2>
<title>Using <command>tdbbackup</command></title>

<para>
<indexterm><primary>TDB</primary><secondary>backing up</secondary><see>tdbbackup</see></indexterm>
<indexterm><primary>tdbbackup</primary></indexterm>
Samba ships with a little utility that helps the root user of your system to backup your
<filename>*.tdb</filename> files. If you run it with no argument, it prints a usage message:
<screen>
&rootprompt;<userinput>tdbbackup</userinput>
 Usage: tdbbackup [options] &lt;fname...&gt;
 
 Version:3.0a
   -h            this help message
   -s suffix     set the backup suffix
   -v            verify mode (restore if corrupt)
</screen></para>

<para>
Here is how I backed up my <filename>printing.tdb</filename> file:
</para>

<para><screen>
&rootprompt;<userinput>ls</userinput>
.              browse.dat     locking.tdb     ntdrivers.tdb printing.tdb
..             share_info.tdb connections.tdb messages.tdb  ntforms.tdb
printing.tdbkp unexpected.tdb brlock.tdb      gmon.out      namelist.debug  
ntprinters.tdb sessionid.tdb
 
&rootprompt;<userinput>tdbbackup -s .bak printing.tdb</userinput>
 printing.tdb : 135 records
 
&rootprompt;<userinput>ls -l printing.tdb*</userinput>
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb.bak

</screen></para>
</sect2>
</sect1>

<sect1>
<title>CUPS Print Drivers from Linuxprinting.org</title>

<para>
<indexterm><primary>Linuxprinting.org</primary></indexterm>
CUPS ships with good support for HP LaserJet-type printers. You can install the generic driver as follows:
<indexterm><primary>lpadmin</primary></indexterm>
<screen>
&rootprompt;<userinput>lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd</userinput>
</screen></para>

<para>
The <option>-m</option> switch will retrieve the <filename>laserjet.ppd</filename> from the standard
repository for not-yet-installed PPDs, which CUPS typically stores in
<filename>/usr/share/cups/model</filename>. Alternatively, you may use <option>-P /path/to/your.ppd</option>.
</para>

<para>
The generic <filename>laserjet.ppd,</filename> however, does not support every special option for every
LaserJet-compatible model. It constitutes a sort of <quote>least common denominator</quote> of all the models.
If for some reason you must pay for the commercially available ESP Print Pro drivers, your first move should
be to consult the database on the <ulink noescape="1"
url="http://www.linuxprinting.org/printer_list.cgi">Linuxprinting</ulink> Web site.  Linuxprinting.org has
excellent recommendations about which driver is best used for each printer. Its database is kept current by
the tireless work of Till Kamppeter from Mandrakesoft, who is also the principal author of the
<command>foomatic-rip</command> utility.
</para>

<note><para>
<indexterm><primary>foomatic-rip</primary></indexterm>
<indexterm><primary>cupsomatic</primary></indexterm>
<indexterm><primary>Adobe PPD</primary></indexterm>
The former <command>cupsomatic</command> concept is now being replaced by the new successor, a much more
powerful <command>foomatic-rip</command>.  <command>cupsomatic</command> is no longer maintained. Here is the
new URL to the <ulink noescape="1" url="http://www.linuxprinting.org/driver_list.cgi">Foomatic-3.0</ulink>
database.  If you upgrade to <command>foomatic-rip</command>, remember to also upgrade to the new-style PPDs
for your Foomatic-driven printers. foomatic-rip will not work with PPDs generated for the old
<command>cupsomatic</command>. The new-style PPDs are 100% compliant with the Adobe PPD specification. They
are also intended to be used by Samba and the cupsaddsmb utility, to provide the driver files for the Windows
clients!
</para></note>

<sect2>
<title>foomatic-rip and Foomatic Explained</title>


<para>
<indexterm significance="preferred"><primary>foomatic</primary></indexterm>
<indexterm significance="preferred"><primary>foomatic-rip</primary></indexterm>
Nowadays, most Linux distributions rely on the utilities from the <ulink
url="http://www.linuxprinting.org/">Linuxprinting.org</ulink> to create their printing-related software
(which, by the way, works on all UNIXes and on Mac OS X and Darwin, too).  The utilities from this sire have a
very end-user-friendly interface that allows for an easy update of drivers and PPDs for all supported models,
all spoolers, all operating systems, and all package formats (because there is none). Its history goes back a
few years.
</para>

<para>
Recently, Foomatic has achieved the astonishing milestone of <ulink
url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">1,000 listed</ulink> printer models.
Linuxprinting.org keeps all the important facts about printer drivers, supported models, and which options are
available for the various driver/printer combinations in its <ulink
url="http://www.linuxprinting.org/foomatic.html">Foomatic</ulink> database. Currently there are <ulink
url="http://www.linuxprinting.org/driver_list.cgi">245 drivers</ulink> in the database. Many drivers support
various models, and many models may be driven by different drivers &smbmdash; its your choice!
</para>

<sect3>
<title>690 <quote>Perfect</quote> Printers</title>

<para>
<indexterm><primary>Windows PPD</primary></indexterm>
At present, there are 690 devices dubbed as working perfectly: 181 are <emphasis>mostly</emphasis> perfect, 96
are <emphasis>partially</emphasis> perfect, and 46 are paperweights. Keeping in mind that most of these are
non-PostScript models (PostScript printers are automatically supported by CUPS to perfection by using their
own manufacturer-provided Windows PPD), and that a multifunctional device never qualifies as working perfectly
if it does not also scan and copy and fax under GNU/Linux &smbmdash; then this is a truly astonishing
achievement! Three years ago the number was not more than 500, and Linux or UNIX printing at the time wasn't
anywhere near the quality it is today.
</para>
</sect3>

<sect3>
<title>How the Printing HOWTO Started It All</title>

<para>
A few years ago <ulink url="http://www2.picante.com/">Grant Taylor</ulink> started it all. The
roots of today's Linuxprinting.org are in the first <ulink
url="http://www.linuxprinting.org/foomatic2.9/howto/">Linux Printing HOWTO</ulink> that he authored. As a
side-project to this document, which served many Linux users and admins to guide their first steps in this
complicated and delicate setup (to a scientist, printing is <quote>applying a structured deposition of
distinct patterns of ink or toner particles on paper substrates</quote>), he started to build in a little
Postgres database with information about the hardware and driver zoo that made up Linux printing of the time.
This database became the core component of today's Foomatic collection of tools and data. In the meantime, it
has moved to an XML representation of the data.
</para>
</sect3>

<sect3>
<title>Foomatic's Strange Name</title>


<para>
<indexterm><primary>foomatic</primary></indexterm>
<quote>Why the funny name?</quote> you ask. When it really took off, around spring 2000, CUPS was far less
popular than today, and most systems used LPD, LPRng, or even PDQ to print. CUPS shipped with a few generic
drivers (good for a few hundred different printer models). These didn't support many device-specific options.
CUPS also shipped with its own built-in rasterization filter (<parameter>pstoraster</parameter>, derived from
Ghostscript). On the other hand, CUPS provided brilliant support for <emphasis>controlling</emphasis> all
printer options through standardized and well-defined PPD files.  Plus, CUPS was designed to be easily
extensible.
</para>

<para>
Taylor already had in his database a respectable compilation of facts about many more printers and the
Ghostscript <quote>drivers</quote> they run with. His idea, to generate PPDs from the database information and
use them to make standard Ghostscript filters work within CUPS, proved to work very well. It also killed
several birds with one stone:
</para>

<itemizedlist>
	<listitem><para>It made all current and future Ghostscript filter
	developments available for CUPS.</para></listitem>

	<listitem><para>It made available a lot of additional printer models
	to CUPS users (because often the traditional Ghostscript way of
	printing was the only one available).</para></listitem>

	<listitem><para>It gave all the advanced CUPS options (Web interface,
	GUI driver configurations) to users wanting (or needing) to use
	Ghostscript filters.</para></listitem>
</itemizedlist>
</sect3>

<sect3>
<title>cupsomatic, pdqomatic, lpdomatic, directomatic</title>

<para>
<indexterm><primary>cupsomatic</primary></indexterm>
<indexterm><primary>CUPS-PPD</primary></indexterm>
<indexterm><primary>PPD</primary><secondary>CUPS</secondary><see>CUPS-PPD</see></indexterm>
CUPS worked through a quickly hacked-up filter script named <ulink
url="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&amp;show=0">cupsomatic</ulink>.  cupsomatic
ran the printfile through Ghostscript, constructing automatically the rather complicated command line needed.
It just needed to be copied into the CUPS system to make it work. To configure the way cupsomatic controls the
Ghostscript rendering process, it needs a CUPS-PPD. This PPD is generated directly from the contents of the
database. For CUPS and the respective printer/filter combo, another Perl script named CUPS-O-Matic did the PPD
generation. After that was working, Taylor implemented within a few days a similar thing for two other
spoolers. Names chosen for the config-generator scripts were <ulink
url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&amp;show=0">PDQ-O-Matic</ulink> (for PDQ)
and <ulink url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&amp;show=0">LPD-O-Matic</ulink>
(for &smbmdash; you guessed it &smbmdash; LPD); the configuration here didn't use PPDs but other
spooler-specific files.
</para>

<para>
From late summer of that year, <ulink url="http://www.linuxprinting.org/till/">Till Kamppeter</ulink> started
to put work into the database. Kamppeter had been newly employed by <ulink
url="http://www.mandrakesoft.com/">Mandrakesoft</ulink> to convert its printing system over to CUPS, after
they had seen his <ulink url="http://www.fltk.org/">FLTK</ulink>-based <ulink
url="http://cups.sourceforge.net/xpp/">XPP</ulink> (a GUI front-end to the CUPS lp-command). He added a huge
amount of new information and new printers. He also developed the support for other spoolers, like <ulink
url="http://ppr.sourceforge.net/">PPR</ulink> (via ppromatic), <ulink
url="http://sourceforge.net/projects/lpr/">GNUlpr</ulink>, and <ulink
url="http://www.lprng.org/">LPRng</ulink> (both via an extended lpdomatic) and spooler-less printing (<ulink
url="http://www.linuxprinting.org/download.cgi?filename=directomatic&amp;show=0">directomatic</ulink>).
</para>

<para>
So, to answer your question, <quote>Foomatic</quote> is the general name for all the overlapping code and data
behind the <quote>*omatic</quote> scripts.  Foomatic, up to versions 2.0.x, required (ugly) Perl data
structures attached to Linuxprinting.org PPDs for CUPS. It had a different <quote>*omatic</quote> script for
every spooler, as well as different printer configuration files.
</para>
</sect3>

<sect3>
<title>The <emphasis>Grand Unification</emphasis> Achieved</title>

<para>
<indexterm><primary>foomatic-rip</primary></indexterm>
This has all changed in Foomatic versions 2.9 (beta) and released as <quote>stable</quote> 3.0. It has now
achieved the convergence of all *omatic scripts and is called the <ulink
url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&amp;show=0">foomatic-rip</ulink>.
This single script is the unification of the previously different spooler-specific *omatic scripts.
foomatic-rip is used by all the different spoolers alike, and because it can read PPDs (both the original
PostScript printer PPDs and the Linuxprinting.org-generated ones), all of a sudden all supported spoolers can
have the power of PPDs at their disposal. Users only need to plug foomatic-rip into their system. For users
there is improved media type and source support &smbmdash; paper sizes and trays are easier to configure.
</para>

<para>
<indexterm><primary>PPDs</primary></indexterm>
<indexterm><primary>Foomatic tutorial</primary></indexterm>
<indexterm><primary>LinuxKongress2002</primary></indexterm>
Also, the new generation of Linuxprinting.org PPDs no longer contains Perl data structures. If you are a
distro maintainer and have used the previous version of Foomatic, you may want to give the new one a spin, but
remember to generate a new-version set of PPDs via the new <ulink
url="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz">foomatic-db-engine!</ulink>.
Individual users just need to generate a single new PPD specific to their model by <ulink
url="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html">following
the steps</ulink> outlined in the Foomatic tutorial or in this chapter. This new development is truly amazing.
</para>

<para>
<indexterm><primary>foomatic-rip</primary></indexterm>
<indexterm><primary>Adobe</primary></indexterm>
<indexterm><primary>printer drivers</primary></indexterm>
foomatic-rip is a very clever wrapper around the need to run Ghostscript with a different syntax, options,
device selections, and/or filters for each different printer or spooler. At the same time, it can read the PPD
associated with a print queue and modify the print job according to the user selections. Together with this
comes the 100% compliance of the new Foomatic PPDs with the Adobe spec. Some innovative features of the
Foomatic concept may surprise users. It will support custom paper sizes for many printers and will support
printing on media drawn from different paper trays within the same job (in both cases, even where there is no
support for this from Windows-based vendor printer drivers).
</para>
</sect3>

<sect3>
<title>Driver Development Outside</title>

<para>
<indexterm><primary>Linuxprinting.org</primary></indexterm>
Most driver development itself does not happen within Linuxprinting.org. Drivers are written by independent
maintainers.  Linuxprinting.org just pools all the information and stores it in its database. In addition, it
also provides the Foomatic glue to integrate the many drivers into any modern (or legacy) printing system
known to the world.
</para>

<para>
Speaking of the different driver development groups, most of the work is currently done in three projects:
</para>

<itemizedlist>
	<listitem><para>
<indexterm><primary>Omni</primary></indexterm>
	<ulink url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">Omni</ulink>
	&smbmdash; a free software project by IBM that tries to convert its printer
	driver knowledge from good-ol' OS/2 times into a modern, modular,
	universal driver architecture for Linux/UNIX (still beta). This
	currently supports 437 models.</para></listitem>

	<listitem><para>
<indexterm><primary>HPIJS</primary></indexterm>
	<ulink url="http://hpinkjet.sf.net/">HPIJS</ulink> &smbmdash;
	a free software project by HP to provide the support for its own
	range of models (very mature, printing in most cases is perfect and
	provides true photo quality). This currently supports 369
	models.</para></listitem>

	<listitem><para>
<indexterm><primary>Gimp-Print</primary></indexterm>
	<ulink url="http://gimp-print.sf.net/">Gimp-Print</ulink> &smbmdash; a free software
	effort, started by Michael Sweet (also lead developer for CUPS), now
	directed by Robert Krawitz, which has achieved an amazing level of
	photo print quality (many Epson users swear that its quality is
	better than the vendor drivers provided by Epson for the Microsoft
	platforms). This currently supports 522 models.</para></listitem>
</itemizedlist>
</sect3>

<sect3>
<title>Forums, Downloads, Tutorials, Howtos (Also for Mac OS X and Commercial UNIX)</title>

<para>
Linuxprinting.org today is the one-stop shop to download printer drivers. Look for printer information and
<ulink url="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/">tutorials</ulink> or solve
printing problems in its popular <ulink url="http://www.linuxprinting.org/newsportal/">forums</ulink>. This
forum is not just for GNU/Linux users, but admins of <ulink url="http://www.linuxprinting.org/macosx/">
commercial UNIX systems</ulink> are also going there, and the relatively new
<ulink url="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general">Mac OS X
forum</ulink> has turned out to be one of the most frequented forums after only a few weeks.
</para>

<para>
<indexterm><primary>Mandriva</primary></indexterm>
<indexterm><primary>Mandrake</primary></indexterm>
<indexterm><primary>Conectiva</primary></indexterm>
Linuxprinting.org and the Foomatic driver wrappers around Ghostscript are now a standard tool-chain for
printing on all the important distros. Most of them also have CUPS underneath. While in recent years most
printer data had been added by Kamppeter, many additional contributions came from engineers with SuSE, Red
Hat, Conectiva, Debian, and others. Vendor-neutrality is an important goal of the Foomatic project. Mandrake
and Conectiva have merged and are now called Mandriva.
</para>

<note><para>
Till Kamppeter from Mandrakesoft is doing an excellent job in his spare time to maintain Linuxprinting.org and
Foomatic. So if you use it often, please send him a note showing your appreciation.
</para></note>
</sect3>

<sect3>
<title>Foomatic Database-Generated PPDs</title>

<para>
<indexterm><primary>Foomatic database</primary></indexterm>
<indexterm><primary>XML-based datasets</primary></indexterm>
<indexterm><primary>kprinter</primary></indexterm>
<indexterm><primary>gtklp</primary></indexterm>
<indexterm><primary>xpp</primary></indexterm>
<indexterm><primary>HP Photosmart</primary></indexterm>
<indexterm><primary>Epson Stylus inkjet</primary></indexterm>
<indexterm><primary>non-PostScript printers</primary></indexterm>
<indexterm><primary>raster</primary></indexterm>
The Foomatic database is an amazing piece of ingenuity in itself. Not only does it keep the printer and driver
information, but it is organized in a way that it can generate PPD files on the fly from its internal
XML-based datasets. While these PPDs are modeled to the Adobe specification of PPDs, the
Linuxprinting.org/Foomatic-PPDs do not normally drive PostScript printers. They are used to describe all the
bells and whistles you could ring or blow on an Epson Stylus inkjet, or an HP Photosmart, or what-have-you.
The main trick is one little additional line, not envisaged by the PPD specification, starting with the
<parameter>*cupsFilter</parameter> keyword. It tells the CUPS daemon how to proceed with the PostScript print
file (old-style Foomatic-PPDs named the cupsomatic filter script, while the new-style PPDs are now call
foomatic-rip). This filter script calls Ghostscript on the host system (the recommended variant is ESP
Ghostscript) to do the rendering work. foomatic-rip knows which filter or internal device setting it should
ask from Ghostscript to convert the PostScript print job into a raster format ready for the target device.
This usage of PPDs to describe the options of non-PostScript printers was the invention of the CUPS
developers. The rest is easy.  GUI tools (like KDE's marvelous <ulink
url="http://printing.kde.org/overview/kprinter.phtml">kprinter</ulink> or the GNOME <ulink
url="http://gtklp.sourceforge.net/">gtklp</ulink> xpp and the CUPS Web interface) read the PPD as well and use
this information to present the available settings to the user as an intuitive menu selection.
</para>
</sect3>
</sect2>

<sect2>
<title>foomatic-rip and Foomatic PPD Download and Installation</title>

<para>
Here are the steps to install a foomatic-rip-driven LaserJet 4 Plus-compatible
printer in CUPS (note that recent distributions of SuSE, UnitedLinux and
Mandrake may ship with a complete package of Foomatic-PPDs plus the
<command>foomatic-rip</command> utility. Going directly to
Linuxprinting.org ensures that you get the latest driver/PPD files).
</para>

<itemizedlist>
	<listitem><para>Open your browser at the Linuxprinting.org printer list <ulink url="http://www.linuxprinting.org/printer_list.cgi">page.</ulink>
	</para></listitem>

	<listitem><para>Check the complete list of printers in the 
	<ulink url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">database.</ulink>.
	</para></listitem>

	<listitem><para>Select your model and click on the link.
	</para></listitem>

	<listitem><para>You'll arrive at a page listing all drivers working with this
	model (for all printers, there will always be <emphasis>one</emphasis>
	recommended driver. Try this one first).
	</para></listitem>

	<listitem><para>In our case (HP LaserJet 4 Plus), we'll arrive at the default driver for the
	<ulink url="http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus">HP-LaserJet 4 Plus.</ulink>
	</para></listitem>

	<listitem><para>The recommended driver is ljet4.</para></listitem>

	<listitem><para>Several links are provided here. You should visit them all if you
	are not familiar with the Linuxprinting.org database.
	</para></listitem>

	<listitem><para>There is a link to the database page for the
	<ulink url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">ljet4</ulink>.
	On the driver's page, you'll find important and detailed information
	about how to use that driver within the various available
	spoolers.</para></listitem>

	<listitem><para>Another link may lead you to the home page of the
	author of the driver.</para></listitem>

	<listitem><para>Important links are the ones that provide hints with
	setup instructions for <ulink noescape="1" url="http://www.linuxprinting.org/cups-doc.html">CUPS</ulink>;
	<ulink url="http://www.linuxprinting.org/pdq-doc.html">PDQ</ulink>;
	<ulink url="http://www.linuxprinting.org/lpd-doc.html">LPD, LPRng, and GNUlpr</ulink>);
	as well as <ulink url="http://www.linuxprinting.org/ppr-doc.html">PPR</ulink>
	or <quote>spoolerless</quote> <ulink url="http://www.linuxprinting.org/direct-doc.html">printing</ulink>.
	</para></listitem>

	<listitem><para>You can view the PPD in your browser through this link:
	<ulink noescape="1" url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&amp;printer=HP-LaserJet_4_Plus&amp;show=1">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&amp;printer=HP-LaserJet_4_Plus&amp;show=1</ulink>
	</para></listitem> <listitem><para>Most importantly, you can also generate and download
	the <ulink url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&amp;printer=HP-LaserJet_4_Plus&amp;show=0">PPD</ulink>.
	</para></listitem>

	<listitem><para>The PPD contains all the information needed to use our
	model and the driver; once installed, this works transparently
	for the user. Later you'll only need to choose resolution, paper size,
	and so on, from the Web-based menu, or from the print dialog GUI, or from
	the command line.</para></listitem>

	<listitem><para>If you ended up on the drivers
	<ulink url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">page</ulink>,
	you can choose to use the <quote>PPD-O-Matic</quote> online PPD generator
	program.</para></listitem>

	<listitem><para>Select the exact model and check either <guilabel>Download</guilabel> or
	<guilabel>Display PPD file</guilabel> and click <guilabel>Generate PPD file</guilabel>.</para></listitem>

	<listitem><para>If you save the PPD file from the browser view, please
	do not use cut and paste (since it could possibly damage line endings
	and tabs, which makes the PPD likely to fail its duty), but use <guimenuitem>Save
	as...</guimenuitem> in your browser's menu. (It is best to use the <guilabel>Download</guilabel> option
	directly from the Web page.)</para></listitem>

	<listitem><para>Another interesting part on each driver page is
	the <guimenuitem>Show execution details</guimenuitem> button. If you
	select your printer model and click on that button,
	a complete Ghostscript command line will be displayed, enumerating all options
	available for that combination of driver and printer model. This is a great way to
	<quote>learn Ghostscript by doing</quote>. It is also an excellent cheat sheet
	for all experienced users who need to reconstruct a good command line
	for that darned printing script, but can't remember the exact
	syntax. </para></listitem>

	<listitem><para>Sometime during your visit to Linuxprinting.org, save
	the PPD to a suitable place on your hard disk, say
	<filename>/path/to/my-printer.ppd</filename> (if you prefer to install
	your printers with the help of the CUPS Web interface, save the PPD to
	the <filename>/usr/share/cups/model/</filename> path and restart
	cupsd).</para></listitem>

	<listitem><para>Then install the printer with a suitable command line,
	like this: 
	</para>

	<para><screen>
	&rootprompt;<userinput>lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \
		-P path/to/my-printer.ppd</userinput>
	</screen></para></listitem>

	<listitem><para>For all the new-style <quote>Foomatic-PPDs</quote>
	from Linuxprinting.org, you also need a special CUPS filter named
	foomatic-rip. 
	</para></listitem>

	<listitem><para>The foomatic-rip Perl script itself also makes some
	interesting <ulink url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&amp;show=1">reading</ulink>
	because it is well documented by Kamppeter's in-line comments (even
	non-Perl hackers will learn quite a bit about printing by reading
	it).</para></listitem>

	<listitem><para>Save foomatic-rip either directly in
	<filename>/usr/lib/cups/filter/foomatic-rip</filename> or somewhere in
	your $PATH (and remember to make it world-executable). Again,
	do not save by copy and paste but use the appropriate link or the
	<guimenuitem>Save as...</guimenuitem>  menu item in your browser.</para></listitem>

	<listitem><para>If you save foomatic-rip in your $PATH, create a symlink:
	<screen>
	&rootprompt;<userinput>cd /usr/lib/cups/filter/ ; ln -s `which foomatic-rip'</userinput>
	</screen>
	</para>

	<para>
	CUPS will discover this new available filter at startup after restarting
	cupsd.</para></listitem>
</itemizedlist>

<para>
Once you print to a print queue set up with the Foomatic PPD, CUPS will insert the appropriate commands and
comments into the resulting PostScript job file. foomatic-rip is able to read and act upon these and uses some
specially encoded Foomatic comments embedded in the job file. These in turn are used to construct
(transparently for you, the user) the complicated Ghostscript command line telling the printer driver exactly
how the resulting raster data should look and which printer commands to embed into the data stream. You need:
</para>

<itemizedlist>
	<listitem><para>A <quote>foomatic+something</quote> PPD &smbmdash; but this is not enough
	to print with CUPS (it is only <emphasis>one</emphasis> important
	component).</para></listitem>

	<listitem><para>The <parameter>foomatic-rip</parameter> filter script (Perl) in
	<filename>/usr/lib/cups/filters/</filename>.</para></listitem>

	<listitem><para>Perl to make foomatic-rip run.</para></listitem>

	<listitem><para>Ghostscript (because it is doing the main work,
	controlled by the PPD/foomatic-rip combo) to produce the raster data
	fit for your printer model's consumption.</para></listitem>

	<listitem><para>Ghostscript <emphasis>must</emphasis> (depending on
	the driver/model) contain support for a certain device representing
	the selected driver for your model (as shown by <command>gs -h</command>).</para></listitem>

	<listitem><para>foomatic-rip needs a new version of PPDs (PPD versions
	produced for cupsomatic do not work with foomatic-rip).</para></listitem>
</itemizedlist>
</sect2>
</sect1>

<sect1>
<title>Page Accounting with CUPS</title>


<para>
<indexterm><primary>CUPS</primary><secondary>Page Accounting</secondary></indexterm>
Often there are questions regarding print quotas where Samba users (that is, Windows clients) should not be
able to print beyond a certain number of pages or data volume per day, week, or month. This feature is
dependent on the real print subsystem you're using.  Samba's part is always to receive the job files from the
clients (filtered <emphasis>or</emphasis> unfiltered) and hand them over to this printing subsystem.
</para>

<para>
Of course one could hack things with one's own scripts. But then there is CUPS. CUPS supports quotas that can
be based on the size of jobs or on the number of pages or both, and can span any time period you want.
</para>

<sect2>
<title>Setting Up Quotas</title>

<para>
<indexterm><primary>CUPS</primary><secondary>quotas</secondary></indexterm>
This is an example command of how root would set a print quota in CUPS, assuming an existing printer named
<quote>quotaprinter</quote>:
<indexterm><primary>lpadmin</primary></indexterm>
<screen>
&rootprompt;<userinput>lpadmin -p quotaprinter -o job-quota-period=604800 \
	-o job-k-limit=1024 -o job-page-limit=100</userinput>
</screen></para>

<para>
This would limit every single user to print no more than 100 pages or 1024 KB of
data (whichever comes first) within the last 604,800 seconds ( = 1 week).
</para>
</sect2>

<sect2>
<title>Correct and Incorrect Accounting</title>

<para>
For CUPS to count correctly, the printfile needs to pass the CUPS pstops filter; otherwise it uses a dummy
count of <quote>one</quote>. Some print files do not pass it (e.g., image files), but then those are mostly
one-page jobs anyway. This also means that proprietary drivers for the target printer running on the client
computers and CUPS/Samba, which then spool these files as <quote>raw</quote> (i.e., leaving them untouched,
not filtering them), will be counted as one-pagers too!
</para>

<para>
You need to send PostScript from the clients (i.e., run a PostScript driver there) to have the chance to get
accounting done. If the printer is a non-PostScript model, you need to let CUPS do the job to convert the file
to a print-ready format for the target printer. This is currently working for about a thousand different
printer models.  Linuxprinting.org has a driver <ulink url="http://www.linuxprinting.org/printer_list.cgi">list</ulink>.
</para>
</sect2>

<sect2>
<title>Adobe and CUPS PostScript Drivers for Windows Clients</title>

<para>
<indexterm><primary>Adobe PostScript</primary></indexterm>
<indexterm><primary>pstops</primary></indexterm>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>pstoraster</primary></indexterm>
<indexterm><primary>PJL-header</primary></indexterm>
Before CUPS 1.1.16, your only option was to use the Adobe PostScript driver on the Windows clients. The output
of this driver was not always passed through the <command>pstops</command> filter on the CUPS/Samba side, and
therefore was not counted correctly (the reason is that it often, depending on the PPD being used, wrote a
PJL-header in front of the real PostScript, which caused CUPS to skip <command>pstops</command> and go
directly to the <command>pstoraster</command> stage).
</para>

<para>
From CUPS 1.1.16 and later releases, you can use the CUPS PostScript driver for Windows NT/200x/XP
clients (which is tagged in the download area of <filename>http://www.cups.org/</filename> as the
<filename>cups-samba-1.1.16.tar.gz</filename> package). It does <emphasis>not</emphasis> work for Windows
9x/Me clients, but it guarantees:
</para>

<itemizedlist>
	<listitem><para> <indexterm><primary>PJL</primary></indexterm> To not write a PJL-header.</para></listitem>

	<listitem><para>To still read and support all PJL-options named in the
	driver PPD with its own means.</para></listitem>

	<listitem><para>That the file will pass through the <command>pstops</command> filter
	on the CUPS/Samba server.</para></listitem>

	<listitem><para>To page-count correctly the print file.</para></listitem>
</itemizedlist>

<para>
You can read more about the setup of this combination in the man page for <command>cupsaddsmb</command> (which
is only present with CUPS installed, and only current from CUPS 1.1.16).
</para>
</sect2>

<sect2>
<title>The page_log File Syntax</title>

<para>
<indexterm><primary>page_log</primary></indexterm>
These are the items CUPS logs in the <filename>page_log</filename> for every page of a job:
</para>

<itemizedlist>
	<listitem><para>Printer name</para></listitem>

	<listitem><para>User name</para></listitem>

	<listitem><para>Job ID</para></listitem>

	<listitem><para>Time of printing</para></listitem>

	<listitem><para>Page number</para></listitem>

	<listitem><para>Number of copies</para></listitem>

	<listitem><para>A billing information string (optional)</para></listitem>

	<listitem><para>The host that sent the job (included since version 1.1.19)</para></listitem>
</itemizedlist>

<para>
Here is an extract of my CUPS server's <filename>page_log</filename> file to illustrate the
format and included items:
</para>

<para><screen>
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33
</screen></para>

<para>
This was job ID <parameter>401</parameter>, printed on <parameter>tec_IS2027</parameter>
by user <parameter>kurt</parameter>, a 64-page job printed in three copies, billed to
<parameter>#marketing</parameter>, and sent from IP address <constant>10.160.50.13.</constant>
 The next job had ID <parameter>402</parameter>, was sent by user <parameter>boss</parameter>
from IP address <constant>10.160.51.33</constant>, printed from one page 440 copies, and
is set to be billed to <parameter>finance-dep</parameter>.
</para>
</sect2>

<sect2>
<title>Possible Shortcomings</title>

<para>
What flaws or shortcomings are there with this quota system?
</para>

<itemizedlist>
	<listitem><para>The ones named above (wrongly logged job in case of
	printer hardware failure, and so on).</para></listitem>

	<listitem><para>In reality, CUPS counts the job pages that are being
	processed in <emphasis>software</emphasis> (that is, going through the
	RIP) rather than the physical sheets successfully leaving the
	printing device. Thus, if there is a jam while printing the fifth sheet out
	of 1,000 and the job is aborted by the printer, the page count will
	still show the figure of 1,000 for that job.</para></listitem>

	<listitem><para>All quotas are the same for all users (no flexibility
	to give the boss a higher quota than the clerk) and no support for
	groups.</para></listitem>

	<listitem><para>No means to read out the current balance or the
	<quote>used-up</quote> number of current quota.</para></listitem>

	<listitem><para>A user having used up 99 sheets of a 100 quota will
	still be able to send and print a 1,000 sheet job.</para></listitem>

	<listitem><para>A user being denied a job because of a filled-up quota
	does not get a meaningful error message from CUPS other than
	<quote>client-error-not-possible</quote>.</para></listitem>
</itemizedlist>
</sect2>

<sect2>
<title>Future Developments</title>

<para>
This is the best system currently available, and there are huge
improvements under development for CUPS 1.2:
</para>

<itemizedlist>
	<listitem><para>Page counting will go into the backends (these talk
	directly to the printer and will increase the count in sync with the
	actual printing process; thus, a jam at the fifth sheet will lead to a
	stop in the counting).</para></listitem>

	<listitem><para>Quotas will be handled more flexibly.</para></listitem>

	<listitem><para>Probably there will be support for users to inquire
	about their accounts in advance.</para></listitem>

	<listitem><para>Probably there will be support for some other tools
	around this topic.</para></listitem>
</itemizedlist>
</sect2>

<sect2>
<title>Other Accounting Tools</title>

<para>
Other accounting tools that can be used includes: PrintAnalyzer, pyKota, printbill, LogReport.
For more information regarding these tools you can try a Google search.
</para>

</sect2>
</sect1>

<sect1>
<title>Additional Material</title>

<para>
A printer queue with <emphasis>no</emphasis> PPD associated to it is a
<quote>raw</quote> printer, and all files will go directly there as received by the
spooler. The exceptions are file types <parameter>application/octet-stream</parameter>
that need the pass-through feature enabled. <quote>Raw</quote> queues do not do any
filtering at all; they hand the file directly to the CUPS backend.
This backend is responsible for sending the data to the device
(as in the <quote>device URI</quote> notation: <filename>lpd://, socket://,
smb://, ipp://, http://, parallel:/, serial:/, usb:/</filename>, and so on).
</para>

<para>
cupsomatic/Foomatic are <emphasis>not</emphasis> native CUPS drivers
and they do not ship with CUPS. They are a third-party add-on
developed at Linuxprinting.org. As such, they are a brilliant hack to
make all models (driven by Ghostscript drivers/filters in traditional
spoolers) also work via CUPS, with the same (good or bad!) quality as
in these other spoolers. <parameter>cupsomatic</parameter> is only a vehicle to execute a
Ghostscript command line at that stage in the CUPS filtering chain
where normally the native CUPS <parameter>pstoraster</parameter> filter would kick
in. <parameter>cupsomatic</parameter> bypasses <parameter>pstoraster</parameter>, kidnaps the print file from CUPS,
and redirects it to go through Ghostscript. CUPS accepts this
because the associated cupsomatic/foomatic-PPD specifies:

<programlisting>
*cupsFilter:  "application/vnd.cups-postscript 0 cupsomatic"
</programlisting>

This line persuades CUPS to hand the file to <parameter>cupsomatic</parameter> once it has
successfully converted it to the MIME type
<parameter>application/vnd.cups-postscript</parameter>. This conversion will not happen for
jobs arriving from Windows that are autotyped
<parameter>application/octet-stream</parameter>, with the according changes in
<filename>/etc/cups/mime.types</filename> in place.
</para>

<para>
CUPS is widely configurable and flexible, even regarding its filtering
mechanism. Another workaround in some situations would be to have in
<filename>/etc/cups/mime.types</filename> entries as follows:

<programlisting>
application/postscript           application/vnd.cups-raw  0  -
application/vnd.cups-postscript  application/vnd.cups-raw  0  -
</programlisting>

This would prevent all PostScript files from being filtered (rather,
they will through the virtual <emphasis>nullfilter</emphasis>
denoted with <quote>-</quote>). This could only be useful for PostScript printers. If you
want to print PostScript code on non-PostScript printers (provided they support ASCII
text printing), an entry as follows could be useful:

<programlisting>
*/*           application/vnd.cups-raw  0  -
</programlisting>

and would effectively send <emphasis>all</emphasis> files to the
backend without further processing.
</para>

<para>
You could have the following entry:

<programlisting>
application/vnd.cups-postscript application/vnd.cups-raw 0 \
	my_PJL_stripping_filter
</programlisting>

You will need to write a <parameter>my_PJL_stripping_filter</parameter>
(which could be a shell script) that parses the PostScript and removes the
unwanted PJL. This needs to conform to CUPS filter design
(mainly, receive and pass the parameters printername, job-id,
username, jobtitle, copies, print options, and possibly the
filename). It is installed as world executable into
<filename>/usr/lib/cups/filters/</filename> and is called by CUPS
if it encounters a MIME type <parameter>application/vnd.cups-postscript</parameter>.
</para>

<para>
CUPS can handle <parameter>-o job-hold-until=indefinite</parameter>.
This keeps the job in the queue on hold. It will only be printed
upon manual release by the printer operator. This is a requirement in
many central reproduction departments, where a few operators manage
the jobs of hundreds of users on some big machine, where no user is
allowed to have direct access (such as when the operators often need
to load the proper paper type before running the 10,000 page job
requested by marketing for the mailing, and so on).
</para>
</sect1>

<sect1>
<title>Autodeletion or Preservation of CUPS Spool Files</title>

<para>
<indexterm><primary>/var/spool/samba</primary></indexterm>
<indexterm><primary>/var/spool/cups/</primary></indexterm>
<indexterm><primary>cupsd.conf</primary></indexterm>
Samba print files pass through two spool directories. One is the incoming directory managed by Samba (set in
the <smbconfoption name="path">/var/spool/samba</smbconfoption> directive in the <smbconfsection
name="[printers]"/> section of &smb.conf;). The other is the spool directory of your UNIX print subsystem. For
CUPS it is normally <filename>/var/spool/cups/</filename>, as set by the <filename>cupsd.conf</filename>
directive <filename>RequestRoot /var/spool/cups</filename>.
</para>

<sect2>
<title>CUPS Configuration Settings Explained</title>

<para>
Some important parameter settings in the CUPS configuration file
<filename>cupsd.conf</filename> are:
</para>

<variablelist>

	<varlistentry><term>PreserveJobHistory Yes</term>
	<listitem><para>
	This keeps some details of jobs in cupsd's mind (well, it keeps the
	c12345, c12346, and so on, files in the CUPS spool directory, which does a
	similar job as the old-fashioned BSD-LPD control files). This is set
	to <quote>Yes</quote> as a default.
	</para></listitem></varlistentry>

	<varlistentry><term>PreserveJobFiles Yes</term>
	<listitem><para>
	This keeps the job files themselves in cupsd's mind
	(it keeps the d12345, d12346, etc., files in the CUPS spool
	directory). This is set to <quote>No</quote> as the CUPS
	default.
	</para></listitem></varlistentry>

	<varlistentry><term><quote>MaxJobs 500</quote></term>
	<listitem><para>
	This directive controls the maximum number of jobs
	that are kept in memory. Once the number of jobs reaches the limit,
	the oldest completed job is automatically purged from the system to
	make room for the new one. If all of the known jobs are still
	pending or active, then the new job will be rejected. Setting the
	maximum to 0 disables this functionality. The default setting is
	0.
	</para></listitem></varlistentry>
</variablelist>

<para>
(There are also additional settings for <parameter>MaxJobsPerUser</parameter> and
<parameter>MaxJobsPerPrinter</parameter>.)
</para>
</sect2>

<sect2>
<title>Preconditions</title>

<para>
For everything to work as it should, you need to have three things:
</para>

<itemizedlist>
	<listitem><para>A Samba smbd that is compiled against <filename>libcups</filename> (check
	on Linux by running <userinput>ldd `which smbd'</userinput>).</para></listitem>

	<listitem><para>A Samba-&smb.conf; setting of
			<smbconfoption name="printing">cups</smbconfoption>.</para></listitem>

	<listitem><para>Another Samba &smb.conf; setting of
			<smbconfoption name="printcap">cups</smbconfoption>.</para></listitem>
</itemizedlist>

<note><para>
In this case, all other manually set printing-related commands (like
<smbconfoption name="print command"/>, 
<smbconfoption name="lpq command"/>, 
<smbconfoption name="lprm command"/>, 
<smbconfoption name="lppause command"/>, and
<smbconfoption name="lpresume command"/>) are ignored, and they should normally have no
influence whatsoever on your printing.
</para></note>
</sect2>

<sect2>
<title>Manual Configuration</title>

<para>
If you want to do things manually, replace the <smbconfoption name="printing">cups</smbconfoption>
by <smbconfoption name="printing">bsd</smbconfoption>. Then your manually set commands may work
(I haven't tested this), and a <smbconfoption name="print command">lp -d %P %s; rm %s</smbconfoption>
may do what you need.
</para>
</sect2>
</sect1>

<sect1>
<title>Printing from CUPS to Windows-Attached Printers</title>

<para>
<indexterm><primary>smbspool</primary></indexterm>
<indexterm><primary>backends</primary></indexterm>
From time to time the question arises, how can you print <emphasis>to</emphasis> a Windows-attached printer
<emphasis>from</emphasis> Samba? Normally the local connection from Windows host to printer would be done by
USB or parallel cable, but this does not matter to Samba. From here only an SMB connection needs to be opened
to the Windows host. Of course, this printer must be shared first. As you have learned by now, CUPS uses
<emphasis>backends</emphasis> to talk to printers and other servers. To talk to Windows shared printers, you
need to use the <filename>smb</filename> (surprise, surprise!) backend. Check if this is in the CUPS backend
directory. This usually resides in <filename>/usr/lib/cups/backend/</filename>. You need to find an
<filename>smb</filename> file there. It should be a symlink to <filename>smbspool</filename>, and the file
must exist and be executable:
<screen>
&rootprompt;<userinput>ls -l /usr/lib/cups/backend/</userinput>
total 253
drwxr-xr-x    3 root   root     720 Apr 30 19:04 .
drwxr-xr-x    6 root   root     125 Dec 19 17:13 ..
-rwxr-xr-x    1 root   root   10692 Feb 16 21:29 canon
-rwxr-xr-x    1 root   root   10692 Feb 16 21:29 epson
lrwxrwxrwx    1 root   root       3 Apr 17 22:50 http -&gt; ipp
-rwxr-xr-x    1 root   root   17316 Apr 17 22:50 ipp
-rwxr-xr-x    1 root   root   15420 Apr 20 17:01 lpd
-rwxr-xr-x    1 root   root    8656 Apr 20 17:01 parallel
-rwxr-xr-x    1 root   root    2162 Mar 31 23:15 pdfdistiller
lrwxrwxrwx    1 root   root      25 Apr 30 19:04 ptal -&gt; /usr/sbin/ptal-cups
-rwxr-xr-x    1 root   root    6284 Apr 20 17:01 scsi
lrwxrwxrwx    1 root   root      17 Apr  2 03:11 smb -&gt; /usr/bin/smbspool
-rwxr-xr-x    1 root   root    7912 Apr 20 17:01 socket
-rwxr-xr-x    1 root   root    9012 Apr 20 17:01 usb

&rootprompt;<userinput>ls -l `which smbspool`</userinput>
-rwxr-xr-x    1 root   root  563245 Dec 28 14:49 /usr/bin/smbspool
</screen></para>

<para>
If this symlink does not exist, create it:
<screen>
&rootprompt;<userinput>ln -s `which smbspool` /usr/lib/cups/backend/smb</userinput>
</screen></para>

<para>
<indexterm><primary>smbspool</primary></indexterm>
<indexterm><primary>troubleshooting</primary></indexterm>
<command>smbspool</command> was written by Mike Sweet from the CUPS folks. It is included and ships with
Samba. It may also be used with print subsystems other than CUPS, to spool jobs to Windows printer shares. To
set up printer <replaceable>winprinter</replaceable> on CUPS, you need to have a driver for it. Essentially
this means to convert the print data on the CUPS/Samba host to a format that the printer can digest (the
Windows host is unable to convert any files you may send). This also means you should be able to print to the
printer if it were hooked directly at your Samba/CUPS host. For troubleshooting purposes, this is what you
should do to determine if that part of the process chain is in order. Then proceed to fix the network
connection/authentication to the Windows host, and so on.
</para>

<para>
To install a printer with the <parameter>smb</parameter> backend on CUPS, use this command:
</para>

<para><screen>
&rootprompt;<userinput>lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename \
  -P /path/to/PPD</userinput>
</screen></para>

<para>
<indexterm><primary>PostScript printers</primary></indexterm>
<indexterm><primary>PPD</primary></indexterm>
<indexterm><primary>Windows NT PostScript driver</primary></indexterm>
The PPD must be able to direct CUPS to generate the print data for the target model. For PostScript printers,
just use the PPD that would be used with the Windows NT PostScript driver. But what can you do if the printer
is only accessible with a password? Or if the printer's host is part of another workgroup? This is provided
for: You can include the required parameters as part of the <filename>smb://</filename> device-URI like this:
</para>

<itemizedlist>
	<listitem><para><filename>smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename</filename></para></listitem>
	<listitem><para><filename>smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename</filename></para></listitem>
	<listitem><para><filename>smb://username:password@WINDOWSNETBIOSNAME/printersharename</filename></para></listitem>
</itemizedlist>

<para>
Note that the device URI will be visible in the process list of the Samba server (e.g., when someone uses the
<command>ps -aux</command> command on Linux), even if the username and passwords are sanitized before they get
written into the log files. This is an inherently insecure option; however, it is the only one. Don't use it
if you want to protect your passwords. Better share the printer in a way that does not require a password!
Printing will only work if you have a working NetBIOS name resolution up and running. Note that this is a
feature of CUPS and you do not necessarily need to have smbd running.

</para>
</sect1>

<sect1>
<title>More CUPS Filtering Chains</title>

<para>
The diagrams in <link linkend="cups1">Filtering Chain 1</link> and <link linkend="cups2">Filtering Chain with
cupsomatic</link> show how CUPS handles print jobs.
</para>

<figure id="cups1">
	<title>Filtering Chain 1.</title>
	<imagefile>cups1</imagefile>
</figure>

<!-- JJJ -->
<figure id="cups2">
	<title>Filtering Chain with cupsomatic</title>
	<imagefile scale="45">cups2</imagefile>
</figure>

</sect1>

<sect1>
<title>Common Errors</title>

	<sect2>
	<title>Windows 9x/Me Client Can't Install Driver</title>

	<para>For Windows 9x/Me, clients require the printer names to be eight
	characters (or <quote>8 plus 3 chars suffix</quote>) max; otherwise, the driver files
	will not get transferred when you want to download them from Samba.</para>

	</sect2>

	<sect2 id="root-ask-loop">
	<title><quote>cupsaddsmb</quote> Keeps Asking for Root Password in Never-ending Loop</title>

	<para>Have you set <smbconfoption name="security">user</smbconfoption>? Have
	you used <command>smbpasswd</command> to give root a Samba account?
	You can do two things: open another terminal and execute
	<command>smbpasswd -a root</command> to create the account and
	continue entering the password into the first terminal. Or, break
	out of the loop by pressing Enter twice (without trying to type a
	password).</para>

	<para>
	If the error is <quote>Tree connect failed: NT_STATUS_BAD_NETWORK_NAME</quote>, 
	you may have forgotten to create the <filename>/etc/samba/drivers</filename> directory.
	</para>
	</sect2>

	<sect2>
	<title><quote>cupsaddsmb</quote> or <quote>rpcclient addriver</quote> Emit Error</title>

	<para>
	If <command>cupsaddsmb</command>, or <command>rpcclient addriver</command> emit the error message
	WERR_BAD_PASSWORD, refer to <link linkend="root-ask-loop">the previous common error</link>.
	</para>
	
	</sect2>

	<sect2>
	<title><quote>cupsaddsmb</quote> Errors</title>

	<para>
	The use of <quote>cupsaddsmb</quote> gives <quote>No PPD file for printer...</quote> 
	message while PPD file is present.  What might the problem be?
	</para>

	<para>
	Have you enabled printer sharing on CUPS? This means, do you have a <literal>&lt;Location
	/printers&gt;....&lt;/Location&gt;</literal> section in CUPS server's <filename>cupsd.conf</filename> that
	does not deny access to the host you run <quote>cupsaddsmb</quote> from?  It <emphasis>could</emphasis> be an
	issue if you use cupsaddsmb remotely, or if you use it with a <option>-h</option> parameter:
	<userinput>cupsaddsmb -H sambaserver -h cupsserver -v printername</userinput>.
	</para>

	<para>Is your <parameter>TempDir</parameter> directive in
	<filename>cupsd.conf</filename> set to a valid value, and is it writable?
	</para>

	</sect2>

	<sect2>
		<title>Client Can't Connect to Samba Printer</title>

	<para>Use <command>smbstatus</command> to check which user
	you are from Samba's point of view. Do you have the privileges to
	write into the <smbconfsection name="[print$]"/>
	share?</para>

	</sect2>

	<sect2>
	<title>New Account Reconnection from Windows 200x/XP Troubles</title>

<para>
Once you are connected as the wrong user (for example, as <constant>nobody</constant>, which often occurs if
you have <smbconfoption name="map to guest">bad user</smbconfoption>), Windows Explorer will not accept an
attempt to connect again as a different user. There will not be any bytes transferred on the wire to Samba,
but still you'll see a stupid error message that makes you think Samba has denied access. Use
<command>smbstatus</command> to check for active connections. Kill the PIDs. You still can't re-connect, and
you get the dreaded <computeroutput>You can't connect with a second account from the same
machine</computeroutput> message as soon as you try. And you do not see a single byte arriving at Samba (see
logs; use <quote>ethereal</quote>) indicating a renewed connection attempt. Shut all Explorer Windows.  This
makes Windows forget what it has cached in its memory as established connections. Then reconnect as the right
user. The best method is to use a DOS terminal window and <emphasis>first</emphasis> do <userinput>net use z:
\\&example.server.samba;\print$ /user:root</userinput>. Check with <command>smbstatus</command> that you are
connected under a different account. Now open the <guilabel>Printers</guilabel> folder (on the Samba server in
the <guilabel>Network Neighborhood</guilabel>), right-click on the printer in question, and select
<guibutton>Connect....</guibutton>.
</para>
</sect2>

<sect2>
<title>Avoid Being Connected to the Samba Server as the Wrong User</title>
	
<para>
<indexterm><primary>smbstatus</primary></indexterm>
You see per <command>smbstatus</command> that you are connected as user nobody, but you want to be root or
printer admin. This is probably due to <smbconfoption name="map to guest">bad user</smbconfoption>, which
silently connected you under the guest account when you gave (maybe by accident) an incorrect username. Remove
<smbconfoption name="map to guest"/> if you want to prevent this.
</para>
</sect2>

<sect2>
<title>Upgrading to CUPS Drivers from Adobe Drivers</title>

<para>
This information came from a mailing list posting regarding problems experienced when
upgrading from Adobe drivers to CUPS drivers on Microsoft Windows NT/200x/XP clients.
</para>

<para>First delete all old Adobe-using printers. Then delete all old Adobe drivers. (On Windows 200x/XP, right-click in
the background of <guilabel>Printers</guilabel> folder, select <guimenuitem>Server Properties...</guimenuitem>, select
tab <guilabel>Drivers</guilabel>, and delete here).</para>
</sect2>

<sect2>
<title>Can't Use <quote>cupsaddsmb</quote> on Samba Server, Which Is a PDC</title>

<para>Do you use the <quote>naked</quote> root user name? Try to do it
this way: <userinput>cupsaddsmb -U <replaceable>DOMAINNAME</replaceable>\\root -v
<replaceable>printername</replaceable></userinput>> (note the two backslashes: the first one is
required to <quote>escape</quote> the second one).</para>

</sect2>

<sect2>
<title>Deleted Windows 200x Printer Driver Is Still Shown</title>

<para>Deleting a printer on the client will not delete the
driver too (to verify, right-click on the white background of the
<guilabel>Printers</guilabel> folder, select <guimenuitem>Server Properties</guimenuitem> and click on the
<guilabel>Drivers</guilabel> tab). These same old drivers will be re-used when you try to
install a printer with the same name. If you want to update to a new
driver, delete the old ones first. Deletion is only possible if no
other printer uses the same driver.</para>
</sect2>

<sect2>
<title>Windows 200x/XP Local Security Policies</title>

<indexterm><primary>Local security policies</primary></indexterm>
<indexterm><primary>unsigned drivers</primary></indexterm>
<para>Local security policies may not allow the installation of unsigned drivers &smbmdash; <quote>local
security policies</quote> may not allow the installation of printer drivers at all.</para>

</sect2>

<sect2>
<title>Administrator Cannot Install Printers for All Local Users</title>

<para>
<indexterm><primary>SMB printers</primary></indexterm>
<indexterm><primary>IPP client</primary></indexterm>
Windows XP handles SMB printers on a <quote>per-user</quote> basis.
This means every user needs to install the printer himself or herself. To have a printer available for
everybody, you might want to use the built-in IPP client capabilities of Win XP. Add a printer with the print
path of <parameter>http://cupsserver:631/printers/printername</parameter>.  We're still looking into this one.
Maybe a logon script could automatically install printers for all users.
</para>

</sect2>

<sect2>
<title>Print Change, Notify Functions on NT Clients</title>

<para>For print change, notify functions on NT++ clients.  These need to run the <command>Server</command>
service first (renamed to <command>File &amp; Print Sharing for MS Networks</command> in XP).</para>

</sect2>

<sect2>
<title>Win XP-SP1</title>

<para>Win XP-SP1 introduced a Point and Print Restriction Policy (this restriction does not apply to
<quote>Administrator</quote> or <quote>Power User</quote> groups of users). In Group Policy Object Editor, go
to <guimenu>User Configuration -> Administrative Templates -> Control Panel -> Printers</guimenu>. The policy
is automatically set to <constant>Enabled</constant> and the <constant>Users can only Point and Print to
machines in their Forest</constant> . You probably need to change it to <constant>Disabled</constant> or
<constant>Users can only Point and Print to these servers</constant> to make driver downloads from Samba
possible.
</para>
</sect2>

<sect2>
<title>Print Options for All Users Can't Be Set on Windows 200x/XP</title>

<para>How are you doing it? I bet the wrong way (it is not easy to find out, though). There are three
different ways to bring you to a dialog that <emphasis>seems</emphasis> to set everything. All three dialogs
<emphasis>look</emphasis> the same, yet only one of them does what you intend. You need to be Administrator or
Print Administrator to do this for all users. Here is how I do in on XP:
</para>

<orderedlist numeration="upperalpha">

	<listitem><para>The first wrong way:

		<orderedlist>
		<listitem><para>Open the <guilabel>Printers</guilabel>
		folder.</para></listitem>

		<listitem><para>Right-click on the printer
		(<guilabel>remoteprinter on cupshost</guilabel>) and
		select in context menu <guimenuitem>Printing
		Preferences...</guimenuitem></para></listitem>.

		<listitem><para>Look at this dialog closely and remember what it looks like.</para></listitem>
		</orderedlist>
	</para></listitem>

	<listitem><para>The second wrong way:
	<orderedlist>
		<listitem><para>Open the <guilabel>Printers</guilabel> folder.</para></listitem>

		<listitem><para>Right-click on the printer (<guilabel>remoteprinter on
		cupshost</guilabel>) and select the context menu
		<guimenuitem>Properties</guimenuitem>.</para></listitem>

		<listitem><para>Click on the <guilabel>General</guilabel> tab.</para></listitem>

		<listitem><para>Click on the button <guibutton>Printing
		Preferences...</guibutton></para></listitem>.

		<listitem><para>A new dialog opens. Keep this dialog open and go back
		to the parent dialog.</para></listitem>
	</orderedlist>
	</para></listitem>

	<listitem><para>The third and correct way: 
	<orderedlist>
		<listitem><para>Open the <guilabel>Printers</guilabel> folder.</para></listitem>

		<listitem><para>Right-click on the printer (<guilabel>remoteprinter on
		cupshost</guilabel>) and select the context menu
		<guimenuitem>Properties</guimenuitem>.</para></listitem>

		<listitem><para>Click on the <guilabel>Advanced</guilabel>
		tab. (If everything is <quote>grayed out,</quote> then you are not logged
		in as a user with enough privileges).</para></listitem>

		<listitem><para>Click on the <guibutton>Printing
		Defaults...</guibutton> button.</para></listitem>

		<listitem><para>On any of the two new tabs, click on the
		<guibutton>Advanced...</guibutton> button.</para></listitem>

		<listitem><para>A new dialog opens. Compare this one to the other
		identical-looking one from step <quote>B.5</quote> or A.3".</para></listitem>
	</orderedlist>
	</para></listitem>
</orderedlist>

<para>
Do you see any difference? I don't either. However, only the last one, which you arrived at with steps
<quote>C.1. to C.6.</quote>, will save any settings permanently and be the defaults for new users. If you want
all clients to get the same defaults, you need to conduct these steps <emphasis>as Administrator</emphasis>
(<smbconfoption name="printer admin"/> in &smb.conf;) <emphasis>before</emphasis> a client downloads the
driver (the clients can later set their own <emphasis>per-user defaults</emphasis> by following the procedures
<emphasis>A</emphasis> or <emphasis>B</emphasis>).
</para>

</sect2>

<sect2>
<title>Most Common Blunders in Driver Settings on Windows Clients</title>

<para>
Don't use <parameter>Optimize for Speed</parameter>, but use <parameter>Optimize for Portability</parameter>
instead (Adobe PS Driver). Don't use <parameter>Page Independence: No</parameter>. Always settle with
<parameter>Page Independence: Yes</parameter> (Microsoft PS Driver and CUPS PS Driver for Windows NT/200x/XP).
If there are problems with fonts, use <parameter>Download as Softfont into printer</parameter> (Adobe PS
Driver). For <guilabel>TrueType Download Options</guilabel> choose <constant>Outline</constant>. Use
PostScript Level 2 if you are having trouble with a non-PS printer and if there is a choice.
</para>

</sect2>

<sect2>
<title><command>cupsaddsmb</command> Does Not Work with Newly Installed Printer</title>

<para>
Symptom: The last command of <command>cupsaddsmb</command> does not complete successfully. If the <command>cmd
= setdriver printername printername</command> result was NT_STATUS_UNSUCCESSFUL, then possibly the printer was
not yet recognized by Samba. Did it show up in Network Neighborhood? Did it show up in <command>rpcclient
hostname -c `enumprinters'</command>? Restart smbd (or send a <command>kill -HUP</command> to all processes
listed by <command>smbstatus</command>, and try again.
</para></sect2>

<sect2>
<title>Permissions on <filename>/var/spool/samba/</filename> Get Reset After Each Reboot</title>

<para>
Have you ever by accident set the CUPS spool directory to the same location (<parameter>RequestRoot
/var/spool/samba/</parameter> in <filename>cupsd.conf</filename> or the other way round:
<filename>/var/spool/cups/</filename> is set as <smbconfoption name="path"/>> in the <smbconfsection
name="[printers]"/> section)? These <parameter>must</parameter> be different. Set <parameter>RequestRoot
/var/spool/cups/</parameter> in <filename>cupsd.conf</filename> and <smbconfoption name="path">
/var/spool/samba</smbconfoption> in the <smbconfsection name="[printers]"/> section of &smb.conf;. Otherwise,
cupsd will sanitize permissions to its spool directory with each restart and printing will not work reliably.
</para>

</sect2>

<sect2>
<title>Print Queue Called <quote>lp</quote> Mishandles Print Jobs</title>

<para>
In this case a print queue called <quote>lp</quote> intermittently swallows jobs and
spits out completely different ones from what was sent.
</para>

<para>
<indexterm><primary>lp</primary></indexterm>
<indexterm><primary>Implicit Classes</primary></indexterm>
<indexterm><primary>BrowseShortNames</primary></indexterm>
It is a bad idea to name any printer <quote>lp</quote>. This is the traditional UNIX name for the default
printer. CUPS may be set up to do an automatic creation of Implicit Classes. This means, to group all printers
with the same name to a pool of devices and load-balance the jobs across them in a round-robin fashion.
Chances are high that someone else has a printer named <quote>lp</quote> too. You may receive that person's
jobs and send your own to his or her device unwittingly. To have tight control over the printer names, set
<parameter>BrowseShortNames No</parameter>. It will present any printer as
<replaceable>printername@cupshost</replaceable>, which gives you better control over what may happen in a
large networked environment.
</para>

</sect2>

<sect2>
<title>Location of Adobe PostScript Driver Files for <quote>cupsaddsmb</quote></title>

<para>
Use <command>smbclient</command> to connect to any Windows box with a shared PostScript printer:
<command>smbclient //windowsbox/print\$ -U guest</command>. You can navigate to the
<filename>W32X86/2</filename> subdir to <command>mget ADOBE*</command> and other files or to
<filename>WIN40/0</filename> to do the same.  Another option is to download the <filename>*.exe</filename>
packaged files from the Adobe Web site.
</para>

</sect2>

</sect1>

<sect1>
<title>Overview of the CUPS Printing Processes</title>

<para>
A complete overview of the CUPS printing processes can be found in <link linkend="a_small">the CUPS
Printing Overview diagram</link>.
</para>

<figure id="a_small">
	<title>CUPS Printing Overview.</title>
	<imagefile scale="45">a_small</imagefile>
</figure>
</sect1>

</chapter>