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
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 19. CUPS Printing Support in Samba 3.0</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="printing.html" title="Chapter 18. Classical Printing Support"><link rel="next" href="VFS.html" title="Chapter 20. Stackable VFS modules"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 19. CUPS Printing Support in Samba 3.0</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="printing.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="VFS.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="CUPS-printing"></a>Chapter 19. CUPS Printing Support in Samba 3.0</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Kurt</span> <span class="surname">Pfeifle</span></h3><div class="affiliation"><span class="orgname"> Danka Deutschland GmbH <br></span><div class="address"><p><tt class="email"><<a href="mailto:kpfeifle@danka.de">kpfeifle@danka.de</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Ciprian</span> <span class="surname">Vizitiu</span></h3><span class="contrib">drawings</span><div class="affiliation"><div class="address"><p><tt class="email"><<a href="mailto:CVizitiu@gbif.org">CVizitiu@gbif.org</a>></tt></p></div></div></div></div><div><p class="pubdate"> (3 June 2003) </p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="CUPS-printing.html#id2953785">Introduction</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2953792">Features and Benefits</a></dt><dt><a href="CUPS-printing.html#id2953845">Overview</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2953900">Basic Configuration of CUPS support</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2953979">Linking of smbd with libcups.so</a></dt><dt><a href="CUPS-printing.html#id2954122">Simple smb.conf Settings for CUPS</a></dt><dt><a href="CUPS-printing.html#id2954205">More complex smb.conf Settings for
CUPS</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2954322">Advanced Configuration</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2954343">Central spooling vs. "Peer-to-Peer" printing</a></dt><dt><a href="CUPS-printing.html#id2954370">CUPS/Samba as a "spooling-only" Print Server; "raw" printing
with Vendor Drivers on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2954406">Driver Installation Methods on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2954465">Explicitly enable "raw" printing for
application/octet-stream!</a></dt><dt><a href="CUPS-printing.html#id2954626">Three familiar Methods for driver upload plus a new one</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2954719">Using CUPS/Samba in an advanced Way -- intelligent printing
with PostScript Driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2954794">GDI on Windows -- PostScript on Unix</a></dt><dt><a href="CUPS-printing.html#id2954839">Windows Drivers, GDI and EMF</a></dt><dt><a href="CUPS-printing.html#id2954940">Unix Printfile Conversion and GUI Basics</a></dt><dt><a href="CUPS-printing.html#id2955028">PostScript and Ghostscript</a></dt><dt><a href="CUPS-printing.html#id2955125">Ghostscript -- the Software RIP for non-PostScript Printers</a></dt><dt><a href="CUPS-printing.html#id2955238">PostScript Printer Description (PPD) Specification</a></dt><dt><a href="CUPS-printing.html#id2955308">CUPS can use all Windows-formatted Vendor PPDs</a></dt><dt><a href="CUPS-printing.html#id2955397">CUPS also uses PPDs for non-PostScript Printers</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2955420">The CUPS Filtering Architecture</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2955560">MIME types and CUPS Filters</a></dt><dt><a href="CUPS-printing.html#id2955747">MIME type Conversion Rules</a></dt><dt><a href="CUPS-printing.html#id2955864">Filter Requirements</a></dt><dt><a href="CUPS-printing.html#id2956034">Prefilters</a></dt><dt><a href="CUPS-printing.html#id2956120">pstops</a></dt><dt><a href="CUPS-printing.html#id2956222">pstoraster</a></dt><dt><a href="CUPS-printing.html#id2956377">imagetops and imagetoraster</a></dt><dt><a href="CUPS-printing.html#id2956434">rasterto [printers specific]</a></dt><dt><a href="CUPS-printing.html#id2956519">CUPS Backends</a></dt><dt><a href="CUPS-printing.html#id2956831">cupsomatic/Foomatic -- how do they fit into the Picture?</a></dt><dt><a href="CUPS-printing.html#id2956944">The Complete Picture</a></dt><dt><a href="CUPS-printing.html#id2956960">mime.convs</a></dt><dt><a href="CUPS-printing.html#id2957012">"Raw" printing</a></dt><dt><a href="CUPS-printing.html#id2957066">"application/octet-stream" printing</a></dt><dt><a href="CUPS-printing.html#id2957282">PostScript Printer Descriptions (PPDs) for non-PS Printers</a></dt><dt><a href="CUPS-printing.html#id2957510">Difference between cupsomatic/foomatic-rip and
native CUPS printing</a></dt><dt><a href="CUPS-printing.html#id2957666">Examples for filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2957897">Sources of CUPS drivers / PPDs</a></dt><dt><a href="CUPS-printing.html#id2958024">Printing with Interface Scripts</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2958100">Network printing (purely Windows)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2958116">From Windows Clients to an NT Print Server</a></dt><dt><a href="CUPS-printing.html#id2958155">Driver Execution on the Client</a></dt><dt><a href="CUPS-printing.html#id2958227">Driver Execution on the Server</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2958289">Network Printing (Windows clients -- UNIX/Samba Print
Servers)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2958310">From Windows Clients to a CUPS/Samba Print Server</a></dt><dt><a href="CUPS-printing.html#id2958474">Samba receiving Jobfiles and passing them to CUPS</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2958550">Network PostScript RIP: CUPS Filters on Server -- clients use
PostScript Driver with CUPS-PPDs</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2958605">PPDs for non-PS Printers on UNIX</a></dt><dt><a href="CUPS-printing.html#id2958646">PPDs for non-PS Printers on Windows</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2958712">Windows Terminal Servers (WTS) as CUPS Clients</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2958729">Printer Drivers running in "Kernel Mode" cause many
Problems</a></dt><dt><a href="CUPS-printing.html#id2958763">Workarounds impose Heavy Limitations</a></dt><dt><a href="CUPS-printing.html#id2958784">CUPS: a "Magical Stone"?</a></dt><dt><a href="CUPS-printing.html#id2958811">PostScript Drivers with no major problems -- even in Kernel
Mode</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2958865"> Setting up CUPS for driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2958884">cupsaddsmb: the unknown Utility</a></dt><dt><a href="CUPS-printing.html#id2958976">Prepare your smb.conf for
cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2959022">CUPS Package of "PostScript Driver for WinNT/2k/XP"</a></dt><dt><a href="CUPS-printing.html#id2959220">Recognize the different Driver Files</a></dt><dt><a href="CUPS-printing.html#id2959278">Acquiring the Adobe Driver Files</a></dt><dt><a href="CUPS-printing.html#id2959310">ESP Print Pro Package of "PostScript Driver for
WinNT/2k/XP"</a></dt><dt><a href="CUPS-printing.html#id2959360">Caveats to be considered</a></dt><dt><a href="CUPS-printing.html#id2959582">What are the Benefits of using the "CUPS PostScript Driver for
Windows NT/2k/XP" as compared to the Adobe Driver?</a></dt><dt><a href="CUPS-printing.html#id2959764">Run "cupsaddsmb" (quiet Mode)</a></dt><dt><a href="CUPS-printing.html#id2959865">Run "cupsaddsmb" with verbose Output</a></dt><dt><a href="CUPS-printing.html#id2960092">Understanding cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2960186">How to recognize if cupsaddsm completed successfully</a></dt><dt><a href="CUPS-printing.html#id2960273">cupsaddsmb with a Samba PDC</a></dt><dt><a href="CUPS-printing.html#id2960308">cupsaddsmb Flowchart</a></dt><dt><a href="CUPS-printing.html#id2960361">Installing the PostScript Driver on a Client</a></dt><dt><a href="CUPS-printing.html#id2960474">Avoiding critical PostScript Driver Settings on the
Client</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2960608">Installing PostScript Driver Files manually (using
rpcclient)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2960723">A Check of the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2960836">Understanding the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2960925">Producing an Example by querying a Windows Box</a></dt><dt><a href="CUPS-printing.html#id2961015">What is required for adddriver and setdriver to succeed</a></dt><dt><a href="CUPS-printing.html#id2961177">Manual Commandline Driver Installation in 15 little Steps</a></dt><dt><a href="CUPS-printing.html#id2961830">Troubleshooting revisited</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2961930">The printing *.tdb Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2962033">Trivial DataBase Files</a></dt><dt><a href="CUPS-printing.html#id2962103">Binary Format</a></dt><dt><a href="CUPS-printing.html#id2962165">Losing *.tdb Files</a></dt><dt><a href="CUPS-printing.html#id2962224">Using tdbbackup</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2962290">CUPS Print Drivers from Linuxprinting.org</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2962398">foomatic-rip and Foomatic explained</a></dt><dt><a href="CUPS-printing.html#id2963027">foomatic-rip and Foomatic-PPD Download and Installation</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2963488">Page Accounting with CUPS</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2963519">Setting up Quotas</a></dt><dt><a href="CUPS-printing.html#id2963551">Correct and incorrect Accounting</a></dt><dt><a href="CUPS-printing.html#id2963592">Adobe and CUPS PostScript Drivers for Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2963663">The page_log File Syntax</a></dt><dt><a href="CUPS-printing.html#id2963765">Possible Shortcomings</a></dt><dt><a href="CUPS-printing.html#id2963836">Future Developments</a></dt><dt><a href="CUPS-printing.html#id2963884">Other Accounting Tools</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2963899">Additional Material</a></dt><dt><a href="CUPS-printing.html#id2964092">Auto-Deletion or Preservation of CUPS Spool Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2964138">CUPS Configuration Settings explained</a></dt><dt><a href="CUPS-printing.html#id2964221">Pre-conditions</a></dt><dt><a href="CUPS-printing.html#id2964281">Manual Configuration</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2964299">When not to use Samba to print to
CUPS</a></dt><dt><a href="CUPS-printing.html#id2964316">In Case of Trouble.....</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2964352">Where to find Documentation</a></dt><dt><a href="CUPS-printing.html#id2964364">How to ask for Help</a></dt><dt><a href="CUPS-printing.html#id2964377">Where to find Help</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2964391">Appendix</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2964398">Printing from CUPS to Windows attached
Printers</a></dt><dt><a href="CUPS-printing.html#id2964612">More CUPS filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2964919">Trouble Shooting Guidelines to fix typical Samba printing
Problems</a></dt><dt><a href="CUPS-printing.html#id2966041">An Overview of the CUPS Printing Processes</a></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2953785"></a>Introduction</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2953792"></a>Features and Benefits</h3></div></div><div></div></div><p>
The Common Unix Print System (<a href="http://www.cups.org/" target="_top">CUPS</a>) has become very popular. All
big Linux distributions now ship it as their default printing
system. But to many it is still a very mystical tool. Normally it
"just works" (TM). People tend to regard it as a sort of "black box",
which they don't want to look into, as long as it works OK. But once
there is a little problem, they are in trouble to find out where to
start debugging it. Also, even the most recent and otherwise excellent
printed Samba documentation has only limited attention paid to CUPS
printing, leaving out important pieces or even writing plain wrong
things about it. This demands rectification. But before you dive into
this chapter, make sure that you don't forget to refer to the
"Classical Printing" chapter also. It contains a lot of information
that is relevant for CUPS too.
</p><p>
CUPS sports quite a few unique and powerful features. While their
basic functions may be grasped quite easily, they are also
new. Because they are different from other, more traditional printing
systems, it is best to try and not apply any prior knowledge about
printing upon this new system. Rather try to start understand CUPS
from the beginning. This documentation will lead you here to a
complete understanding of CUPS, if you study all of the material
contained. But lets start with the most basic things first. Maybe this
is all you need for now. Then you can skip most of the other
paragraphs.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2953845"></a>Overview</h3></div></div><div></div></div><p>
CUPS is more than just a print spooling system. It is a complete
printer management system that complies with the new IPP
(<span class="emphasis"><em>Internet Printing Protocol</em></span>). IPP is an industry
and IETF (<span class="emphasis"><em>Internet Engineering Task Force</em></span>)
standard for network printing. Many of its functions can be managed
remotely (or locally) via a web browser (giving you a
platform-independent access to the CUPS print server). In addition it
has the traditional commandline and several more modern GUI interfaces
(GUI interfaces developed by 3rd parties, like KDE's
overwhelming <a href="http://printing.kde.org/" target="_top">KDEPrint</a>).
</p><p>
CUPS allows creation of "raw" printers (ie: NO print file
format translation) as well as "smart" printers (i.e. CUPS does
file format conversion as required for the printer). In many ways
this gives CUPS similar capabilities 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 move on to
explore how one may configure CUPS for interfacing with MS Windows
print clients via Samba.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2953900"></a>Basic Configuration of CUPS support</h2></div></div><div></div></div><p>
Printing with CUPS in the most basic <tt class="filename">smb.conf</tt>
setup in Samba 3.0 (as was true for 2.2.x) only needs two
settings: <i class="parameter"><tt>printing = cups</tt></i> and <i class="parameter"><tt>printcap
= cups</tt></i>. CUPS itself doesn't need a printcap file
anymore. However, the <tt class="filename">cupsd.conf</tt> configuration
file knows two related directives: they control if such a file should
be automatically created and maintained by CUPS for the convenience of
third party applications (example: <i class="parameter"><tt>Printcap
/etc/printcap</tt></i> and <i class="parameter"><tt>PrintcapFormat
BSD</tt></i>). These legacy programs often require the existence of
printcap file containing printernames or they will refuse to
print. Make sure CUPS is set to generate and maintain a printcap! For
details see <b class="command">man cupsd.conf</b> and other CUPS-related
documentation, like the wealth of documents on your CUPS server
itself: <a href="http://localhost:631/documentation.html" target="_top">http://localhost:631/documentation.html</a>.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2953979"></a>Linking of smbd with libcups.so</h3></div></div><div></div></div><p>
Samba has a very special relationship to CUPS. The reason is: Samba
can be compiled with CUPS library support. Most recent installations
have this support enabled, and per default CUPS linking is compiled
into smbd and other Samba binaries. Of course, you can use CUPS even
if Samba is not linked against <tt class="filename">libcups.so</tt> -- but
there are some differences in required or supported configuration
then.
</p><p>
If SAMBA is compiled against libcups, then <i class="parameter"><tt>printcap =
cups</tt></i> uses the CUPS API to list printers, submit jobs,
query queues, etc. Otherwise it maps to the System V commands with an
additional <b class="command">-oraw</b> option for printing. On a Linux
system, you can use the <b class="command">ldd</b> utility to find out
details (ldd may not be present on other OS platforms, or its function
may be embodied by a different command):
</p><pre class="screen">
transmeta:/home/kurt # ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
[....]
</pre><p>
The line <tt class="computeroutput">libcups.so.2 => /usr/lib/libcups.so.2
(0x40123000)</tt> shows there is CUPS support compiled
into this version of Samba. If this is the case, and printing = cups
is set, then <span class="emphasis"><em>any otherwise manually set print command in
<tt class="filename">smb.conf</tt> is ignored</em></span>. This is an
important point to remember!
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> Should you require -- for any reason -- to set your own
print commands, you can still do this by setting <i class="parameter"><tt>printing =
sysv</tt></i>. However, you'll loose all the benefits from the
close CUPS/Samba integration. You are on your own then to manually
configure the rest of the printing system commands (most important:
<i class="parameter"><tt>print command</tt></i>; other commands are
<i class="parameter"><tt>lppause command, lpresume command, lpq command, lprm
command, queuepause command </tt></i> and <i class="parameter"><tt>queue resume
command</tt></i>).</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954122"></a>Simple <tt class="filename">smb.conf</tt> Settings for CUPS</h3></div></div><div></div></div><p>
To summarize, here is the simplest printing-related setup
for <tt class="filename">smb.conf</tt> to enable basic CUPS support:
</p><pre class="screen">
[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
public = yes
guest ok = yes
writable = no
printable = yes
printer admin = root, @ntadmins
</pre><p>
This is all you need for basic printing setup for CUPS. It will print
all Graphic, Text, PDF and PostScript file submitted from Windows
clients. However, most of your Windows users would not know how to
send these kind 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 very rarely send files from the command
line. Unlike UNIX clients, they hardly submit graphic, text or PDF
formatted files directly to the spooler. They nearly exclusively print
from GUI applications, with a "printer driver" hooked in between the
applications native format and the print data stream. If the backend
printer is not a PostScript device, the print data stream is "binary",
sensible only for the target printer. Read on to learn which problem
this may cause and how to avoid it.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954205"></a>More complex <tt class="filename">smb.conf</tt> Settings for
CUPS</h3></div></div><div></div></div><p>
Here is a slightly more complex printing-related setup
for <tt class="filename">smb.conf</tt>. It enables general CUPS printing
support for all printers, but defines one printer share which is set
up differently.
</p><pre class="screen">
[global]
printing = cups
printcap name = cups
load printers = yes
[printers]
comment = All Printers
path = /var/spool/samba
public = yes
guest ok = yes
writable = no
printable = yes
printer admin = root, @ntadmins
[special_printer]
comment = A special printer with his own settings
path = /var/spool/samba-special
printing = sysv
printcap = lpstat
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
public = no
guest ok = no
writeable = no
printable = yes
printer admin = kurt
hosts deny = 0.0.0.0
hosts allow = turbo_xp, 10.160.50.23, 10.160.51.60
</pre><p>
This special share is only there for my testing purposes. It doesn't
even write the print job to a file. It just logs the job parameters
known to Samba into the <tt class="filename">/tmp/smbprn.log</tt> file and
deletes the jobfile. Moreover, the <i class="parameter"><tt>printer
admin</tt></i> of this share is "kurt" (not the "@ntadmins" group);
guest access is not allowed; the share isn't announced in Network
Neighbourhood (so you need to know it is there), and it is only
allowing access from three hosts. To prevent CUPS kicking in and
taking over the print jobs for that share, we need to set
<i class="parameter"><tt>printing = sysv</tt></i> and <i class="parameter"><tt>printcap =
lpstat</tt></i>.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2954322"></a>Advanced Configuration</h2></div></div><div></div></div><p>
Before we dive into all the configuration options, let's clarify a few
points. <span class="emphasis"><em>Network printing needs to be organized and setup
correctly</em></span>. Often this is not done correctly. Legacy systems
or small LANs in business environments often lack a clear design and
good housekeeping.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954343"></a>Central spooling vs. "Peer-to-Peer" printing</h3></div></div><div></div></div><p>
Many small office or home networks, as well as badly organized larger
environments, allow each client a direct access to available network
printers. Generally, this is a bad idea. It often blocks one client's
access to the printer when another client's job is printing. It also
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 usage of a "print server": it routes all jobs through one
central system, which responds immediately, takes jobs from multiple
concurrent clients at the same time and in turn transfers them to the
printer(s) in the correct order.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954370"></a>CUPS/Samba as a "spooling-only" Print Server; "raw" printing
with Vendor Drivers on Windows Clients</h3></div></div><div></div></div><p>
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 "raw" spooling of all jobs handed to them by
Samba. This approach meant that the Windows clients were expected to
prepare the print job file in such a way that it became fit to be fed to
the printing device. Here a native (vendor-supplied) Windows printer
driver for the target device needed to be installed on each and every
client.
</p><p>
Of course you can setup 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954406"></a>Driver Installation Methods on Windows Clients</h3></div></div><div></div></div><p>
The printer drivers on the Windows clients may be installed
in two functionally different ways:
</p><div class="itemizedlist"><ul type="disc"><li><p>manually install the drivers locally on each client,
one by one; this yields the old <span class="emphasis"><em>LanMan</em></span> style
printing; it uses a <tt class="filename">\\sambaserver\printershare</tt>
type of connection.</p></li><li><p>deposit and prepare the drivers (for later download) on
the print server (Samba); this enables the clients to use
"Point'n'Print" to get drivers semi-automatically installed the
first time they access the printer; with this method NT/2K/XP
clients use the <span class="emphasis"><em>SPOOLSS/MS-RPC</em></span>
type printing calls.</p></li></ul></div><p>
The second method is recommended for use over the first.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954465"></a>Explicitly enable "raw" printing for
<span class="emphasis"><em>application/octet-stream</em></span>!</h3></div></div><div></div></div><p>
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 "raw" printing of deliberate (binary) file
formats. The CUPS files that need to be correctly set for RAW mode
printers to work are:
</p><div class="itemizedlist"><ul type="disc"><li><p>/etc/cups/mime.types
</p></li><li><p>/etc/cups/mime.convs</p></li></ul></div><p>
Both contain entries (at the end of the respective files) which must
be uncommented to allow RAW mode operation.
In<tt class="filename">/etc/cups/mime.types</tt> make sure this line is
present:
</p><pre class="screen">
application/octet-stream
</pre><p>
In <tt class="filename">/etc/cups/mime.convs</tt>,
have this line:
</p><pre class="screen">
application/octet-stream application/vnd.cups-raw 0 -
</pre><p>
If these two files are not set up correctly for raw Windows client
printing, you may encounter the dreaded <tt class="computeroutput">Unable to
convert file 0</tt> in your CUPS error_log file.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>editing the <tt class="filename">mime.convs</tt> and the
<tt class="filename">mime.types</tt> file does not
<span class="emphasis"><em>enforce</em></span> "raw" printing, it only
<span class="emphasis"><em>allows</em></span> it.
</p></div><p><b>Background. </b>
CUPS being 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
"Denial of Service" attack on your printer(s), causing at the least
the loss of a lot of paper and ink. "Unknown" data are tagged by CUPS
as <span class="emphasis"><em>MIME type: application/octet-stream</em></span> and not
allowed to go to the printer. By default, you can only send other
(known) MIME types "raw". Sending data "raw" means that CUPS does not
try to convert them and passes them to the printer untouched (see next
chapter for even more background explanations).
</p><p>
This is all you need to know to get the CUPS/Samba combo printing
"raw" 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954626"></a>Three familiar Methods for driver upload plus a new one</h3></div></div><div></div></div><p>
If you want to use the MS-RPC type printing, you must upload the
drivers onto the Samba server first (<i class="parameter"><tt>[print$]</tt></i>
share). For a discussion on how to deposit printer drivers on the
Samba host (so that the Windows clients can download and use them via
"Point'n'Print") please also refer to the previous chapter of this
HOWTO Collection. There you will find a description or reference to
three methods of preparing the client drivers on the Samba server:
</p><div class="itemizedlist"><ul type="disc"><li><p>the GUI, "Add Printer Wizard"
<span class="emphasis"><em>upload-from-a-Windows-client</em></span>
method;</p></li><li><p>the commandline, "smbclient/rpcclient"
<span class="emphasis"><em>upload-from-a-UNIX-workstation</em></span>
method;</p></li><li><p>the <span class="emphasis"><em>Imprints</em></span> Toolset
method.</p></li></ul></div><p>
These 3 methods apply to CUPS all the same. A new and more
convenient way to load the Windows drivers into Samba is provided
provided if you use CUPS:
</p><div class="itemizedlist"><ul type="disc"><li><p>the <span class="emphasis"><em>cupsaddsmb</em></span>
utility.</p></li></ul></div><p>
cupsaddsmb is discussed in much detail further below. But we will
first explore the CUPS filtering system and compare the Windows and
UNIX printing architectures.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2954719"></a>Using CUPS/Samba in an advanced Way -- intelligent printing
with PostScript Driver Download</h2></div></div><div></div></div><p>
Still reading on? Good. Let's go into more detail then. We now know
how to set up a "dump" printserver, that is, a server which is spooling
printjobs "raw", leaving the print data untouched.
</p><p>
Possibly you need to setup CUPS in a more smart way. The reasons could
be manifold:
</p><div class="itemizedlist"><ul type="disc"><li><p>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 departments prints how
much?</p></li><li><p>Maybe you are asked to setup a print quota system:
users should not be able to print more jobs, once they have surpassed
a given limit per period?</p></li><li><p>Maybe your previous network printing setup is a mess
and shall be re-organized from a clean beginning?</p></li><li><p>Maybe you have experiencing too many "Blue Screens",
originating from poorly debugged printer drivers running in NT "kernel
mode"?</p></li></ul></div><p>
These goals cannot be achieved by a raw print server. To build a
server meeting these requirements, you'll first need to learn about
how CUPS works and how you can enable its features.
</p><p>
What follows is the comparison of some fundamental concepts for
Windows and Unix printing; then is the time for a description of the
CUPS filtering system, how it works and how you can tweak it.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954794"></a>GDI on Windows -- PostScript on Unix</h3></div></div><div></div></div><p>
Network printing is one of the most complicated and error-prone
day-to-day tasks any user or an administrator may encounter. This is
true for all OS platforms. And there are reasons for this.
</p><p>
You can't expect for most file formats to just throw them towards
printers and they get printed. There needs to be a file format
conversion in between. The problem is: there is no common standard for
print file formats across all manufacturers and printer types. While
<span class="emphasis"><em>PostScript</em></span> (trademark held by Adobe), and, to an
extent, <span class="emphasis"><em>PCL</em></span> (trademark held by HP), have developed
into semi-official "standards", by being the most widely used PDLs
(<span class="emphasis"><em>Page Description Languages</em></span>), there are still
many manufacturers who "roll their own" (their reasons may be
unacceptable license fees for using printer-embedded PostScript
interpreters, etc.).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954839"></a>Windows Drivers, GDI and EMF</h3></div></div><div></div></div><p>
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 GDI (<span class="emphasis"><em>Graphical Device
Interface</em></span>), 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
<span class="emphasis"><em>on screen</em></span> as well as <span class="emphasis"><em>on
paper</em></span> (=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, produces often a file format called EMF (<span class="emphasis"><em>Enhanced
MetaFile</em></span>). The EMF is processed by the printer driver and
converted to the printer-specific file format.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
To the GDI foundation in MS Windows, Apple has chosen to
put paper and screen output on a common foundation for their
(BSD-Unix-based, did you know??) Mac OS X and Darwin Operating
Systems.Their <span class="emphasis"><em>Core Graphic Engine</em></span> uses a
<span class="emphasis"><em>PDF</em></span> derivate for all display work.
</p></div><p>
</p><div class="figure"><a name="id2954904"></a><p class="title"><b>Figure 19.1. Windows Printing to a local Printer</b></p><div class="mediaobject"><img src="projdoc/imagefiles/1small.png" alt="Windows Printing to a local Printer"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2954940"></a>Unix Printfile Conversion and GUI Basics</h3></div></div><div></div></div><p>
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. That gives at least 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 how
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 <span class="emphasis"><em>X.org</em></span>,
designing the UNIX foundations and protocols for Graphical User
Interfaces refused to take over responsibility for "paper output"
also, as some had demanded at the time, and restricted itself to
"on-screen only". (For some years now, the "Xprint" 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 "font" directories on your
system; there are separate ones for fonts used for X display and fonts
to be used on paper.
</p><p><b>Background. </b>
The PostScript programming language is an "invention" by Adobe Inc.,
but its specifications have been published to the full. Its strength
lies in its powerful abilities to describe graphical objects (fonts,
shapes, patterns, lines, curves, 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 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
"raster images" or "pixels" (one notable exception are 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 which 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955028"></a>PostScript and Ghostscript</h3></div></div><div></div></div><p>
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: these devices have a built-in PostScript
language "interpreter", also called a <span class="emphasis"><em>Raster Image
Processor</em></span> (RIP), (which makes them more expensive than
other types of printers); throw PostScript towards them, and they will
spit out your printed pages. Their RIP is doing 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 to PostScript printing of a file from a Windows origin.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Traditional Unix programs and printing systems -- while
using PostScript -- are largely not PPD-aware. PPDs are "PostScript
Printer Description" files. They enable you to specify and control all
options a printer supports: duplexing, stapling, 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.... ;-)
</p></div><p>
</p><div class="figure"><a name="id2955075"></a><p class="title"><b>Figure 19.2. Printing to a Postscript Printer</b></p><div class="mediaobject"><img src="projdoc/imagefiles/2small.png" alt="Printing to a Postscript Printer"></div></div><p>
</p><p>
However, there are other types of printers out there. These don't know
how to print PostScript. They use their own <span class="emphasis"><em>Page Description
Language</em></span> (PDL, often proprietary). To print to them is much
more demanding. Since your Unix applications mostly produce
PostScript, and since these devices don't understand PostScript, you
need to convert the printfiles to a format suitable for your printer
on the host, before you can send it away.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955125"></a>Ghostscript -- the Software RIP for non-PostScript Printers</h3></div></div><div></div></div><p>
Here is where <span class="emphasis"><em>Ghostscript</em></span> kicks in. Ghostscript is
the traditional (and quite powerful) PostScript interpreter used on
Unix platforms. It is a RIP in software, capable to do a
<span class="emphasis"><em>lot</em></span> of file format conversions, for a very broad
spectrum of hardware devices as well as software file formats.
Ghostscript technology and drivers is what enables PostScript printing
to non-PostScript hardware.
</p><p>
</p><div class="figure"><a name="id2955155"></a><p class="title"><b>Figure 19.3. Ghostscript as a RIP for non-postscript printers</b></p><div class="mediaobject"><img src="projdoc/imagefiles/3small.png" alt="Ghostscript as a RIP for non-postscript printers"></div></div><p>
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
Use the "gs -h" command to check for all built-in "devices" of your
Ghostscript version. If you specify e.g. a parameter of
<i class="parameter"><tt>-sDEVICE=png256</tt></i> on your Ghostscript command
line, you are asking Ghostscript to convert the input into a PNG
file. Naming a "device" on the commandline is the most important
single parameter to tell Ghostscript how exactly it should render the
input. New Ghostscript versions are released at fairly regular
intervals, now by artofcode LLC. They are initially put under the
"AFPL" 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 got some
deficiencies. 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, RedHat and Debian. It includes
the "cups" device (essential to print to non-PS printers from CUPS).
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955238"></a>PostScript Printer Description (PPD) Specification</h3></div></div><div></div></div><p>
While PostScript in essence is a <span class="emphasis"><em>Page Description
Language</em></span> (PDL) to represent the page layout in a
<span class="emphasis"><em>device independent</em></span> way, real world print jobs are
always ending up to be output on a 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 <span class="emphasis"><em>PostScript Printer Description</em></span> (PPD)
files. Every PostScript printer ships with one of these files.
</p><p>
PPDs contain all 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.
</p><p>
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 as 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.
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
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).
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955308"></a>CUPS can use all Windows-formatted Vendor PPDs</h3></div></div><div></div></div><p>
CUPS can handle all spec-compliant PPDs as supplied by the
manufacturers for their PostScript models. Even if a
Unix/Linux-illiterate vendor might not have mentioned our favorite
OS in his manuals and brochures -- you can safely trust this:
<span class="emphasis"><em>if you get hold of the Windows NT version of the PPD, you
can use it unchanged in CUPS</em></span> and thus access the full
power of your printer just like a Windows NT user could!
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
To check the spec compliance of any PPD online, go to <a href="http://www.cups.org/testppd.php" target="_top">http://www.cups.org/testppd.php</a>
and upload your PPD. You will see the results displayed
immediately. CUPS in all versions after 1.1.19 has a much more strict
internal PPD parsing and checking code enabled; in case of printing
trouble this online resource should be one of your first pitstops.
</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
For real PostScript printers <span class="emphasis"><em>don't</em></span> use the
<span class="emphasis"><em>Foomatic</em></span> or <span class="emphasis"><em>cupsomatic</em></span>
PPDs from Linuxprinting.org. With these devices the original
vendor-provided PPDs are always the first choice!
</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
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
<b class="command">smbclient //NT4-box/print\$ -U username</b> to
access the Windows directory where all printer driver files are
stored. First look in the <tt class="filename">W32X86/2</tt> subdir for
the PPD you are seeking.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955397"></a>CUPS also uses PPDs for non-PostScript Printers</h3></div></div><div></div></div><p>
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.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2955420"></a>The CUPS Filtering Architecture</h2></div></div><div></div></div><p>
The core of the CUPS filtering system is based on
<span class="emphasis"><em>Ghostscript</em></span>. 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 <span class="emphasis"><em>MIME types</em></span>. Every incoming
printfile is subjected to an initial
<span class="emphasis"><em>auto-typing</em></span>. The auto-typing 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 setup a working filtering chain for any
given input data format.
</p><p>
If CUPS rasterizes a PostScript file <span class="emphasis"><em>natively</em></span> to
a bitmap, this is done in 2 stages:
</p><div class="itemizedlist"><ul type="disc"><li><p>the first stage uses a Ghostscript device named "cups"
(this is since version 1.1.15) and produces a generic raster format
called "CUPS raster".
</p></li><li><p>the second stage uses a "raster driver" which converts
the generic CUPS raster to a device specific raster.</p></li></ul></div><p>
Make sure your Ghostscript version has the "cups" device compiled in
(check with <b class="command">gs -h | grep cups</b>). Otherwise you
may encounter the dreaded <tt class="computeroutput">Unable to convert file
0</tt> in your CUPS error_log file. To have "cups" as a
device in your Ghostscript, you either need to <span class="emphasis"><em>patch GNU
Ghostscript</em></span> and re-compile or use <a href="http://www.cups.org/ghostscript.php" target="_top">ESP Ghostscript</a>. The
superior alternative is ESP Ghostscript: it supports not just CUPS,
but 300 other devices too (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.
</p><p>
CUPS printers may be setup to use <span class="emphasis"><em>external</em></span>
rendering paths. One of the most common ones is provided by the
<span class="emphasis"><em>Foomatic/cupsomatic</em></span> concept, from <a href="http://www.linuxprinting.org/" target="_top">Linuxprinting.org</a>. This
uses the classical Ghostscript approach, doing everything in one
step. It doesn't use the "cups" device, but one of the many
others. However, even for Foomatic/cupsomatic usage, best results and
broadest printer model support is provided by ESP Ghostscript (more
about cupsomatic/Foomatic, particularly the new version called now
<span class="emphasis"><em>foomatic-rip</em></span>, follows below).
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955560"></a>MIME types and CUPS Filters</h3></div></div><div></div></div><p>
CUPS reads the file <tt class="filename">/etc/cups/mime.types</tt>
(and all other files carrying a <tt class="filename">*.types</tt> suffix
in the same directory) upon startup. These files contain the MIME
type recognition rules which are applied when CUPS runs its
auto-typing routines. The rule syntax is explained in the man page
for <tt class="filename">mime.types</tt> and in the comments section of the
<tt class="filename">mime.types</tt> file itself. A simple rule reads
like this:
</p><pre class="screen">
application/pdf pdf string(0,%PDF)
</pre><p>
This means: if a filename has either a
<tt class="filename">.pdf</tt> suffix, or if the magic
string <span class="emphasis"><em>%PDF</em></span> is right at the
beginning of the file itself (offset 0 from the start), then it is
a PDF file (<span class="emphasis"><em>application/pdf</em></span>).
Another rule is this:
</p><pre class="screen">
application/postscript ai eps ps string(0,%!) string(0,<04>%!)
</pre><p>
Its meaning: if the filename has one of the suffixes
<tt class="filename">.ai</tt>, <tt class="filename">.eps</tt>,
<tt class="filename">.ps</tt> or if the file itself starts with one of the
strings <span class="emphasis"><em>%!</em></span> or <span class="emphasis"><em><04>%!</em></span>, it
is a generic PostScript file
(<span class="emphasis"><em>application/postscript</em></span>).
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
There is a very important difference between two similar MIME type in
CUPS: one is <span class="emphasis"><em>application/postscript</em></span>, the other is
<span class="emphasis"><em>application/vnd.cups-postscript</em></span>. While
<span class="emphasis"><em>application/postscript</em></span> is meant to be device
independent (job options for the file are still outside the PS file
content, embedded in commandline or environment variables by CUPS),
<span class="emphasis"><em>application/vnd.cups-postscript</em></span> may have the job
options inserted into the PostScript data itself (were
applicable). The transformation of the generic PostScript
(application/postscript) to the device-specific version
(application/vnd.cups-postscript) is the responsibility of the
CUPS <span class="emphasis"><em>pstops</em></span> filter. pstops uses information
contained in the PPD to do the transformation.
</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
Don't confuse the other mime.types file your system might be using
with the one in the <tt class="filename">/etc/cups/</tt> directory.
</p></div><p>
CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI and a
lot of image formats (GIF. PNG, TIFF, JPEG, Photo-CD, SUN-Raster,
PNM, PBM, SGI-RGB and some more) and their associated MIME types
with its filters.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955747"></a>MIME type Conversion Rules</h3></div></div><div></div></div><p>
CUPS reads the file <tt class="filename">/etc/cups/mime.convs</tt>
(and all other files named with a <tt class="filename">*.convs</tt>
suffix in the same directory) upon startup. These files contain
lines naming an input MIME type, an output MIME type, a format
conversion filter which can produce the output from the input type
and virtual costs associated with this conversion. One example line
reads like this:
</p><pre class="screen">
application/pdf application/postscript 33 pdftops
</pre><p>
This means that the <span class="emphasis"><em>pdftops</em></span> filter will take
<span class="emphasis"><em>application/pdf</em></span> as input and produce
<span class="emphasis"><em>application/postscript</em></span> as output, the virtual
cost of this operation is 33 CUPS-$. The next filter is more
expensive, costing 66 CUPS-$:
</p><pre class="screen">
application/vnd.hp-HPGL application/postscript 66 hpgltops
</pre><p>
This is the <span class="emphasis"><em>hpgltops</em></span>, which processes HP-GL
plotter files to PostScript.
</p><pre class="screen">
application/octet-stream
</pre><p>
Here are two more examples:
</p><pre class="screen">
application/x-shell application/postscript 33 texttops
text/plain application/postscript 33 texttops
</pre><p>
The last two examples name the <span class="emphasis"><em>texttops</em></span> filter
to work on "text/plain" as well as on "application/x-shell". (Hint:
this differentiation is needed for the syntax highlighting feature of
"texttops").
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2955864"></a>Filter Requirements</h3></div></div><div></div></div><p>
There are many more combinations named in mime.convs. However, you
are not limited to use the ones pre-defined there. You can plug in any
filter you like into 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 to what CUPS
needs, and put in the right lines in <tt class="filename">mime.types</tt>
and <tt class="filename">mime.convs</tt>, then it will work seamlessly
inside CUPS!
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
The mentioned "CUPS requirements" for filters are simple. Take
filenames or <tt class="filename">stdin</tt> as input and write to
<tt class="filename">stdout</tt>. They should take these 5 or 6 arguments:
<span class="emphasis"><em>printer job user title copies options [filename]</em></span>
</p><div class="variablelist"><dl><dt><span class="term">Printer</span></dt><dd><p>The name of the printer queue (normally this is the
name of the filter being run)</p></dd><dt><span class="term">job</span></dt><dd><p>The numeric job ID for the job being
printed</p></dd><dt><span class="term">Printer</span></dt><dd><p>The string from the originating-user-name
attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The string from the job-name attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The numeric value from the number-copies
attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The job options</p></dd><dt><span class="term">Printer</span></dt><dd><p>(Optionally) The print request file (if missing,
filters expected data fed through <tt class="filename">stdin</tt>). In most
cases it is very easy to write a simple wrapper script around existing
filters to make them work with CUPS.</p></dd></dl></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956034"></a>Prefilters</h3></div></div><div></div></div><p>
As was said, PostScript is the central file format to any Unix based
printing system. From PostScript, CUPS generates raster data to feed
non-PostScript printers.
</p><p>
But what is happening if you send one of the supported non-PS formats
to print? Then CUPS runs "pre-filters" on these input formats to
generate PostScript first. There are pre-filters to create PS from
ASCII text, PDF, DVI or HP-GL. The outcome of these filters is always
of MIME type <span class="emphasis"><em>application/postscript</em></span> (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 pre-filter is running on all supported image formats,
the <span class="emphasis"><em>imagetops</em></span> filter. Its outcome is always of
MIME type <span class="emphasis"><em>application/vnd.cups-postscript</em></span>
(<span class="emphasis"><em>not</em></span> application/postscript), meaning it has the
print options already embedded into the file.
</p><p>
</p><div class="figure"><a name="id2956084"></a><p class="title"><b>Figure 19.4. Prefiltering in CUPS to form Postscript</b></p><div class="mediaobject"><img src="projdoc/imagefiles/4small.png" alt="Prefiltering in CUPS to form Postscript"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956120"></a>pstops</h3></div></div><div></div></div><p>
<span class="emphasis"><em>pstops</em></span>is the filter to convert
<span class="emphasis"><em>application/postscript</em></span> to
<span class="emphasis"><em>application/vnd.cups-postscript</em></span>. It was said
above that this filter inserts all device-specific print options
(commands to the printer to ask for the duplexing of output, or
stapling an punching it, etc.) into the PostScript file.
</p><p>
</p><div class="figure"><a name="id2956149"></a><p class="title"><b>Figure 19.5. Adding Device-specific Print Options</b></p><div class="mediaobject"><img src="projdoc/imagefiles/5small.png" alt="Adding Device-specific Print Options"></div></div><p>
</p><p>
This is not all: other tasks performed by it are:
</p><div class="itemizedlist"><ul type="disc"><li><p>
selecting the range of pages to be printed (if you choose to
print only pages "3, 6, 8-11, 16, 19-21", or only the odd numbered
ones)
</p></li><li><p>
putting 2 or more logical pages on one sheet of paper (the
so-called "number-up" function)
</p></li><li><p>counting the pages of the job to insert the accounting
information into the <tt class="filename">/var/log/cups/page_log</tt>
</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956222"></a>pstoraster</h3></div></div><div></div></div><p>
<span class="emphasis"><em>pstoraster</em></span> 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 <span class="emphasis"><em>raster drivers</em></span>,
that are able to generate device-specific printer data.
</p><p>
</p><div class="figure"><a name="id2956251"></a><p class="title"><b>Figure 19.6. Postscript to intermediate Raster format</b></p><div class="mediaobject"><img src="projdoc/imagefiles/6small.png" alt="Postscript to intermediate Raster format"></div></div><p>
</p><p>
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 following downstream raster drivers. Its MIME type is
registered with IANA and its specification is of course completely
open. It is designed to make it very 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
for the first stage of rasterization so these vendors don't need to care
about Ghostscript complications (in fact, there is currently more
than one vendor financing the development of CUPS raster drivers).
</p><p>
</p><div class="figure"><a name="id2956304"></a><p class="title"><b>Figure 19.7. CUPS-raster production using Ghostscript</b></p><div class="mediaobject"><img src="projdoc/imagefiles/7small.png" alt="CUPS-raster production using Ghostscript"></div></div><p>
</p><p>
CUPS versions before version 1.1.15 were shipping a binary (or source
code) standalone filter, named "pstoraster". pstoraster was derived
from GNU Ghostscript 5.50, and could be installed besides and in
addition to any GNU or AFPL Ghostscript package without conflicting.
</p><p>
From version 1.1.15, this has changed. The functions for this has been
integrated back into Ghostscript (now based on GNU Ghostscript version
7.05). The "pstoraster" filter is now a simple shell script calling
<b class="command">gs</b> with the <b class="command">-sDEVICE=cups</b>
parameter. If your Ghostscript doesn't show a success on asking for
<b class="command">gs -h |grep cups</b>, you might not be able to
print. Update your Ghostscript then!
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956377"></a>imagetops and imagetoraster</h3></div></div><div></div></div><p>
Above in the section about prefilters, we mentioned the prefilter
that generates PostScript from image formats. The imagetoraster
filter is used to convert directly from image to raster, without the
intermediate PostScript stage. It is used more often than the above
mentioned prefilters. Here is a summarizing flowchart of image file
filtering:
</p><p>
</p><div class="figure"><a name="id2956398"></a><p class="title"><b>Figure 19.8. Image format to CUPS-raster format conversion</b></p><div class="mediaobject"><img src="projdoc/imagefiles/8small.png" alt="Image format to CUPS-raster format conversion"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956434"></a>rasterto [printers specific]</h3></div></div><div></div></div><p>
CUPS ships with quite some different raster drivers processing CUPS
raster. On my system I find in /usr/lib/cups/filter/ these:
<i class="parameter"><tt>rastertoalps, rastertobj, rastertoepson, rastertoescp,
rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo,
rastertoescp, rastertohp</tt></i> and
<i class="parameter"><tt>rastertoprinter</tt></i>. Don't worry if you have less
than this; some of these are installed by commercial add-ons to CUPS
(like <i class="parameter"><tt>rastertoturboprint</tt></i>), others (like
<i class="parameter"><tt>rastertoprinter</tt></i>) by 3rd party driver
development projects (such as Gimp-Print) wanting to cooperate as
closely as possible with CUPS.
</p><p>
</p><div class="figure"><a name="id2956484"></a><p class="title"><b>Figure 19.9. Raster to Printer Specific formats</b></p><div class="mediaobject"><img src="projdoc/imagefiles/9small.png" alt="Raster to Printer Specific formats"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956519"></a>CUPS Backends</h3></div></div><div></div></div><p>
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" of sending printjobs over the network, or for every local
interface. Every CUPS printqueue needs to have a CUPS "device-URI"
associated with it. The device URI is the way to encode the backend
used to send the job to its destination. Network device-URIs are using
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 much from my examples, if your OS is not Linux:
</p><div class="variablelist"><dl><dt><span class="term">usb</span></dt><dd><p>
This backend sends printfiles to USB-connected printers. An
example for the CUPS device-URI to use is:
<tt class="filename">usb:/dev/usb/lp0</tt>
</p></dd><dt><span class="term">serial</span></dt><dd><p>
This backend sends printfiles to serially connected printers.
An example for the CUPS device-URI to use is:
<tt class="filename">serial:/dev/ttyS0?baud=11500</tt>
</p></dd><dt><span class="term">parallel</span></dt><dd><p>
This backend sends printfiles to printers connected to the
parallel port. An example for the CUPS device-URI to use is:
<tt class="filename">parallel:/dev/lp0</tt>
</p></dd><dt><span class="term">scsi</span></dt><dd><p>
This backend sends printfiles to printers attached to the
SCSI interface. An example for the CUPS device-URI to use is:
<tt class="filename">scsi:/dev/sr1</tt>
</p></dd><dt><span class="term">lpd</span></dt><dd><p>
This backend sends printfiles to LPR/LPD connected network
printers. An example for the CUPS device-URI to use is:
<tt class="filename">lpd://remote_host_name/remote_queue_name</tt>
</p></dd><dt><span class="term">AppSocket/HP JetDirect</span></dt><dd><p>
This backend sends printfiles to AppSocket (a.k.a. "HP
JetDirect") connected network printers. An example for the CUPS
device-URI to use is:
<tt class="filename">socket://10.11.12.13:9100</tt>
</p></dd><dt><span class="term">ipp</span></dt><dd><p>
This backend sends printfiles to IPP connected network
printers (or to other CUPS servers). Examples for CUPS device-URIs
to use are:
<tt class="filename">ipp:://192.193.194.195/ipp</tt>
(for many HP printers) or
<tt class="filename">ipp://remote_cups_server/printers/remote_printer_name</tt>
</p></dd><dt><span class="term">http</span></dt><dd><p>
This backend sends printfiles 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:
<tt class="filename">http:://192.193.194.195:631/ipp</tt>
(for many HP printers) or
<tt class="filename">http://remote_cups_server:631/printers/remote_printer_name</tt>
</p></dd><dt><span class="term">smb</span></dt><dd><p>
This backend sends printfiles to printers shared by a Windows
host. An example for CUPS device-URIs to use are:
<tt class="filename">smb://workgroup/server/printersharename</tt>
Or
<tt class="filename">Smb://server/printersharename</tt>
or
<tt class="filename">smb://username:password@workgroup/server/printersharename</tt>
or
<tt class="filename">smb://username:password@server/printersharename</tt>.
The smb:// backend is a symlink to the Samba utility
<span class="emphasis"><em>smbspool</em></span> (doesn't ship with CUPS). If the
symlink is not present in your CUPS backend directory, have your
root user create it: <b class="command">ln -s `which smbspool`
/usr/lib/cups/backend/smb</b>.
</p></dd></dl></div><p>
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 "special" printers which send
the printjobs as email (through a "mailto:/" backend), convert them to
PDF (through a "pdfgen:/" backend) or dump them to "/dev/null" (In
fact I have the system-wide default printer set up to be connected to
a "devnull:/" backend: there are just too many people sending jobs
without specifying a printer, or scripts and programs which don't name
a printer. The system-wide default deletes the job and sends a polite
mail back to the $USER asking him to always specify a correct
printername).
</p><p>
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 <span class="emphasis"><em>lpinfo</em></span>
utility. Used with the <i class="parameter"><tt>-v</tt></i> parameter, it lists
all available backends:
</p><pre class="screen">
lpinfo -v
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956831"></a>cupsomatic/Foomatic -- how do they fit into the Picture?</h3></div></div><div></div></div><p>
"cupsomatic" filters may be the most widely used on CUPS
installations. You must be clear about the fact 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. cupsomatic uses PPDs which are generated from the "Foomatic"
Printer & Driver Database at Linuxprinting.org.
</p><p>
You can recognize these PPDs from the line calling the
<span class="emphasis"><em>cupsomatic</em></span> filter:
</p><pre class="screen">
*cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
</pre><p>
This line you may find amongst 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 <span class="emphasis"><em>foomatic</em></span> namepart for
the driver description. cupsomatic is a Perl script that runs
Ghostscript, with all the complicated commandline options
auto-constructed from the selected PPD and commandline options give to
the printjob.
</p><p>
However, cupsomatic 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 "Point'n'Print" to Windows clients. A better,
and more powerful successor is now in a very stable Beta-version
available: it is called <span class="emphasis"><em>foomatic-rip</em></span>. To use
foomatic-rip as a filter with CUPS, you need the new-type PPDs. These
have a similar, but different line:
</p><pre class="screen">
*cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
</pre><p>
The PPD generating engine at Linuxprinting.org has been revamped.
The new PPDs comply to the Adobe spec. On top, they also provide a
new way to specify different quality levels (hi-res photo, normal
color, grayscale, draft...) with a single click (whereas before you
could have required 5 or more different selections (media type,
resolution, inktype, 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: the new foomatic-rip now works seamlessly with all
legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR etc.), providing
for them access to use PPDs for their printing!
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956944"></a>The Complete Picture</h3></div></div><div></div></div><p>
If you want to see an overview over all the filters and how they
relate to each other, the complete picture of the puzzle is at the end
of this document.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2956960"></a><tt class="filename">mime.convs</tt></h3></div></div><div></div></div><p>
CUPS auto-constructs all possible filtering chain paths for any given
MIME type, and every printer installed. But how does it decide in
favor or against a specific alternative? (There may often 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 3rd column of the mime.convs file. They represent virtual costs
assigned to this filter. Every possible filtering chain will sum up to
a total "filter cost". CUPS decides for the most "inexpensive" route.
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
The setting of <i class="parameter"><tt>FilterLimit 1000</tt></i> in
<tt class="filename">cupsd.conf</tt> will not allow more filters to
run concurrently than will consume a total of 1000 virtual filter
cost. This is a very efficient way to limit the load of any CUPS
server by setting an appropriate "FilterLimit" value. A FilterLimit of
200 allows roughly 1 job at a time, while a FilterLimit of 1000 allows
approximately 5 jobs maximum at a time.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957012"></a>"Raw" printing</h3></div></div><div></div></div><p>
You can tell CUPS to print (nearly) any file "raw". "Raw" means it
will not be filtered. CUPS will send the file to the printer "as is"
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 "-o raw" 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:
</p><pre class="screen">
lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E
</pre><p>
sets up a queue named "rawprinter", connected via the "socket"
protocol (a.k.a. "HP JetDirect") to the device at IP address
11.12.1.3.14, using port 9100. (If you had added a PPD with
<b class="command">-P /path/to/PPD</b> to this command line, you would
have installed a "normal" printqueue.
</p><p>
CUPS will automatically treat each job sent to a queue as a "raw" 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957066"></a>"application/octet-stream" printing</h3></div></div><div></div></div><p>
Any MIME type with no rule in the
<tt class="filename">/etc/cups/mime.types</tt> file is regarded as unknown
or <span class="emphasis"><em>application/octet-stream</em></span> and will not be
sent. Because CUPS refuses to print unknown MIME types per default,
you will probably have experienced the fact that printjobs originating
from Windows clients were not printed. You may have found an error
message in your CUPS logs like:
</p><pre class="screen">
Unable to convert file 0 to printable format for job
</pre><p>
To enable the printing of "application/octet-stream" files, edit
these two files:
</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="filename">/etc/cups/mime.convs</tt></p></li><li><p><tt class="filename">/etc/cups/mime.types</tt></p></li></ul></div><p>
Both contain entries (at the end of the respective files) which must
be uncommented to allow RAW mode operation for
application/octet-stream. In <tt class="filename">/etc/cups/mime.types</tt>
make sure this line is present:
</p><pre class="screen">
application/octet-stream
</pre><p>
This line (with no specific auto-typing rule set) makes all files
not otherwise auto-typed a member of application/octet-stream. In
<tt class="filename">/etc/cups/mime.convs</tt>, have this
line:
</p><pre class="screen">
application/octet-stream application/vnd.cups-raw 0 -
</pre><p>
This line tells CUPS to use the <span class="emphasis"><em>Null Filter</em></span>
(denoted as "-", doing... nothing at all) on
<span class="emphasis"><em>application/octet-stream</em></span>, and tag the result as
<span class="emphasis"><em>application/vnd.cups-raw</em></span>. 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.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> Editing the <tt class="filename">mime.convs</tt> and the
<tt class="filename">mime.types</tt> file does not
<span class="emphasis"><em>enforce</em></span> "raw" printing, it only
<span class="emphasis"><em>allows</em></span> it.
</p></div><p><b>Background. </b>
CUPS being 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...) "Unknown" data are regarded by CUPS
as <span class="emphasis"><em>MIME type</em></span>
<span class="emphasis"><em>application/octet-stream</em></span>. While you
<span class="emphasis"><em>can</em></span> send data "raw", the MIME type for these must
be one that is known to CUPS and an allowed one. The file
<tt class="filename">/etc/cups/mime.types</tt> defines the "rules" how CUPS
recognizes MIME types. The file
<tt class="filename">/etc/cups/mime.convs</tt> decides which file
conversion filter(s) may be applied to which MIME types.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957282"></a>PostScript Printer Descriptions (PPDs) for non-PS Printers</h3></div></div><div></div></div><p>
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 jobfile. CUPS has extended this
scope for PPDs to cover non-PostScript printers too. This was not
very 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 jobfiles. The only difference is:
a PostScript printer has the RIP built-in, for other types of
printers the Ghostscript RIP runs on the host computer.
</p><p>
PPDs for a non-PS printer have a few lines that are unique to
CUPS. The most important one looks similar to this:
</p><pre class="screen">
*cupsFilter: application/vnd.cups-raster 66 rastertoprinter
</pre><p>
It is the last piece in the CUPS filtering puzzle. This line tells the
CUPS daemon to use as a last filter "rastertoprinter". This filter
should be served as input an "application/vnd.cups-raster" MIME type
file. Therefore CUPS should auto-construct a filtering chain, which
delivers as its last output the specified MIME type. This is then
taken as input to the specified "rastertoprinter" filter. After this
the last filter has done its work ("rastertoprinter" is a Gimp-Print
filter), the file should go to the backend, which sends it to the
output device.
</p><p>
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):
</p><div class="variablelist"><dl><dt><span class="term">deskjet.ppd</span></dt><dd><p>older HP inkjet printers and compatible
</p></dd><dt><span class="term">deskjet2.ppd</span></dt><dd><p>newer HP inkjet printers and compatible
</p></dd><dt><span class="term">dymo.ppd</span></dt><dd><p>label printers
</p></dd><dt><span class="term">epson9.ppd</span></dt><dd><p>Epson 24pin impact printers and compatible
</p></dd><dt><span class="term">epson24.ppd</span></dt><dd><p>Epson 24pin impact printers and compatible
</p></dd><dt><span class="term">okidata9.ppd</span></dt><dd><p>Okidata 9pin impact printers and compatible
</p></dd><dt><span class="term">okidat24.ppd</span></dt><dd><p>Okidata 24pin impact printers and compatible
</p></dd><dt><span class="term">stcolor.ppd</span></dt><dd><p>older Epson Stylus Color printers
</p></dd><dt><span class="term">stcolor2.ppd</span></dt><dd><p>newer Epson Stylus Color printers
</p></dd><dt><span class="term">stphoto.ppd</span></dt><dd><p>older Epson Stylus Photo printers
</p></dd><dt><span class="term">stphoto2.ppd</span></dt><dd><p>newer Epson Stylus Photo printers
</p></dd><dt><span class="term">laserjet.ppd</span></dt><dd><p>all PCL printers. Further below is a discussion
of several other driver/PPD-packages suitable fur use with CUPS.
</p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957510"></a>Difference between <span class="emphasis"><em>cupsomatic/foomatic-rip</em></span> and
<span class="emphasis"><em>native CUPS</em></span> printing</h3></div></div><div></div></div><p>
Native CUPS rasterization works in two steps.
</p><div class="itemizedlist"><ul type="disc"><li><p>
First is the "pstoraster" step. It uses the special "cups"
device from ESP Ghostscript 7.05.x as its tool
</p></li><li><p>
Second comes the "rasterdriver" 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/Non-Free, some are proprietary.</p></li></ul></div><p>
Often this produces better quality (and has several more
advantages) than other methods.
</p><p>
</p><div class="figure"><a name="id2957561"></a><p class="title"><b>Figure 19.10. cupsomatic/foomatic processing versus Native CUPS</b></p><div class="mediaobject"><img src="projdoc/imagefiles/10small.png" alt="cupsomatic/foomatic processing versus Native CUPS"></div></div><p>
</p><p>
One other method is the <span class="emphasis"><em>cupsomatic/foomatic-rip</em></span>
way. Note that cupsomatic is <span class="emphasis"><em>not</em></span> made by the CUPS
developers. It is an independent contribution to printing development,
made by people from Linuxprinting.org (see also <a href="http://www.cups.org/cups-help.html" target="_top">http://www.cups.org/cups-help.html</a>).
cupsomatic is no longer developed and maintained and is no longer
supported. It has now been replaced by
<span class="emphasis"><em>foomatic-rip</em></span>. foomatic-rip is a complete re-write
of the old cupsomatic idea, but very much improved and generalized to
other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly
advised, especially if you are upgrading to a recent version of CUPS
too.
</p><p>
Both the cupsomatic (old) and the foomatic-rip (new) methods from
Linuxprinting.org use the traditional Ghostscript print file
processing, doing everything in a single step. It therefore relies on
all the other devices built-in 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.
</p><p>
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.
</p><p>
cupsomatic "kidnaps" the printfile after the
<span class="emphasis"><em>application/vnd.cups-postscript</em></span> stage and
deviates it through the CUPS-external, system wide Ghostscript
installation: Therefore the printfile bypasses the "pstoraster" filter
(and thus also bypasses the CUPS-raster-drivers
"rastertosomething"). After Ghostscript finished its rasterization,
cupsomatic hands the rendered file directly to the CUPS backend. The
flowchart above illustrates the difference between native CUPS
rendering and the Foomatic/cupsomatic method.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957666"></a>Examples for filtering Chains</h3></div></div><div></div></div><p>
Here are a few examples of commonly occurring filtering chains to
illustrate the workings of CUPS.
</p><p>
Assume you want to print a PDF file to a HP JetDirect-connected
PostScript printer, but you want to print the pages 3-5, 7, 11-13
only, and you want to print them "2-up" and "duplex":
</p><div class="itemizedlist"><ul type="disc"><li><p>your print options (page selection as required, 2-up,
duplex) are passed to CUPS on the commandline;</p></li><li><p>the (complete) PDF file is sent to CUPS and autotyped as
<span class="emphasis"><em>application/pdf</em></span>;</p></li><li><p>the file therefore first must pass the
<span class="emphasis"><em>pdftops</em></span> pre-filter, which produces PostScript
MIME type <span class="emphasis"><em>application/postscript</em></span> (a preview here
would still show all pages of the original PDF);</p></li><li><p>the file then passes the <span class="emphasis"><em>pstops</em></span>
filter which applies the commandline options: it selects the pages
2-5, 7 and 11-13, creates and imposed layout "2 pages on 1 sheet" and
inserts the correct "duplex" command (as is defined in the printer's
PPD) into the new PostScript file; the file now is of PostScript MIME
type
<span class="emphasis"><em>application/vnd.cups-postscript</em></span>;</p></li><li><p>the file goes to the <span class="emphasis"><em>socket</em></span>
backend, which transfers the job to the printers.</p></li></ul></div><p>
The resulting filter chain therefore is:
</p><pre class="screen">
pdftops --> pstops --> socket
</pre><p>
Assume your want to print the same filter to an USB-connected
Epson Stylus Photo printer, installed with the CUPS
<tt class="filename">stphoto2.ppd</tt>. The first few filtering stages
are nearly the same:
</p><div class="itemizedlist"><ul type="disc"><li><p>your print options (page selection as required, 2-up,
duplex) are passed to CUPS on the commandline;</p></li><li><p>the (complete) PDF file is sent to CUPS and autotyped as
<span class="emphasis"><em>application/pdf</em></span>;</p></li><li><p>the file therefore first must pass the
<span class="emphasis"><em>pdftops</em></span> pre-filter, which produces PostScript
MIME type <span class="emphasis"><em>application/postscript</em></span> (a preview here
would still show all pages of the original PDF);</p></li><li><p>the file then passes the "pstops" filter which applies
the commandline options: it selects the pages 2-5, 7 and 11-13,
creates and imposed layout "2 pages on 1 sheet" and inserts the
correct "duplex" command... (OOoops -- this printer and his PPD
don't support duplex printing at all -- this option will be ignored
then) into the new PostScript file; the file now is of PostScript
MIME type
<span class="emphasis"><em>application/vnd.cups-postscript</em></span>;</p></li><li><p>the file then passes the
<span class="emphasis"><em>pstoraster</em></span> stage and becomes MIME type
<span class="emphasis"><em>application/cups-raster</em></span>;</p></li><li><p>finally, the <span class="emphasis"><em>rastertoepson</em></span> filter
does its work (as is indicated in the printer's PPD), creating the
printer-specific raster data and embedding any user-selected
print-options into the print data stream;</p></li><li><p>the file goes to the <span class="emphasis"><em>usb</em></span> backend,
which transfers the job to the printers.</p></li></ul></div><p>
The resulting filter chain therefore is:
</p><pre class="screen">
pdftops --> pstops --> pstoraster --> rastertoepson --> usb
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957897"></a>Sources of CUPS drivers / PPDs</h3></div></div><div></div></div><p>
On the internet you can find now many thousand CUPS-PPD files
(with their companion filters), in many national languages,
supporting more than 1000 non-PostScript models.
</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://wwwl.easysw.com/printpro/" target="_top">ESP
PrintPro (http://wwwl.easysw.com/printpro/)</a> (commercial,
non-Free) is packaged with more than 3000 PPDs, ready for
successful use "out of the box" on Linux, Mac OS X, IBM-AIX,
HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital Unix and some
more 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).</p></li><li><p>the <a href="http://gimp-print.sourceforge.net/" target="_top">Gimp-Print-Project
(http://gimp-print.sourceforge.net/)</a> (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;</p></li><li><p><a href="http://www.turboprint.com/" target="_top">TurboPrint
(http://www.turboprint.com/)</a> (Shareware, non-Free) supports
roughly the same amount of printers in excellent
quality;</p></li><li><p><a href="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/" target="_top">OMNI
(http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</a>
(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);</p></li><li><p><a href="http://hpinkjet.sourceforge.net/" target="_top">HPIJS
(http://hpinkjet.sourceforge.net/)</a> (BSD-style licenses, Free)
supports around 150 of HP's own printers and is also providing
excellent print quality now (currently available only via the Foomatic
path);</p></li><li><p><a href="http://www.linuxprinting.org/" target="_top">Foomatic/cupsomatic
(http://www.linuxprinting.org/)</a> (LPGL, Free) from
Linuxprinting.org are providing PPDs for practically every Ghostscript
filter known to the world (including Omni, Gimp-Print and
HPIJS).</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
The cupsomatic/Foomatic trick from Linuxprinting.org works
differently from the other drivers. This is explained elsewhere in this
document.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958024"></a>Printing with Interface Scripts</h3></div></div><div></div></div><p>
CUPS also supports the usage of "interface scripts" as known from
System V AT&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 similar role as
PPDs for PostScript printers. Interface scripts may inject the Escape
sequences as required into the print data stream, if the user has
chosen to select a certain paper tray, or print landscape, or use A3
paper, etc. Interfaces 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 <b class="command">-i</b> option:
</p><pre class="screen">
lpadmin -p pclprinter -v socket://11.12.13.14:9100 -i /path/to/interface-script
</pre><p>
Interface scripts might be the "unknown animal" to many. However,
with CUPS they provide the most easy way to plug in your own
custom-written filtering script or program into one specific print
queue (some information about the traditional usage of interface scripts is
to be found at <a href="http://playground.sun.com/printing/documentation/interface.html" target="_top">http://playground.sun.com/printing/documentation/interface.html</a>).
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2958100"></a>Network printing (purely Windows)</h2></div></div><div></div></div><p>
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 "purely Windows" setup: Windows clients
with a Windows NT print server.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958116"></a>From Windows Clients to an NT Print Server</h3></div></div><div></div></div><p>
Windows clients printing to an NT-based print server have two
options. They may
</p><div class="itemizedlist"><ul type="disc"><li><p>execute the driver locally and render the GDI output
(EMF) into the printer specific format on their own,
or</p></li><li><p>send the GDI output (EMF) to the server, where the
driver is executed to render the printer specific
output.</p></li></ul></div><p>
Both print paths are shown in the flowcharts below.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958155"></a>Driver Execution on the Client</h3></div></div><div></div></div><p>
In the first case the print server must spool the file as "raw",
meaning it shouldn't touch the jobfile and try to convert it in any
way. This is what traditional Unix-based print server can do too; and
at a better performance and more reliably than NT print server. This
is what most Samba administrators probably are familiar with. One
advantage of this setup is that this "spooling-only" print server may
be used even if no driver(s) for Unix are available it is sufficient
to have the Windows client drivers available and installed on the
clients.
</p><p>
</p><div class="figure"><a name="id2958191"></a><p class="title"><b>Figure 19.11. Print Driver execution on the Client</b></p><div class="mediaobject"><img src="projdoc/imagefiles/11small.png" alt="Print Driver execution on the Client"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958227"></a>Driver Execution on the Server</h3></div></div><div></div></div><p>
The other path executes the printer driver on the server. The clients
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.
</p><p>
</p><div class="figure"><a name="id2958249"></a><p class="title"><b>Figure 19.12. Print Driver execution on the Server</b></p><div class="mediaobject"><img src="projdoc/imagefiles/12small.png" alt="Print Driver execution on the Server"></div></div><p>
</p><p>
However, there is something similar possible with CUPS. Read on...
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2958289"></a>Network Printing (Windows clients -- UNIX/Samba Print
Servers)</h2></div></div><div></div></div><p>
Since UNIX print servers <span class="emphasis"><em>cannot</em></span> execute the Win32
program code on their platform, the picture is somewhat
different. However, this doesn't limit your options all that
much. In the contrary, you may have a way here to implement printing
features which are not possible otherwise.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958310"></a>From Windows Clients to a CUPS/Samba Print Server</h3></div></div><div></div></div><p>
Here is a simple recipe showing how you can take advantage of CUPS
powerful features for the benefit of your Windows network printing
clients:
</p><div class="itemizedlist"><ul type="disc"><li><p>Let the Windows clients send PostScript to the CUPS
server.</p></li><li><p>Let the CUPS server render the PostScript into device
specific raster format.</p></li></ul></div><p>
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.
</p><p>
Firstly, to enable CUPS based printing through Samba the
following options should be set in your <tt class="filename">smb.conf</tt> file [globals]
section:
</p><div class="itemizedlist"><ul type="disc"><li><p><i class="parameter"><tt>printing = CUPS</tt></i></p></li><li><p><i class="parameter"><tt>printcap = CUPS</tt></i></p></li></ul></div><p>
When these parameters are specified, all manually set print directives
(like <i class="parameter"><tt>print command =...</tt></i>, or <i class="parameter"><tt>lppause
command =...</tt></i>) in <tt class="filename">smb.conf</tt> (as well as
in samba itself) will be ignored. Instead, Samba will directly
interface with CUPS through it's 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
<span class="emphasis"><em>System V</em></span> AT&T command set, with the -oraw
option automatically passing through (if you want your own defined
print commands to work with a Samba that has CUPS support compiled in,
simply use <i class="parameter"><tt>printing = sysv</tt></i>).
</p><p>
</p><div class="figure"><a name="id2958439"></a><p class="title"><b>Figure 19.13. Printing via CUPS/samba server</b></p><div class="mediaobject"><img src="projdoc/imagefiles/13small.png" alt="Printing via CUPS/samba server"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958474"></a>Samba receiving Jobfiles and passing them to CUPS</h3></div></div><div></div></div><p>
Samba <span class="emphasis"><em>must</em></span> use its own spool directory (it is set
by a line similar to <i class="parameter"><tt>path = /var/spool/samba</tt></i>,
in the <i class="parameter"><tt>[printers]</tt></i> or
<i class="parameter"><tt>[printername]</tt></i> section of
<tt class="filename">smb.conf</tt>). Samba receives the job in its own
spool space and passes it into the spool directory of CUPS (the CUPS
spooling directory is set by the <i class="parameter"><tt>RequestRoot</tt></i>
directive, in a line that defaults to <i class="parameter"><tt>RequestRoot
/var/spool/cups</tt></i>). CUPS checks the access rights of its
spool dir and resets it to healthy values with every re-start. We have
seen quite some people who had used a common spooling space for Samba
and CUPS, and were struggling for weeks with this "problem".
</p><p>
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 "localhost" to print. If they run on different machines, you
need to make sure the Samba host gets access to printing on CUPS.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2958550"></a>Network PostScript RIP: CUPS Filters on Server -- clients use
PostScript Driver with CUPS-PPDs</h2></div></div><div></div></div><p>
PPDs can control all print device options. They are usually provided
by the manufacturer; if you own a PostScript printer, that is. PPD
files (PostScript Printer Descriptions) 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
"on-the-fly" into buttons and drop-down lists for the user to select.
</p><p>
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 <a href="http://localhost:631/printers/" target="_top">http://localhost:631/printers/</a>
and click on one <span class="emphasis"><em>Configure Printer</em></span> button to see
it), or a commandline interface (see <b class="command">man lpoptions</b>
or see if you have lphelp on your system). There are also some
different GUI frontends 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.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958605"></a>PPDs for non-PS Printers on UNIX</h3></div></div><div></div></div><p>
CUPS doesn't limit itself to "real" PostScript printers in its usage
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.
</p><p>
This is logical, as 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
<i class="parameter"><tt>*cupsFilter</tt></i> . 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958646"></a>PPDs for non-PS Printers on Windows</h3></div></div><div></div></div><p>
CUPS-PPDs can also be used on Windows-Clients, on top of a
"core" PostScript driver (now recommended is the "CUPS PostScript
Driver for WindowsNT/2K/XP"; you can also use the Adobe one, with
limitations). This feature enables CUPS to do a few tricks no other
spooler can do:
</p><div class="itemizedlist"><ul type="disc"><li><p>act as a networked PostScript RIP (Raster Image
Processor), handling printfiles from all client platforms in a uniform
way;</p></li><li><p>act as a central accounting and billing server, since
all files are passed through the pstops filter and are therefore
logged in the CUPS <tt class="filename">page_log</tt> file.
<span class="emphasis"><em>NOTE:</em></span> this can not happen with "raw" print jobs,
which always remain unfiltered per definition;</p></li><li><p>enable clients to consolidate on a single PostScript
driver, even for many different target printers.</p></li></ul></div><p>
Using CUPS PPDs on Windows clients enables these to control
all print job settings just as a UNIX client can do too.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2958712"></a>Windows Terminal Servers (WTS) as CUPS Clients</h2></div></div><div></div></div><p>
This setup may be of special interest to people experiencing major
problems in WTS environments. WTS need often 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.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958729"></a>Printer Drivers running in "Kernel Mode" cause many
Problems</h3></div></div><div></div></div><p>
The reason is that in Win NT printer drivers run in "Kernel
Mode", this introduces 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 "Blue Screens
of Death" on a regular basis?
</p><p>
PostScript drivers generally are very well tested. They are not known
to cause any problems, even though they run in Kernel Mode too. This
might be because there have so far only been 2 different PostScript
drivers the ones from Adobe and the one from Microsoft. Both are
very well tested and are as stable as you ever can imagine on
Windows. The CUPS driver is derived from the Microsoft one.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958763"></a>Workarounds impose Heavy Limitations</h3></div></div><div></div></div><p>
In many cases, in an attempt to work around this problem, site
administrators have resorted to restrict the allowed drivers installed
on their WTS to one generic PCL- and one PostScript driver. This
however restricts the clients in the amount of printer options
available for them; 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! )
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958784"></a>CUPS: a "Magical Stone"?</h3></div></div><div></div></div><p>
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 3 different PostScript
drivers 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)
chose 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 "raw spooling" device. Plus, this setup is not yet widely tested,
although the first feedbacks look very promising.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958811"></a>PostScript Drivers with no major problems -- even in Kernel
Mode</h3></div></div><div></div></div><p>
More recent printer drivers on W2K and XP don't run in Kernel mode
(unlike Win NT) any more. 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 "2" of "W32X86" are "old"
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 Win 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 doesn't allow them to publish the whole of the source code.
However, they have released the "diff" under the GPL, and if you are
owner of an "MS DDK for Win NT", you can check the driver yourself.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2958865"></a> Setting up CUPS for driver Download</h2></div></div><div></div></div><p>
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 the previous chapter. In reality, this is a
pure Samba business, and only relates to the Samba/Win client
relationship.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958884"></a><span class="emphasis"><em>cupsaddsmb</em></span>: the unknown Utility</h3></div></div><div></div></div><p>
The cupsaddsmb utility (shipped with all current CUPS versions) is an
alternative method to transfer printer drivers into the Samba
<i class="parameter"><tt>[print$]</tt></i> share. Remember, this share is where
clients expect drivers deposited and setup for download and
installation. It makes the sharing of any (or all) installed CUPS
printers very easy. cupsaddsmb can use the Adobe PostScript driver as
well as the newly developed <span class="emphasis"><em>CUPS PostScript Driver for
WinNT/2K/XP</em></span>. Note, that cupsaddsmb does
<span class="emphasis"><em>not</em></span> work with arbitrary vendor printer drivers,
but only with the <span class="emphasis"><em>exact</em></span> driver files that are
named in its man page.
</p><p>
The CUPS printer driver is available from the CUPS download site. Its
package name is <tt class="filename">cups-samba-[version].tar.gz</tt> . It
is preferred over the Adobe drivers since it has a number of
advantages:
</p><div class="itemizedlist"><ul type="disc"><li><p>it supports a much more accurate page
accounting;</p></li><li><p>it supports banner pages, and page labels on all
printers;</p></li><li><p>it supports the setting of a number of job IPP
attributes (such as job-priority, page-label and
job-billing)</p></li></ul></div><p>
However, currently only Windows NT, 2000, and XP are supported by the
CUPS drivers. You will need to get the respective part of Adobe driver
too if you need to support Windows 95, 98, and ME clients.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2958976"></a>Prepare your <tt class="filename">smb.conf</tt> for
cupsaddsmb</h3></div></div><div></div></div><p>
Prior to running cupsaddsmb, you need the following settings in
<tt class="filename">smb.conf</tt>:
</p><pre class="screen">
[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
public = yes
guest ok = yes # setting depends on your requirements
writable = no
printable = yes
printer admin = root
[print$]
comment = Printer Drivers
path = /etc/samba/drivers
browseable = yes
guest ok = no
read only = yes
write list = root
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959022"></a>CUPS Package of "PostScript Driver for WinNT/2k/XP"</h3></div></div><div></div></div><p>
CUPS users may get the exactly same packages from<a href="http://www.cups.org/software.html" target="_top"><span class="emphasis"><em>http://www.cups.org/software.html</em></span></a>.
It is a separate package from the CUPS base software files, tagged as
<span class="emphasis"><em>CUPS 1.1.x Windows NT/2k/XP Printer Driver for SAMBA
(tar.gz, 192k)</em></span>. The filename to download is
<tt class="filename">cups-samba-1.1.x.tar.gz</tt>. Upon untar-/unzip-ing,
it will reveal these files:
</p><pre class="screen">
# tar xvzf cups-samba-1.1.19.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss
</pre><p>
These have been packaged with the ESP meta packager software
"EPM". The <tt class="filename">*.install</tt> and
<tt class="filename">*.remove</tt> files are simple shell scripts, which
untars the <tt class="filename">*.ss</tt> (the <tt class="filename">*.ss</tt> is
nothing else but a tar-archive, which can be untar-ed by "tar"
too). Then it puts the content into
<tt class="filename">/usr/share/cups/drivers/</tt>. This content includes 3
files:
</p><pre class="screen">
# tar tv cups-samba.ss
cupsdrvr.dll
cupsui.dll
cups.hlp
</pre><p>
The <span class="emphasis"><em>cups-samba.install</em></span> shell scripts is easy to
handle:
</p><pre class="screen">
# ./cups-samba.install
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.
</pre><p>
The script should automatically put the driver files into the
<tt class="filename">/usr/share/cups/drivers/</tt> directory.
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
Due to a bug, one recent CUPS release puts the
<tt class="filename">cups.hlp</tt> driver file
into<tt class="filename">/usr/share/drivers/</tt> instead of
<tt class="filename">/usr/share/cups/drivers/</tt>. To work around this,
copy/move the file (after running the
<b class="command">./cups-samba.install</b> script) manually to the
right place.
</p></div><pre class="screen">
cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
</pre><p>
This new CUPS PostScript driver is currently binary-only, but free of
charge. No complete source code is provided (yet). The reason is this:
it has been developed with the help of the <span class="emphasis"><em>Microsoft Driver
Developer Kit</em></span> (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 "diff" in source code under the GPL, so anybody with a license of
Visual Studio and a DDK will be able to compile for him/herself.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959220"></a>Recognize the different Driver Files</h3></div></div><div></div></div><p>
The CUPS drivers don't support the "older" Windows 95/98/ME, but only
the Windows NT/2000/XP client:
</p><pre class="screen">
[Windows NT, 2000, and XP are supported by:]
cups.hlp
cupsdrvr.dll
cupsui.dll
</pre><p>
Adobe drivers are available for the older Windows 95/98/ME as well as
the Windows NT/2000/XP clients. The set of files is different for the
different platforms.
</p><pre class="screen">
[Windows 95, 98, and Me are supported by:]
ADFONTS.MFM
ADOBEPS4.DRV
ADOBEPS4.HLP
DEFPRTR2.PPD
ICONLIB.DLL
PSMON.DLL
[Windows NT, 2000, and XP are supported by:]
ADOBEPS5.DLL
ADOBEPSU.DLL
ADOBEPSU.HLP
</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
If both, the Adobe driver files and the CUPS driver files for the
support of WinNT/2k/XP are present in , the Adobe ones will be ignored
and the CUPS ones will be used. If you prefer -- for whatever reason
-- to use Adobe-only drivers, move away the 3 CUPS driver files. The
Win95/98/ME clients use the Adobe drivers in any case.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959278"></a>Acquiring the Adobe Driver Files</h3></div></div><div></div></div><p>
Acquiring the Adobe driver files seems to be unexpectedly difficult
for many users. They are not available on the Adobe website as single
files and the self-extracting and/or self-installing Windows-exe is
not easy to locate either. Probably you 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
<i class="parameter"><tt>[print$]</tt></i> share holds the Adobe files, from
where you can get them with smbclient from the CUPS host. A more
detailed description about this is in the next (the CUPS printing)
chapter.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959310"></a>ESP Print Pro Package of "PostScript Driver for
WinNT/2k/XP"</h3></div></div><div></div></div><p>
Users of the ESP Print Pro software are able to install their "Samba
Drivers" package for this purpose with no problem. Retrieve the driver
files from the normal download area of the ESP Print Pro software
at<a href="http://www.easysw.com/software.html" target="_top">http://www.easysw.com/software.html</a>.
You need to locate the link labelled "SAMBA" amongst the
<span class="emphasis"><em>Download Printer Drivers for ESP Print Pro 4.x</em></span>
area and download the package. Once installed, you can prepare any
driver by simply highlighting the printer in the Printer Manager GUI
and select <span class="emphasis"><em>Export Driver...</em></span> from the menu. Of
course you need to have prepared Samba beforehand too to handle the
driver files; i.e. mainly setup the <i class="parameter"><tt>[print$]</tt></i>
share, etc. 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.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959360"></a>Caveats to be considered</h3></div></div><div></div></div><p>
Once you have run the install script (and possibly manually
moved the <tt class="filename">cups.hlp</tt> file to
<tt class="filename">/usr/share/cups/drivers/</tt>), the driver is
ready to be put into Samba's <i class="parameter"><tt>[print$]</tt></i> share (which often maps to
<tt class="filename">/etc/samba/drivers/</tt> and contains a subdir
tree with <span class="emphasis"><em>WIN40</em></span> and
<span class="emphasis"><em>W32X86</em></span> branches): You do this by running
"cupsaddsmb" (see also <b class="command">man cupsaddsmb</b> for
CUPS since release 1.1.16).
</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>
You may need to put root into the smbpasswd file by running
<b class="command">smbpasswd</b>; 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
<span class="emphasis"><em>Single Sign On</em></span> to a Windows Domain Controller.
</p></div><p>
Once the driver files are in the <i class="parameter"><tt>[print$]</tt></i> share
and are initialized, they are ready to be downloaded and installed by
the Win NT/2k/XP clients.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
</p><div class="orderedlist"><ol type="1"><li><p>
Win 9x/ME clients won't work with the CUPS PostScript driver. For
these you'd still need to use the <tt class="filename">ADOBE*.*</tt>
drivers as previously.
</p></li><li><p>
It is not harmful if you still have the
<tt class="filename">ADOBE*.*</tt> driver files from previous
installations in the <tt class="filename">/usr/share/cups/drivers/</tt>
directory. The new <span class="emphasis"><em>cupsaddsmb</em></span> (from 1.1.16) will
automatically prefer "its own" drivers if it finds both.
</p></li><li><p>
Should your Win clients have had the old <tt class="filename">ADOBE*.*</tt>
files for the Adobe PostScript driver installed, the download and
installation of the new CUPS PostScript driver for Windows NT/2k/XP
will fail at first. You need to wipe the old driver from the clients
first. It is not enough to "delete" the printer, as 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 "Printers" folder (possibly via <span class="emphasis"><em>Start
--> Settings --> Control Panel --> Printers</em></span>),
right-click onto the folder background and select <span class="emphasis"><em>Server
Properties</em></span>. When the new dialog opens, select the
<span class="emphasis"><em>Drivers</em></span> tab. On the list select the driver you
want to delete and click on the <span class="emphasis"><em>Delete</em></span>
button. This will only work if there is not one single printer left
which uses that particular driver. You need to "delete" all printers
using this driver in the "Printers" folder first. You will need
Administrator privileges to do this.
</p></li><li><p>
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 elsewhere in the "Samba HOWTO Collection": either change
a driver for an existing printer by running the "Printer Properties"
dialog, or use <b class="command">rpcclient</b> with the
<b class="command">setdriver</b> sub-command.
</p></li></ol></div><p>
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959582"></a>What are the Benefits of using the "CUPS PostScript Driver for
Windows NT/2k/XP" as compared to the Adobe Driver?</h3></div></div><div></div></div><p>
You are interested in a comparison between the CUPS and the Adobe
PostScript drivers? For our purposes these are the most important
items which weigh in favor of the CUPS ones:
</p><div class="itemizedlist"><ul type="disc"><li><p>no hassle with the Adobe EULA</p></li><li><p>no hassle with the question “<span class="quote">Where do I
get the ADOBE*.* driver files from?</span>”</p></li><li><p>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 printfile starts with
<i class="parameter"><tt><1B >%-12345X</tt></i> or
<i class="parameter"><tt><escape>%-12345X</tt></i> instead
of <i class="parameter"><tt>%!PS</tt></i>). This leads to the
CUPS daemon auto-typing the incoming file as a print-ready file,
not initiating a pass through the "pstops" filter (to speak more
technically, it is not regarded as the generic MIME type
<span class="emphasis"><em>application/postscript</em></span>, but as
the more special MIME type
<span class="emphasis"><em>application/cups.vnd-postscript</em></span>),
which therefore also leads to the page accounting in
<span class="emphasis"><em>/var/log/cups/page_log</em></span> not
receiving the exact number of pages; instead the dummy page number
of "1" is logged in a standard setup)</p></li><li><p>the Adobe driver has more options to "mis-configure" the
PostScript generated by it (like setting it inadvertently to
<span class="emphasis"><em>Optimize for Speed</em></span>, instead of
<span class="emphasis"><em>Optimize for Portability</em></span>, which
could lead to CUPS being unable to process it)</p></li><li><p>the CUPS PostScript driver output sent by Windows
clients to the CUPS server will be guaranteed to be auto-typed always
as generic MIME type <span class="emphasis"><em>application/postscript</em></span>,
thusly passing through the CUPS "pstops" filter and logging the
correct number of pages in the <tt class="filename">page_log</tt> for
accounting and quota purposes</p></li><li><p>the CUPS PostScript driver supports the sending of
additional standard (IPP) print options by Win NT/2k/XP clients. Such
additional print options are: naming the CUPS standard
<span class="emphasis"><em>banner pages</em></span> (or the custom ones, should they be
installed at the time of driver download), using the CUPS
<span class="emphasis"><em>page-label</em></span> option, setting a
<span class="emphasis"><em>job-priority</em></span> and setting the <span class="emphasis"><em>scheduled
time of printing</em></span> (with the option to support additional
useful IPP job attributes in the future).</p></li><li><p>the CUPS PostScript driver supports the inclusion of
the new <span class="emphasis"><em>*cupsJobTicket</em></span> comments at the
beginning of the PostScript file (which could be used in the future
for all sort of beneficial extensions on the CUPS side, but which will
not disturb any other applications as they will regard it as a comment
and simply ignore it).</p></li><li><p>the CUPS PostScript driver will be the heart of the
fully fledged CUPS IPP client for Windows NT/2K/XP to be released soon
(probably alongside the first Beta release for CUPS
1.2).</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959764"></a>Run "cupsaddsmb" (quiet Mode)</h3></div></div><div></div></div><p>
The cupsaddsmb command copies the needed files into your
<i class="parameter"><tt>[print$]</tt></i> share. Additionally, the PPD
associated with this printer is copied from
<tt class="filename">/etc/cups/ppd/</tt> to
<i class="parameter"><tt>[print$]</tt></i>. 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
towards Samba. If you have a small network you are probably using user
level security (<i class="parameter"><tt>security = user</tt></i>). Probably your
root has already a Samba account. Otherwise, create it now, using
<b class="command">smbpasswd</b>:
</p><pre class="screen">
# smbpasswd -a root
New SMB password: [type in password 'secret']
Retype new SMB password: [type in password 'secret']
</pre><p>
Here is an example of a successfully run cupsaddsmb command.
</p><pre class="screen">
# cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via SAMBA: [type in password 'secret']
</pre><p>
To share <span class="emphasis"><em>all</em></span> printers and drivers, use the
<i class="parameter"><tt>-a</tt></i> parameter instead of a printer name. Since
cupsaddsmb "exports" the printer drivers to Samba, it should be
obvious that it only works for queues with a CUPS driver associated.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2959865"></a>Run "cupsaddsmb" with verbose Output</h3></div></div><div></div></div><p>
Probably you want to see what's going on. Use the
<i class="parameter"><tt>-v</tt></i> parameter to get a more verbose output. The
output below was edited for better readability: all "\" at the end of
a line indicate that I inserted an artificial line break plus some
indentation here:
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>
You will see the root password for the Samba account printed on
screen. If you use remote access, the password will go over the wire
unencrypted!
</p></div><pre class="screen">
# cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via 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 (2328.8 kb/s) \
(average 2328.8 kb/s)
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll (9374.3 kb/s) \
(average 5206.6 kb/s)
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll (8107.2 kb/s) \
(average 5984.1 kb/s)
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp (3475.0 kb/s) \
(average 5884.7 kb/s)
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 (2328.8 kb/s) \
(average 2328.8 kb/s)
putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (9368.0 kb/s) \
(average 6469.6 kb/s)
putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (9958.2 kb/s) \
(average 8404.3 kb/s)
putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (8341.5 kb/s) \
(average 8398.6 kb/s)
putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (2195.9 kb/s) \
(average 8254.3 kb/s)
putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (8239.9 kb/s) \
(average 8253.6 kb/s)
putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (6222.2 kb/s) \
(average 8188.5 kb/s)
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.
</pre><p>
If you look closely, you'll discover your root password was transfered
unencrypted over the wire, so beware! Also, if you look further her,
you'll discover error messages like NT_STATUS_OBJECT_NAME_COLLISION in
between. They occur, because the directories WIN40 and W32X86 already
existed in the <i class="parameter"><tt>[print$]</tt></i> driver download share
(from a previous driver installation). They are harmless here.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960092"></a>Understanding cupsaddsmb</h3></div></div><div></div></div><p>
What has happened? What did cupsaddsmb do? There are five stages of
the procedure
</p><div class="orderedlist"><ol type="1"><li><p>call the CUPS server via IPP and request the
driver files and the PPD file for the named printer;</p></li><li><p>store the files temporarily in the local
TEMPDIR (as defined in
<tt class="filename">cupsd.conf</tt>);</p></li><li><p>connect via smbclient to the Samba server's
<i class="parameter"><tt>[print$]</tt></i> share and put the files into the
share's WIN40 (for Win95/98/ME) and W32X86/ (for WinNT/2k/XP) sub
directories;</p></li><li><p>connect via rpcclient to the Samba server and
execute the "adddriver" command with the correct
parameters;</p></li><li><p>connect via rpcclient to the Samba server a second
time and execute the "setdriver" command.</p></li></ol></div><p>
Note, that you can run the cupsaddsmb 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 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):
</p><pre class="screen">
# cupsaddsmb -H sambaserver -h cupsserver -v printername
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960186"></a>How to recognize if cupsaddsm completed successfully</h3></div></div><div></div></div><p>
You <span class="emphasis"><em>must</em></span> always check if the utility completed
successfully in all fields. You need as a minimum these 3 messages
amongst the output:
</p><div class="orderedlist"><ol type="1"><li><p><span class="emphasis"><em>Printer Driver infotec_2105 successfully
installed.</em></span> # (for the W32X86 == WinNT/2K/XP
architecture...)</p></li><li><p><span class="emphasis"><em>Printer Driver infotec_2105 successfully
installed.</em></span> # (for the WIN40 == Win9x/ME
architecture...)</p></li><li><p><span class="emphasis"><em>Successfully set [printerXPZ] to driver
[printerXYZ].</em></span></p></li></ol></div><p>
These messages probably not easily recognized in the general
output. If you run cupsaddsmb with the <i class="parameter"><tt>-a</tt></i>
parameter (which tries to prepare <span class="emphasis"><em>all</em></span> active CUPS
printer drivers for download), you might miss if individual printers
drivers had problems to install properly. Here a redirection of the
output will help you analyze the results in retrospective.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
It is impossible to see any diagnostic output if you don't run
cupsaddsmb in verbose mode. Therefore we strongly recommend to not
use the default quiet mode. It will hide any problems from you which
might occur.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960273"></a>cupsaddsmb with a Samba PDC</h3></div></div><div></div></div><p>
You can't get the standard cupsaddsmb command to run on a Samba PDC?
You are asked for the password credential all over again and again and
the command just will not take off at all? Try one of these
variations:
</p><pre class="screen">
# cupsaddsmb -U DOMAINNAME\\root -v printername
# cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -v printername
# cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -h cups-server -v printername
</pre><p>
(Note the two backslashes: the first one is required to
"escape" the second one).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960308"></a>cupsaddsmb Flowchart</h3></div></div><div></div></div><p>
Here is a chart about the procedures, commandflows and
dataflows of the "cupaddsmb" command. Note again: cupsaddsmb is
not intended to, and does not work with, "raw" queues!
</p><p>
</p><div class="figure"><a name="id2960326"></a><p class="title"><b>Figure 19.14. cupsaddsmb flowchart</b></p><div class="mediaobject"><img src="projdoc/imagefiles/1small.png" alt="cupsaddsmb flowchart"></div></div><p>
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960361"></a>Installing the PostScript Driver on a Client</h3></div></div><div></div></div><p>
After cupsaddsmb 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;
</p><div class="itemizedlist"><ul type="disc"><li><p>open the <span class="emphasis"><em>Printers</em></span>
share of Samba in Network Neighbourhood;</p></li><li><p>right-click on the printer in
question;</p></li><li><p>from the opening context-menu select
<span class="emphasis"><em>Install...</em></span> or
<span class="emphasis"><em>Connect...</em></span> (depending on the Windows version you
use).</p></li></ul></div><p>
After a few seconds, there should be a new printer in your
client's <span class="emphasis"><em>local</em></span> "Printers" folder: On Windows
XP it will follow a naming convention of <span class="emphasis"><em>PrinterName on
SambaServer</em></span>. (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 will appears in a
<tt class="filename">\\SambaServer\PrinterName</tt> entry in the
dropdown list of available printers.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher
and Samba from 2.2.4. If it doesn't work, or if the automatic printer
driver download to the clients doesn't 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:
</p></div><pre class="screen">
net use lpt1: \\sambaserver\printershare /user:ntadmin
</pre><p>
should you desire to use the CUPS networked PostScript RIP
functions. (Note that user "ntadmin" needs to be a valid Samba user
with the required privileges to access the printershare) This would
set up the printer connection in the traditional
<span class="emphasis"><em>LanMan</em></span> way (not using MS-RPC).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960474"></a>Avoiding critical PostScript Driver Settings on the
Client</h3></div></div><div></div></div><p>
Soooo: printing works, but there are still problems. Most jobs print
well, some don't print at all. Some jobs have problems with fonts,
which don't 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:
</p><div class="itemizedlist"><ul type="disc"><li><p>Avoid the <span class="emphasis"><em>PostScript Output Option: Optimize
for Speed</em></span> setting. Rather use the <span class="emphasis"><em>Optimize for
Portability</em></span> instead (Adobe PostScript
driver).</p></li><li><p>Don't use the <span class="emphasis"><em>Page Independence:
NO</em></span> setting. Instead use <span class="emphasis"><em>Page Independence
YES</em></span> (CUPS PostScript Driver)</p></li><li><p>Recommended is the <span class="emphasis"><em>True Type Font
Downloading Option: Native True Type</em></span> over
<span class="emphasis"><em>Automatic</em></span> and <span class="emphasis"><em>Outline</em></span>; you
should by all means avoid <span class="emphasis"><em>Bitmap</em></span> (Adobe
PostScript Driver)</p></li><li><p>Choose <span class="emphasis"><em>True Type Font: Download as Softfont
into Printer</em></span> over the default <span class="emphasis"><em>Replace by Device
Font</em></span> (for exotic fonts you may need to change it back to
get a printout at all) (Adobe)</p></li><li><p>Sometimes you can choose <span class="emphasis"><em>PostScript Language
Level</em></span>: in case of problems try <span class="emphasis"><em>2</em></span>
instead of <span class="emphasis"><em>3</em></span> (the latest ESP Ghostscript package
handles Level 3 PostScript very well) (Adobe).</p></li><li><p>Say <span class="emphasis"><em>Yes</em></span> to <span class="emphasis"><em>PostScript
Error Handler</em></span> (Adobe)</p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2960608"></a>Installing PostScript Driver Files manually (using
rpcclient)</h2></div></div><div></div></div><p>
Of course you can run all the commands which are embedded into the
cupsaddsmb convenience utility yourself, one by one, and hereby upload
and prepare the driver files for future client downloads.
</p><div class="orderedlist"><ol type="1"><li><p>prepare Samba (a CUPS printqueue with the name of the
printer should be there. We are providing the driver
now);</p></li><li><p>copy all files to
<i class="parameter"><tt>[print$]:</tt></i></p></li><li><p>run <b class="command">rpcclient adddriver</b>
(for each client architecture you want to support):</p></li><li><p>run <b class="command">rpcclient
setdriver.</b></p></li></ol></div><p>
We are going to do this now. First, read the man page on "rpcclient"
to get a first idea. Look at all the printing related
sub-commands. <b class="command">enumprinters</b>,
<b class="command">enumdrivers</b>, <b class="command">enumports</b>,
<b class="command">adddriver</b>, <b class="command">setdriver</b> are amongst
the most interesting ones. rpcclient implements an important part of
the MS-RPC protocol. You can use it to query (and command) a Win NT
(or 2K/XP) PC too. MS-RPC is used by Windows clients, amongst other
things, to benefit from the "Point'n'Print" features. Samba can now
mimic this too.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960723"></a>A Check of the rpcclient man Page</h3></div></div><div></div></div><p>
First let's have a little check of the rpcclient man page. Here are
two relevant passages:
</p><p>
<b class="command">adddriver <arch> <config></b> Execute an
AddPrinterDriver() RPC to install the printer driver information on
the server. Note that the driver files should already exist in the
directory returned by <b class="command">getdriverdir</b>. Possible
values for <i class="parameter"><tt>arch</tt></i> are the same as those for the
<b class="command">getdriverdir</b> command. The
<i class="parameter"><tt>config</tt></i> parameter is defined as follows:
</p><pre class="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
</pre><p>Any empty fields should be enter as the string "NULL". </p><p>Samba does not need to support the concept of Print Monitors
since these only apply to local printers whose driver can make use of
a bi-directional link for communication. This field should be "NULL".
On a remote NT print server, the Print Monitor for a driver must
already be installed prior to adding the driver or else the RPC will
fail
</p><p>
<b class="command">setdriver <printername> <drivername></b>
Execute a <b class="command">SetPrinter()</b> command to update the
printer driver associated with an installed printer. The printer
driver must already be correctly installed on the print server.
</p><p> See also the enumprinters and enumdrivers commands for
obtaining a list of installed printers and drivers.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960836"></a>Understanding the rpcclient man Page</h3></div></div><div></div></div><p>
The <span class="emphasis"><em>exact</em></span> 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 "\". Usually you would type the
command in one line without the linebreaks:
</p><pre class="screen">
adddriver "Architecture" \
"LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"
</pre><p>
What the man pages denotes as a simple <config>
keyword, does in reality consist of 8 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.
Note, that what the man pages names the "LongPrinterName" in
reality should rather be called the "Driver Name". You can name it
anything you want, as long as you use this name later in the
<span class="emphasis"><em>rpcclient ... setdriver</em></span> command. For
practical reasons, many name the driver the same as the
printer.
</p><p>
True: it isn't simple at all. I hear you asking:
<span class="emphasis"><em>How do I know which files are "Driver
File", "Data File", "Config File", "Help File" and "Language
Monitor File" in each case?</em></span> -- 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 overhearing 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 <b class="command">rpcclient</b> to see what it tells us and
try to understand the man page more clearly which we've read just
now.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2960925"></a>Producing an Example by querying a Windows Box</h3></div></div><div></div></div><p>
We could run <b class="command">rpcclient</b> with a
<b class="command">getdriver</b> or a <b class="command">getprinter</b>
subcommand (in level 3 verbosity) against it. Just sit down at UNIX or
Linux workstation with the Samba utilities installed. Then type the
following command:
</p><pre class="screen">
rpcclient -U'USERNAME%PASSWORD' NT-SERVER-NAME -c 'getdriver printername 3'
</pre><p>
From the result it should become clear which is which. Here is an
example from my installation:
</p><pre class="screen">
# rpcclient -U'Danka%xxxx' W2KSERVER -c'getdriver "DANKA InfoStream Virtual Printer" 3'
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: []
</pre><p>
Some printer drivers list additional files under the label
"Dependentfiles": these would go into the last field
<span class="emphasis"><em>ListOfFiles,Comma-separated</em></span>. For the CUPS
PostScript drivers we don't need any (nor would we for the Adobe
PostScript driver): therefore the field will get a "NULL" entry.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961015"></a>What is required for adddriver and setdriver to succeed</h3></div></div><div></div></div><p>
From the manpage (and from the quoted output
of <span class="emphasis"><em>cupsaddsmb</em></span>, 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 rpcclient
subcommands (<b class="command">adddriver</b> and
<b class="command">setdriver</b>) need to encounter the following
pre-conditions to complete successfully:
</p><div class="itemizedlist"><ul type="disc"><li><p>you are connected as "printer admin", or root (note,
that this is <span class="emphasis"><em>not</em></span> the "Printer Operators" group in
NT, but the <span class="emphasis"><em>printer admin</em></span> group, as defined in
the <i class="parameter"><tt>[global]</tt></i> section of
<tt class="filename">smb.conf</tt>);</p></li><li><p>copy all required driver files to
<tt class="filename">\\sambaserver\print$\w32x86</tt> and
<tt class="filename">\\sambaserver\print$\win40</tt> as appropriate. They
will end up in the "0" respective "2" subdirectories later -- for now
<span class="emphasis"><em>don't</em></span> put them there, they'll be automatically
used by the <b class="command">adddriver</b> subcommand.! (if you use
"smbclient" to put the driver files into the share, note that you need
to escape the "$": <b class="command">smbclient //sambaserver/print\$ -U
root</b>);</p></li><li><p>the user you're connecting as must be able to write to
the <i class="parameter"><tt>[print$]</tt></i> share and create
subdirectories;</p></li><li><p>the printer you are going to setup for the Windows
clients, needs to be installed in CUPS already;</p></li><li><p>the CUPS printer must be known to Samba, otherwise the
<b class="command">setdriver</b> subcommand fails with an
NT_STATUS_UNSUCCESSFUL error. To check if the printer is known by
Samba you may use the <b class="command">enumprinters</b> subcommand to
rpcclient. 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
shortly ago and encounter problems: try restarting
Samba.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961177"></a>Manual Commandline Driver Installation in 15 little Steps</h3></div></div><div></div></div><p>
We are going to install a printer driver now by manually executing all
required commands. As 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.
</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961194"></a>First Step: Install the Printer on CUPS</h4></div></div><div></div></div><pre class="screen">
# lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E -P /home/kurt/canonIR85.ppd
</pre><p>
This installs printer with the name <span class="emphasis"><em>mysmbtstprn</em></span>
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
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961224"></a>Second Step (optional): Check if the Printer is recognized by
Samba</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep -C2 mysmbtstprn
flags:[0x800000]
name:[\\kde-bitshop\mysmbtstprn]
description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn]
comment:[mysmbtstprn]
</pre><p>
This should show the printer in the list. If not, stop and re-start
the Samba daemon (smbd), or send a HUP signal: <b class="command">kill -HUP
`pidof smbd`</b>. Check again. Troubleshoot and repeat until
success. Note the "empty" field between the two commas in the
"description" line. Here would the driver name appear if there was one
already. You need to know root's Samba password (as set by the
<b class="command">smbpasswd</b> command) for this step and most of the
following steps. Alternatively you can authenticate as one of the
users from the "write list" as defined in <tt class="filename">smb.conf</tt> for
<i class="parameter"><tt>[print$]</tt></i>.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961288"></a>Third Step (optional): Check if Samba knows a Driver for the
Printer</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver
drivername:[]
# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv
servername:[\\kde-bitshop]
printername:[\\kde-bitshop\mysmbtstprn]
sharename:[mysmbtstprn]
portname:[Samba Printer Port]
drivername:[]
comment:[mysmbtstprn]
location:[]
sepfile:[]
printprocessor:[winprint]
# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
result was WERR_UNKNOWN_PRINTER_DRIVER
</pre><p>
Neither method 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 the
message along the lines: "The server has not the required printer
driver installed".
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961326"></a>Fourth Step: Put all required Driver Files into Samba's
[print$]</h4></div></div><div></div></div><pre class="screen">
# 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'
</pre><p>
(Note that this command should be entered in one long single
line. Line-breaks and the line-end indicating "\" has been inserted
for readability reasons.) This step is <span class="emphasis"><em>required</em></span>
for the next one to succeed. It makes the driver files physically
present in the <i class="parameter"><tt>[print$]</tt></i> 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 "not installed here" message.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961377"></a>Fifth Step: Verify where the Driver Files are now</h4></div></div><div></div></div><pre class="screen">
# ls -l /etc/samba/drivers/W32X86/
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
</pre><p>
The driver files now are in the W32X86 architecture "root" of
<i class="parameter"><tt>[print$]</tt></i>.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961415"></a>Sixth Step: Tell Samba that these are
<span class="emphasis"><em>Driver</em></span> Files
(<b class="command">adddriver</b>)</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c `adddriver "Windows NT x86" "mydrivername: \
cupsdrvr.dll:mysmbtstprn.PPD: \
cupsui.dll:cups.hlp:NULL:RAW[<span class="citation">:</span>]NULL" \
localhost
Printer Driver mydrivername successfully installed.
</pre><p>
Note that your 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 "2" 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 printername; however, in big installations you may use this driver
for a number of printers which have obviously different names. So the
name of the driver is not fixed.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961469"></a>Seventh Step: Verify where the Driver Files are now</h4></div></div><div></div></div><pre class="screen">
# ls -l /etc/samba/drivers/W32X86/
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
# ls -l /etc/samba/drivers/W32X86/2
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
</pre><p>
Notice how step 6 did also move the driver files to the appropriate
subdirectory. Compare with the situation after step 5.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961503"></a>Eighth Step (optional): Verify if Samba now recognizes the
Driver</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c 'enumdrivers 3' localhost | grep -B2 -A5 mydrivername
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]
</pre><p>
Remember, this command greps for the name you did choose for the
driver in step Six. This command must succeed before you can proceed.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961536"></a>Ninth Step: Tell Samba which Printer should use these Driver
Files (<b class="command">setdriver</b>)</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' localhost
Successfully set mysmbtstprn to driver mydrivername
</pre><p>
Since you can bind any printername (=printqueue) to any driver, this
is a very convenient way to setup many queues which use the same
driver. You don't need to repeat all the previous steps for the
setdriver command to succeed. The only pre-conditions are:
<b class="command">enumdrivers</b> must find the driver and
<b class="command">enumprinters</b> must find the printer.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961586"></a>Tenth Step (optional): Verify if Samba has this Association
recognized</h4></div></div><div></div></div><pre class="screen">
# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver
drivername:[mydrivername]
# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv
servername:[\\kde-bitshop]
printername:[\\kde-bitshop\mysmbtstprn]
sharename:[mysmbtstprn]
portname:[Done]
drivername:[mydrivername]
comment:[mysmbtstprn]
location:[]
sepfile:[]
printprocessor:[winprint]
# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
[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]
# rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep mysmbtstprn
name:[\\kde-bitshop\mysmbtstprn]
description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn]
comment:[mysmbtstprn]
</pre><p>
Compare these results with the ones from steps 2 and 3. Note that
every single of these commands show the driver is installed. Even
the <b class="command">enumprinters</b> command now lists the driver
on the "description" line.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961666"></a>Eleventh Step (optional): Tickle the Driver into a correct
Device Mode</h4></div></div><div></div></div><p>
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 Neighbourhood, go to the Samba server, 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. An alternative way is to
open the "Printers (and Faxes)" folder, right-click on the printer in
question and select "Connect" or "Install". As a result, a new printer
should have appeared in your client's local "Printers (and Faxes)"
folder, named something like "printersharename on Sambahostname".
</p><p>
It is important that you execute this step as a Samba printer admin
(as defined in <tt class="filename">smb.conf</tt>). Here is another method
to do this on Windows XP. It uses a commandline, which you may type
into the "DOS box" (type root's smbpassword when prompted):
</p><pre class="screen">
C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /in /n \\sambacupsserver\mysmbtstprn"
</pre><p>
Change any printer setting once (like <span class="emphasis"><em>"portrait"
--> "landscape"</em></span>), click "Apply"; change the setting
back.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961731"></a>Twelfth Step: Install the Printer on a Client
("Point'n'Print")</h4></div></div><div></div></div><pre class="screen">
C:\> rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\mysmbtstprn"
</pre><p>
If it doesn't work it could be a permission problem with the
<i class="parameter"><tt>[print$]</tt></i> share.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961764"></a>Thirteenth Step (optional): Print a Test Page</h4></div></div><div></div></div><pre class="screen">
C:\> rundll32 printui.dll,PrintUIEntry /p /n "\\sambacupsserver\mysmbtstprn"
</pre><p>
Then hit [TAB] 5 times, [ENTER] twice, [TAB] once and [ENTER] again
and march to the printer.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961790"></a>Fourteenth Step (recommended): Study the Test Page</h4></div></div><div></div></div><p>
Hmmm.... just kidding! By now you know everything about printer
installations and you don't 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" - why not just throw it away!
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2961808"></a>Fifteenth Step (obligatory): Enjoy. Jump. Celebrate your
Success</h4></div></div><div></div></div><pre class="screen">
# echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd
</pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2961830"></a>Troubleshooting revisited</h3></div></div><div></div></div><p>
The setdriver command will fail, if in Samba's mind the queue is not
already there. You had promising messages about the:
</p><pre class="screen">
Printer Driver ABC successfully installed.
</pre><p>
after the "adddriver" parts of the procedure? But you are also seeing
a disappointing message like this one beneath?
</p><pre class="screen">
result was NT_STATUS_UNSUCCESSFUL
</pre><p>
It is not good enough that <span class="emphasis"><em>you</em></span>
can see the queue <span class="emphasis"><em>in CUPS</em></span>, using
the <b class="command">lpstat -p ir85wm</b> command. A
bug in most recent versions of Samba prevents the proper update of
the queuelist. The recognition of newly installed CUPS printers
fails unless you re-start Samba or send a HUP to all smbd
processes. To verify if this is the reason why Samba doesn't
execute the setdriver command successfully, check if Samba "sees"
the printer:
</p><pre class="screen">
# rpcclient transmeta -N -U'root%secret' -c 'enumprinters 0'| grep ir85wm
printername:[ir85wm]
</pre><p>
An alternative command could be this:
</p><pre class="screen">
# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm'
cmd = getprinter ir85wm
flags:[0x800000]
name:[\\transmeta\ir85wm]
description:[\\transmeta\ir85wm,ir85wm,DPD]
comment:[CUPS PostScript-Treiber for WinNT/2K/XP]
</pre><p>
BTW, you can use these commands, plus a few more, of course,
to install drivers on remote Windows NT print servers too!
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2961930"></a>The printing <tt class="filename">*.tdb</tt> Files</h2></div></div><div></div></div><p>
Some mystery is associated with the series of files with a
tdb-suffix appearing in every Samba installation. They are
<tt class="filename">connections.tdb</tt>,
<tt class="filename">printing.tdb</tt>,
<tt class="filename">share_info.tdb</tt> ,
<tt class="filename">ntdrivers.tdb</tt>,
<tt class="filename">unexpected.tdb</tt>,
<tt class="filename">brlock.tdb</tt> ,
<tt class="filename">locking.tdb</tt>,
<tt class="filename">ntforms.tdb</tt>,
<tt class="filename">messages.tdb</tt> ,
<tt class="filename">ntprinters.tdb</tt>,
<tt class="filename">sessionid.tdb</tt> and
<tt class="filename">secrets.tdb</tt>. What is their purpose?
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962033"></a>Trivial DataBase Files</h3></div></div><div></div></div><p>
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 are saved by writing into
the Registry. Samba and Unix obviously don't have such a kind of
Registry. Samba instead keeps track of all client related information in a
series of <tt class="filename">*.tdb</tt> files. (TDB = Trivial Data
Base). These are often located in <tt class="filename">/var/lib/samba/</tt>
or <tt class="filename">/var/lock/samba/</tt> . The printing related files
are <tt class="filename">ntprinters.tdb</tt>,
<tt class="filename">printing.tdb</tt>,<tt class="filename">ntforms.tdb</tt> and
<tt class="filename">ntdrivers.tdb</tt>.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962103"></a>Binary Format</h3></div></div><div></div></div><p>
<tt class="filename">*.tdb</tt> files are not human readable. They are
written in a binary format. "Why not ASCII?", you may ask. "After all,
ASCII configuration files are a good and proofed tradition on UNIX."
-- The reason for this design decision by the Samba Team is mainly
performance. Samba needs to be fast; it runs a separate
<b class="command">smbd</b> process for each client connection, in some
environments many thousand of them. Some of these smbds might need to
write-access the same <tt class="filename">*.tdb</tt> file <span class="emphasis"><em>at the
same time</em></span>. The file format of Samba's
<tt class="filename">*.tdb</tt> files allows for this provision. Many smbd
processes may write to the same <tt class="filename">*.tdb</tt> file at the
same time. This wouldn't be possible with pure ASCII files.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962165"></a>Losing <tt class="filename">*.tdb</tt> Files</h3></div></div><div></div></div><p>
It is very important that all <tt class="filename">*.tdb</tt> files remain
consistent over all write and read accesses. However, it may happen
that these files <span class="emphasis"><em>do</em></span> get corrupted. (A
<b class="command">kill -9 `pidof smbd`</b> while a write access is in
progress could do the damage as well as a power interruption,
etc.). In cases of trouble, a deletion of the old printing-related
<tt class="filename">*.tdb</tt> files may be the only option. You need to
re-create all print related setup after that. Or you have made a
backup of the <tt class="filename">*.tdb</tt> files in time.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962224"></a>Using <span class="emphasis"><em>tdbbackup</em></span></h3></div></div><div></div></div><p>
Samba ships with a little utility which helps the root user of your
system to back up your <tt class="filename">*.tdb</tt> files. If you run it
with no argument, it prints a little usage message:
</p><pre class="screen">
# tdbbackup
Usage: tdbbackup [options] <fname...>
Version:3.0a
-h this help message
-s suffix set the backup suffix
-v verify mode (restore if corrupt)
</pre><p>
Here is how I backed up my printing.tdb file:
</p><pre class="screen">
# ls
. 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
kde-bitshop:/var/lock/samba # tdbbackup -s .bak printing.tdb
printing.tdb : 135 records
kde-bitshop:/var/lock/samba # ls -l printing.tdb*
-rw------- 1 root root 40960 May 2 03:44 printing.tdb
-rw------- 1 root root 40960 May 2 03:44 printing.tdb.bak
</pre></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2962290"></a>CUPS Print Drivers from Linuxprinting.org</h2></div></div><div></div></div><p>
CUPS ships with good support for HP LaserJet type printers. You can
install the generic driver as follows:
</p><pre class="screen">
lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd
</pre><p>
The <i class="parameter"><tt>-m</tt></i> switch will retrieve the
<tt class="filename">laserjet.ppd</tt> from the standard repository for
not-yet-installed-PPDs, which CUPS typically stores in
<tt class="filename">/usr/share/cups/model</tt>. Alternatively, you may use
<i class="parameter"><tt>-P /path/to/your.ppd</tt></i>.
</p><p>
The generic laserjet.ppd however does not support every special option
for every LaserJet-compatible model. It constitutes a sort of "least
denominator" of all the models. If for some reason it is ruled out to
you to pay for the commercially available ESP Print Pro drivers, your
first move should be to consult the database on <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a>.
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 foomatic-rip utility.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
The former "cupsomatic" concept is now be replaced by the new, much
more powerful "foomatic-rip". foomatic-rip is the successor of
cupsomatic. cupsomatic is no longer maintained. Here is the new URL
to the Foomatic-3.0 database:<a href="http://www.linuxprinting.org/driver_list.cgi" target="_top">http://www.linuxprinting.org/driver_list.cgi</a>.
If you upgrade to foomatic-rip, don't forget to also upgrade to the
new-style PPDs for your foomatic-driven printers. foomatic-rip will
not work with PPDs generated for the old cupsomatic. The new-style
PPDs are 100% compliant to the Adobe PPD specification. They are
intended to be used by Samba and the cupsaddsmb utility also, to
provide the driver files for the Windows clients also!
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2962398"></a>foomatic-rip and Foomatic explained</h3></div></div><div></div></div><p>
Nowadays most Linux distros rely on the utilities of Linuxprinting.org
to create their printing related software (which, BTW, works on all
UNIXes and on Mac OS X or Darwin too). It is not known as well as it
should be, that it also has a very end-user friendly interface which
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.
</p><p>
Recently Foomatic has achieved the astonishing milestone of <a href="http://www.linuxprinting.org/printer_list.cgi?make=Anyone" target="_top">1000
listed</a> 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 <a href="http://www.linuxprinting.org/foomatic.html" target="_top">Foomatic</a>
database. Currently there are <a href="http://www.linuxprinting.org/driver_list.cgi" target="_top">245 drivers</a>
in the database: many drivers support various models, and many models
may be driven by different drivers; it's your choice!
</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962453"></a>690 "perfect" Printers</h4></div></div><div></div></div><p>
At present there are 690 devices dubbed as working "perfectly", 181
"mostly", 96 "partially" and 46 are "Paperweights". Keeping in mind
that most of these are non-PostScript models (PostScript printers are
automatically supported 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
doesn't also scan and copy and fax under GNU/Linux: 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!
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962477"></a>How the "Printing HOWTO" started it all</h4></div></div><div></div></div><p>
A few years ago <a href="http://www2.picante.com:81/~gtaylor/" target="_top">Grant Taylor</a>
started it all. The roots of today's Linuxprinting.org are in the
first <a href="http://www.linuxprinting.org/foomatic2.9/howto/" target="_top">Linux Printing
HOWTO</a> which 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
"applying a structured deposition of distinct patterns of ink or toner
particles on paper substrates" <span class="emphasis"><em>;-)</em></span>, 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.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962522"></a>Foomatic's strange Name</h4></div></div><div></div></div><p>
"Why the funny name?", 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 ("pstoraster", derived from
Ghostscript). On the other hand, CUPS provided brilliant support for
<span class="emphasis"><em>controlling</em></span> all printer options through
standardized and well-defined "PPD files" (PostScript Printers
Description files). Plus, CUPS was designed to be easily extensible.
</p><p>
Grant already had in his database a respectable compilation
of facts about a many more printers, and the Ghostscript "drivers"
they run with. His idea, to generate PPDs from the database info
and use them to make standard Ghostscript filters work within CUPS,
proved to work very well. It also "killed several birds with one
stone":
</p><div class="itemizedlist"><ul type="disc"><li><p>It made all current and future Ghostscript filter
developments available for CUPS;</p></li><li><p>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);</p></li><li><p>It gave all the advanced CUPS options (web interface,
GUI driver configurations) to users wanting (or needing) to use
Ghostscript filters.</p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962589"></a>cupsomatic, pdqomatic, lpdomatic, directomatic</h4></div></div><div></div></div><p>
CUPS worked through a quickly-hacked up filter script named <a href="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&show=0" target="_top">cupsomatic</a>.
cupsomatic ran the printfile through Ghostscript, constructing
automatically the rather complicated command line needed. It just
required 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, Grant implemented within a few
days a similar thing for two other spoolers. Names chosen for the
config-generator scripts were <a href="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0" target="_top">PDQ-O-Matic</a>
(for PDQ) and <a href="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0" target="_top">LPD-O-Matic</a>
(for - you guessed it - LPD); the configuration here didn't use PPDs
but other spooler-specific files.
</p><p>
From late summer of that year, <a href="http://www.linuxprinting.org/till/" target="_top">Till Kamppeter</a>
started to put work into the database. Till had been newly employed by
<a href="http://www.mandrakesoft.com/" target="_top">MandrakeSoft</a> to
convert their printing system over to CUPS, after they had seen his
<a href="http://www.fltk.org/" target="_top">FLTK</a>-based <a href="http://cups.sourceforge.net/xpp/" target="_top">XPP</a> (a GUI frontend 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
<a href="http://ppr.sourceforge.net/" target="_top">PPR</a> (via ppromatic),
<a href="http://sourceforge.net/projects/lpr/" target="_top">GNUlpr</a> and
<a href="http://www.lprng.org/" target="_top">LPRng</a> (both via an extended
lpdomatic) and "spoolerless" printing (<a href="http://www.linuxprinting.org/download.cgi?filename=directomatic&show=0" target="_top">directomatic</a>)....
</p><p>
So, to answer your question: "Foomatic" is the general name for all
the overlapping code and data behind the "*omatic" scripts.... --
Foomatic up to versions 2.0.x required (ugly) Perl data structures
attached the Linuxprinting.org PPDs for CUPS. It had a different
"*omatic" script for every spooler, as well as different printer
configuration files..
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962725"></a>7.13.1.5.The <span class="emphasis"><em>Grand Unification</em></span>
achieved...</h4></div></div><div></div></div><p>
This all has changed in Foomatic versions 2.9 (Beta) and released as
"stable" 3.0. This has now achieved the convergence of all *omatic
scripts: it is called the <a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0" target="_top">foomatic-rip</a>.
This single script is the unification of the previously different
spooler-specific *omatic scripts. foomatic-rip is used by all the
different spoolers alike. Because foomatic-rip 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; paper sizes and trays are easier to configure.
</p><p>
Also, the New Generation of Linuxprinting.org PPDs doesn't contain
Perl data structures any more. 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 don't forget to generate a new-version set of PPDs,
via the new <a href="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz" target="_top">foomatic-db-engine</a>!
Individual users just need to generate a single new PPD specific to
their model by <a href="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html" target="_top">following
the steps</a> outlined in the Foomatic tutorial or further
below. This new development is truly amazing.
</p><p>
foomatic-rip is a very clever wrapper around the need to run
Ghostscript with a different syntax, different options, different
device selections and/or different filters for each different printer
or different 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 really innovative features of
the Foomatic concept will surprise users: it will support custom paper
sizes for many printers; and it 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).
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962810"></a>Driver Development outside</h4></div></div><div></div></div><p>
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.
</p><p>
Speaking of the different driver development groups: most of
the work is currently done in three projects. These are:
</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/" target="_top">Omni</a>
-- a Free Software project by IBM which tries to convert their 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.</p></li><li><p><a href="http://hpinkjet.sf.net/" target="_top">HPIJS</a> --
a Free Software project by HP to provide the support for their own
range of models (very mature, printing in most cases is perfect and
provides true photo quality). This currently supports 369
models.</p></li><li><p><a href="http://gimp-print.sf.net/" target="_top">Gimp-Print</a> -- 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.</p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962892"></a>Forums, Downloads, Tutorials, Howtos -- also for Mac OS X and
commercial Unix</h4></div></div><div></div></div><p>
Linuxprinting.org today is the one-stop "shop" to download printer
drivers. Look for printer information and <a href="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/" target="_top">tutorials</a>
or solve printing problems in its popular <a href="http://www.linuxprinting.org/newsportal/" target="_top">forums</a>. But
it's not just for GNU/Linux: users and admins of <a href="http://www.linuxprinting.org/macosx/" target="_top">commercial UNIX
systems</a> are also going there, and the relatively new <a href="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general" target="_top">Mac
OS X forum</a> has turned out to be one of the most frequented
fora after only a few weeks.
</p><p>
Linuxprinting.org and the Foomatic driver wrappers around Ghostscript
are now a standard toolchain 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 Till (who works at Mandrake), many
additional contributions came from engineers with SuSE, RedHat,
Connectiva, Debian and others. Vendor-neutrality is an important goal
of the Foomatic project.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
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.
</p></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2962963"></a>Foomatic Database generated PPDs</h4></div></div><div></div></div><p>
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 modelled to the
Adobe specification of "PostScript Printer Descriptions" (PPDs), the
Linuxprinting.org/Foomatic-PPDs don't 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 a HP Photosmart or
what-have-you. The main "trick" is one little additional line, not
envisaged by the PPD specification, starting with the "*cupsFilter"
keyword: it tells the CUPS daemon how to proceed with the PostScript
print file (old-style Foomatic-PPDs named the
<span class="emphasis"><em>cupsomatic</em></span> filter script, while the new-style
PPDs now call <span class="emphasis"><em>foomatic-rip</em></span>). 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 printjob into a raster format ready for the
target device. This usage of PPDs to describe the options of non-PS
printers was the invention of the CUPS developers. The rest is easy:
GUI tools (like KDE's marvellous <a href="http://printing.kde.org/overview/kprinter.phtml" target="_top">"kprinter"</a>,
or the GNOME <a href="http://gtklp.sourceforge.net/" target="_top">"gtklp"</a>, "xpp" and the CUPS
web interface) read the PPD too and use this information to present
the available settings to the user as an intuitive menu selection.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963027"></a>foomatic-rip and Foomatic-PPD Download and Installation</h3></div></div><div></div></div><p>
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 foomatic-rip utility. going directly to
Linuxprinting.org ensures you to get the latest driver/PPD files):
</p><div class="itemizedlist"><ul type="disc"><li><p>Surf to <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a>
</p></li><li><p>Check the complete list of printers in the database:
<a href="http://www.linuxprinting.org/printer_list.cgi?make=Anyone" target="_top">http://www.linuxprinting.org/printer_list.cgi?make=Anyone</a>
</p></li><li><p>There select your model and click on the
link.</p></li><li><p>You'll arrive at a page listing all drivers working
with this model (for all printers, there will always be
<span class="emphasis"><em>one</em></span> recommended driver. Try this one
first).</p></li><li><p>In our case ("HP LaserJet 4 Plus"), we'll arrive here:
<a href="http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus" target="_top">http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus</a>
</p></li><li><p>The recommended driver is "ljet4".</p></li><li><p>There are several links provided here. You should
visit them all, if you are not familiar with the Linuxprinting.org
database.</p></li><li><p>There is a link to the database page for the "ljet4":
<a href="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4" target="_top">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</a>
On the driver's page, you'll find important and detailed information
about how to use that driver within the various available
spoolers.</p></li><li><p>Another link may lead you to the homepage of the
driver author or the driver.</p></li><li><p>Important links are the ones which provide hints with
setup instructions for CUPS (<a href="http://www.linuxprinting.org/cups-doc.html" target="_top">http://www.linuxprinting.org/cups-doc.html</a>),
PDQ (<a href="http://www.linuxprinting.org/pdq-doc.html" target="_top">http://www.linuxprinting.org/pdq-doc.html</a>),
LPD, LPRng and GNUlpr (<a href="http://www.linuxprinting.org/lpd-doc.html" target="_top">http://www.linuxprinting.org/lpd-doc.html</a>)
as well as PPR (<a href="http://www.linuxprinting.org/ppr-doc.html" target="_top">http://www.linuxprinting.org/ppr-doc.html)</a>
or "spooler-less" printing (<a href="http://www.linuxprinting.org/direct-doc.html" target="_top">http://www.linuxprinting.org/direct-doc.html</a>
).</p></li><li><p>You can view the PPD in your browser through this
link: <a href="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1" target="_top">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1</a>
</p></li><li><p>You can also (most importantly)
generate and download the PPD: <a href="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0" target="_top">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0</a>
</p></li><li><p>The PPD contains all the information needed to use our
model and the driver; this is, once installed, working transparently
for the user. Later you'll only need to choose resolution, paper size
etc. from the web-based menu, or from the print dialog GUI, or from
the commandline.</p></li><li><p>Should you have ended up on the driver's page (<a href="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4" target="_top">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</a>),
you can choose to use the "PPD-O-Matic" online PPD generator
program.</p></li><li><p>Select the exact model and check either "download" or
"display PPD file" and click on "Generate PPD file".</p></li><li><p>If you save the PPD file from the browser view, please
don't use "cut'n'past" (since it could possibly damage line endings
and tabs, which makes the PPD likely to fail its duty), but use "Save
as..." in your browser's menu. (Best is to use the "download" option
from the web page directly).</p></li><li><p>Another very interesting part on each driver page is
the <span class="emphasis"><em>Show execution details</em></span> button. If you
select your printer model and click that button, you will get
displayed a complete Ghostscript command line, enumerating all options
available for that driver/printermodel combo. This is a great way to
"Learn Ghostscript By Doing". It is also an excellent "cheat sheet"
for all experienced users who need to re-construct a good command line
for that damn printing script, but can't remember the exact
syntax. ;-)</p></li><li><p>Some time during your visit to Linuxprinting.org, save
the PPD to a suitable place on your harddisk, say
<tt class="filename">/path/to/my-printer.ppd</tt> (if you prefer to install
your printers with the help of the CUPS web interface, save the PPD to
the <tt class="filename">/usr/share/cups/model/</tt> path and re-start
cupsd).</p></li><li><p>Then install the printer with a suitable commandline,
e.g.:
</p><pre class="screen">
lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P path/to/my-printer.ppd
</pre></li><li><p>Note again this: for all the new-style "Foomatic-PPDs"
from Linuxprinting.org, you also need a special "CUPS filter" named
"foomatic-rip".Get the latest version of "foomatic-rip" from: <a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0" target="_top">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0</a>
</p></li><li><p>The foomatic-rip Perlscript itself also makes some
interesting reading (<a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1" target="_top">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1</a>),
because it is very well documented by Till's inline comments (even
non-Perl hackers will learn quite a bit about printing by reading
it... ;-)</p></li><li><p>Save foomatic-rip either directly in
<tt class="filename">/usr/lib/cups/filter/foomatic-rip</tt> or somewhere in
your $PATH (and don't forget to make it world-executable). Again,
don't save by "copy'n'paste" but use the appropriate link, or the
"Save as..." menu item in your browser.</p></li><li><p>If you save foomatic-rip in your $PATH, create a symlink:
<b class="command">cd /usr/lib/cups/filter/ ; ln -s `which
foomatic-rip`</b>. For CUPS to discover this new
available filter at startup, you need to re-start
cupsd.</p></li></ul></div><p>
Once you print to a printqueue set up with the Foomatic-PPD, CUPS will
insert the appropriate commands and comments into the resulting
PostScript jobfile. foomatic-rip is able to read and act upon
these. foomatic-rip uses some specially encoded Foomatic comments,
embedded in the jobfile. These in turn are used to construct
(transparently for you, the user) the complicated ghostscript command
line telling for the printer driver how exactly the resulting raster
data should look like and which printer commands to embed into the
data stream.
</p><p>
You need:
</p><div class="itemizedlist"><ul type="disc"><li><p>A "foomatic+something" PPD -- but it this not enough
to print with CUPS (it is only <span class="emphasis"><em>one</em></span> important
component)</p></li><li><p>The "foomatic-rip" filter script (Perl) in
/usr/lib/cups/filters/</p></li><li><p>Perl to make foomatic-rip run</p></li><li><p>Ghostscript (because it is doing the main work,
controlled by the PPD/foomatic-rip combo) to produce the raster data
fit for your printermodel's consumption</p></li><li><p>Ghostscript <span class="emphasis"><em>must</em></span> (depending on
the driver/model) contain support for a certain "device", representing
the selected "driver" for your model (as shown by "gs
-h")</p></li><li><p>foomatic-rip needs a new version of PPDs (PPD versions
produced for cupsomatic don't work with
foomatic-rip).</p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2963488"></a>Page Accounting with CUPS</h2></div></div><div></div></div><p>
Often there are questions regarding "print quotas" wherein Samba users
(that is, Windows clients) should not be able to print beyond a
certain amount 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 <span class="emphasis"><em>or</em></span> unfiltered) and hand it over to this
printing subsystem.
</p><p>
Of course one could "hack" things with one's own scripts. But then
there is CUPS. CUPS supports "quotas" which can be based on sizes of
jobs or on the number of pages or both, and are spanning any time
period you want.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963519"></a>Setting up Quotas</h3></div></div><div></div></div><p>
This is an example command how root would set a print quota in CUPS,
assuming an existing printer named "quotaprinter":
</p><pre class="screen">
lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100
</pre><p>
This would limit every single user to print 100 pages or 1024 KB of
data (whichever comes first) within the last 604,800 seconds ( = 1
week).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963551"></a>Correct and incorrect Accounting</h3></div></div><div></div></div><p>
For CUPS to count correctly, the printfile needs to pass the CUPS
"pstops" filter, otherwise it uses a "dummy" count of "1". Some
printfiles don't pass it (eg: image files) but then those are mostly 1
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 "raw" (i.e. leaving them untouched, not
filtering them), will be counted as "1-pagers" too!
</p><p>
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
will be working for currently about 1,000 different printer models,
see <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a>).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963592"></a>Adobe and CUPS PostScript Drivers for Windows Clients</h3></div></div><div></div></div><p>
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 "pstops" 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 pstops and go directly
to the "pstoraster" stage).
</p><p>
From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver for
Windows NT/2K/XP clients" (which is tagged in the download area of
http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). It does
<span class="emphasis"><em>not</em></span> work for Win9x/ME clients. But it guarantees:
</p><div class="itemizedlist"><ul type="disc"><li><p>to not write an PJL-header</p></li><li><p>to still read and support all PJL-options named in the
driver PPD with its own means</p></li><li><p> that the file will pass through the "pstops" filter
on the CUPS/Samba server</p></li><li><p>to page-count correctly the
printfile</p></li></ul></div><p>
You can read more about the setup of this combination in the manpage
for "cupsaddsmb" (which is only present with CUPS installed, and only
current from CUPS 1.1.16).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963663"></a>The page_log File Syntax</h3></div></div><div></div></div><p>
These are the items CUPS logs in the "page_log" for every
single <span class="emphasis"><em>page</em></span> of a job:
</p><div class="itemizedlist"><ul type="disc"><li><p>Printer name</p></li><li><p>User name</p></li><li><p>Job ID</p></li><li><p>Time of printing</p></li><li><p>the page number</p></li><li><p>the number of copies</p></li><li><p>a billing information string
(optional)</p></li><li><p>the host which sent the job (included since version
1.1.19)</p></li></ul></div><p>
Here is an extract of my CUPS server's page_log file to illustrate the
format and included items:
</p><pre class="screen">
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
DigiMaster9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33
</pre><p>
This was job ID "401", printed on "infotec_IS2027" by user "kurt", a
64-page job printed in 3 copies and billed to "#marketing", sent
from IP address 10.160.50.13. The next job had ID "402", was sent by
user "boss" from IP address 10.160.51.33,printed from one page 440
copies and is set to be billed to "finance-dep".
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963765"></a>Possible Shortcomings</h3></div></div><div></div></div><p>
What flaws or shortcomings are there with this quota system?
</p><div class="itemizedlist"><ul type="disc"><li><p>the ones named above (wrongly logged job in case of
printer hardware failure, etc.)</p></li><li><p>in reality, CUPS counts the job pages that are being
processed in <span class="emphasis"><em>software</em></span> (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 5th sheet out
of 1000 and the job is aborted by the printer, the "page count" will
still show the figure of 1000 for that job</p></li><li><p>all quotas are the same for all users (no flexibility
to give the boss a higher quota than the clerk) no support for
groups</p></li><li><p>no means to read out the current balance or the
"used-up" number of current quota</p></li><li><p>a user having used up 99 sheets of 100 quota will
still be able to send and print a 1,000 sheet job</p></li><li><p>a user being denied a job because of a filled-up quota
doesn't get a meaningful error message from CUPS other than
"client-error-not-possible".</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963836"></a>Future Developments</h3></div></div><div></div></div><p>
This is the best system currently available, and there are huge
improvements under development for CUPS 1.2:
</p><div class="itemizedlist"><ul type="disc"><li><p>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 5th sheet will lead to a
stop in the counting)</p></li><li><p>quotas will be handled more flexibly</p></li><li><p>probably there will be support for users to inquire
their "accounts" in advance</p></li><li><p>probably there will be support for some other tools
around this topic</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2963884"></a>Other Accounting Tools</h3></div></div><div></div></div><p>
PrintAnalyzer, pyKota, printbill, LogReport.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2963899"></a>Additional Material</h2></div></div><div></div></div><p>
A printer queue with <span class="emphasis"><em>no</em></span> PPD associated to it is a
"raw" printer and all files will go directly there as received by the
spooler. The exceptions are file types "application/octet-stream"
which need "passthrough feature" enabled. "Raw" queues don't do any
filtering at all, they hand the file directly to the CUPS backend.
This backend is responsible for the sending of the data to the device
(as in the "device URI" notation: <tt class="filename">lpd://, socket://,
smb://, ipp://, http://, parallel:/, serial:/, usb:/</tt> etc.)
</p><p>
"cupsomatic"/Foomatic are <span class="emphasis"><em>not</em></span> native CUPS drivers
and they don't 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. "cupsomatic" is only a vehicle to execute a
ghostscript commandline at that stage in the CUPS filtering chain,
where "normally" the native CUPS "pstoraster" filter would kick
in. cupsomatic by-passes pstoraster, "kidnaps" the printfile from CUPS
away and re-directs it to go through Ghostscript. CUPS accepts this,
because the associated CUPS-O-Matic-/Foomatic-PPD specifies:
</p><pre class="screen">
*cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
</pre><p>
This line persuades CUPS to hand the file to cupsomatic, once it has
successfully converted it to the MIME type
"application/vnd.cups-postscript". This conversion will not happen for
Jobs arriving from Windows which are auto-typed
"application/octet-stream", with the according changes in
<tt class="filename">/etc/cups/mime.types</tt> in place.
</p><p>
CUPS is widely configurable and flexible, even regarding its filtering
mechanism. Another workaround in some situations would be to have in
<tt class="filename">/etc/cups/mime.types</tt> entries as follows:
</p><pre class="screen">
application/postscript application/vnd.cups-raw 0 -
application/vnd.cups-postscript application/vnd.cups-raw 0 -
</pre><p>
This would prevent all Postscript files from being filtered (rather,
they will through the virtual <span class="emphasis"><em>nullfilter</em></span>
denoted with "-"). This could only be useful for PS printers. If you
want to print PS code on non-PS printers (provided they support ASCII
text printing) an entry as follows could be useful:
</p><pre class="screen">
*/* application/vnd.cups-raw 0 -
</pre><p>
and would effectively send <span class="emphasis"><em>all</em></span> files to the
backend without further processing.
</p><p>
Lastly, you could have the following entry:
</p><pre class="screen">
application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter
</pre><p>
You will need to write a <span class="emphasis"><em>my_PJL_stripping_filter</em></span>
(could be a shellscript) that parses the PostScript and removes the
unwanted PJL. This would need 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 would be installed as world executable into
<tt class="filename">/usr/lib/cups/filters/</tt> and will be called by CUPS
if it encounters a MIME type "application/vnd.cups-postscript".
</p><p>
CUPS can handle <span class="emphasis"><em>-o job-hold-until=indefinite</em></span>.
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, etc.).
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2964092"></a>Auto-Deletion or Preservation of CUPS Spool Files</h2></div></div><div></div></div><p>
Samba print files pass through two "spool" directories. One is the
incoming directory managed by Samba, (set in the <span class="emphasis"><em>path =
/var/spool/samba</em></span> directive in the
<span class="emphasis"><em>[printers]</em></span> section of
<tt class="filename">smb.conf</tt>). The other is the spool directory of
your UNIX print subsystem. For CUPS it is normally
<tt class="filename">/var/spool/cups/</tt>, as set by the cupsd.conf
directive <tt class="filename">RequestRoot /var/spool/cups</tt>.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964138"></a>CUPS Configuration Settings explained</h3></div></div><div></div></div><p>
Some important parameter settings in the CUPS configuration file
<tt class="filename">cupsd.conf</tt> are:
</p><div class="variablelist"><dl><dt><span class="term">PreserveJobHistory Yes</span></dt><dd><p>
This keeps some details of jobs in cupsd's mind (well it keeps the
"c12345", "c12346" etc. files in the CUPS spool directory, which do a
similar job as the old-fashioned BSD-LPD control files). This is set
to "Yes" as a default.
</p></dd><dt><span class="term">PreserveJobFiles Yes</span></dt><dd><p>
This keeps the job files themselves in cupsd's mind
(well it keeps the "d12345", "d12346" etc. files in the CUPS spool
directory...). This is set to "No" as the CUPS
default.
</p></dd><dt><span class="term"><span class="emphasis"><em>"MaxJobs 500"</em></span></span></dt><dd><p>
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.
</p></dd></dl></div><p>
(There are also additional settings for "MaxJobsPerUser" and
"MaxJobsPerPrinter"...)
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964221"></a>Pre-conditions</h3></div></div><div></div></div><p>
For everything to work as announced, you need to have three
things:
</p><div class="itemizedlist"><ul type="disc"><li><p>a Samba-smbd which is compiled against "libcups" (Check
on Linux by running "ldd `which smbd`")</p></li><li><p>a Samba-<tt class="filename">smb.conf</tt> setting of
"printing = cups"</p></li><li><p>another Samba-<tt class="filename">smb.conf</tt> setting of
"printcap = cups"</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
In this case all other manually set printing-related commands (like
"print command", "lpq command", "lprm command", "lppause command" or
"lpresume command") are ignored and they should normally have no
influence what-so-ever on your printing.
</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964281"></a>Manual Configuration</h3></div></div><div></div></div><p>
If you want to do things manually, replace the "printing =
cups" by "printing = bsd". Then your manually set commands may work
(haven't tested this), and a "print command = lp -d %P %s; rm %s"
may do what you need.
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2964299"></a>When <span class="emphasis"><em>not</em></span> to use Samba to print to
CUPS</h2></div></div><div></div></div><p>
[TO BE DONE]
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2964316"></a>In Case of Trouble.....</h2></div></div><div></div></div><p>
If you have more problems, post the output of these commands
to the CUPS or Samba mailing lists (choose the one which seems more
relevant to your problem):
</p><pre class="screen">
grep -v ^# /etc/cups/cupsd.conf | grep -v ^$
grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;"
</pre><p>
(adapt paths as needed). These commands leave out the empty
lines and lines with comments, providing the "naked settings" in a
compact way. Don't forget to name the CUPS and Samba versions you
are using! This saves bandwidth and makes for easier readability
for experts (and you are expecting experts to read them, right?
;-)
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964352"></a>Where to find Documentation</h3></div></div><div></div></div><p>
[TO BE DONE]
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964364"></a>How to ask for Help</h3></div></div><div></div></div><p>
[TO BE DONE]
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964377"></a>Where to find Help</h3></div></div><div></div></div><p>
[TO BE DONE]
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2964391"></a>Appendix</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964398"></a>Printing <span class="emphasis"><em>from</em></span> CUPS to Windows attached
Printers</h3></div></div><div></div></div><p>
From time to time the question arises, how you can print
<span class="emphasis"><em>to</em></span> a Windows attached printer
<span class="emphasis"><em>from</em></span> Samba. Normally the local connection
"Windows host <--> printer" would be done by USB or parallel
cable, but this doesn't 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
<span class="emphasis"><em>backends</em></span> to talk to printers and other
servers. To talk to Windows shared printers you need to use the
<span class="emphasis"><em>smb</em></span> (surprise, surprise!) backend. Check if this
is in the CUPS backend directory. This resides usually in
<tt class="filename">/usr/lib/cups/backend/</tt>. You need to find a "smb"
file there. It should be a symlink to <tt class="filename">smbspool</tt>
which file must exist and be executable:
</p><pre class="screen">
# ls -l /usr/lib/cups/backend/
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 -> 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 -> /usr/local/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 -> /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
# ls -l `which smbspool`
-rwxr-xr-x 1 root root 563245 Dec 28 14:49 /usr/bin/smbspool
</pre><p>
If this symlink doesn't exist, create it:
</p><pre class="screen">
# ln -s `which smbspool` /usr/lib/cups/backend/smb
</pre><p>
smbspool has been 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 "winprinter" 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, etc.
</p><p>
To install a printer with the smb backend on CUPS, use this command:
</p><pre class="screen">
# lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename -P /path/to/PPD
</pre><p>
The <span class="emphasis"><em>PPD</em></span> 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
<tt class="filename">smb://</tt> device-URI. Like this:
</p><pre class="screen">
smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename
smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename
smb://username:password@WINDOWSNETBIOSNAME/printersharename
</pre><p>
Note that the device-URI will be visible in the process list of the
Samba server (e.g. when someone uses the <b class="command">ps -aux</b>
command on Linux), even if the username and passwords are sanitized
before they get written into the log files. So 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
doesn't 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 don't necessarily need to have smbd running
(but who wants that? :-).
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964612"></a>More CUPS filtering Chains</h3></div></div><div></div></div><p>
The following diagrams reveal how CUPS handles print jobs.
</p><pre class="screen">
#########################################################################
#
# CUPS in and of itself has this (general) filter chain (CAPITAL
# letters are FILE-FORMATS or MIME types, other are filters (this is
# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT
# |
# V
# pstoraster # as shipped with CUPS, independent from any Ghostscipt
# | # installation on the system
# | (= "postscipt interpreter")
# V
# APPLICATION/VND.CUPS-RASTER
# |
# V
# rastertosomething (e.g. Gimp-Print filters may be plugged in here)
# | (= "raster driver")
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# V
# backend
#
#
# ESP PrintPro has some enhanced "rastertosomething" filters as compared to
# CUPS, and also a somewhat improved "pstoraster" filter.
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
</pre><pre class="screen">
#########################################################################
#
# This is how "cupsomatic" comes into play:
# =========================================
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
# | V
# V cupsomatic
# pstoraster (constructs complicated
# | (= "postscipt interpreter") Ghostscript commandline
# | to let the file be
# V processed by a
# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
# | call...)
# V |
# rastertosomething V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
# V |
# backend <------------------------------------+
# |
# V
# THE PRINTER
#
#
# Note, that cupsomatic "kidnaps" the printfile after the
# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it gh
# the CUPS-external, systemwide Ghostscript installation, bypassing the
# "pstoraster" filter (therefore also bypassing the CUPS-raster-drivers
# "rastertosomething", and hands the rasterized file directly to the CUPS
# backend...
#
# cupsomatic is not made by the CUPS developers. It is an independent
# contribution to printing development, made by people from
# Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
</pre><pre class="screen">
#########################################################################
#
# And this is how it works for ESP PrintPro from 4.3:
# ===================================================
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT
# |
# V
# gsrip
# | (= "postscipt interpreter")
# V
# APPLICATION/VND.CUPS-RASTER
# |
# V
# rastertosomething (e.g. Gimp-Print filters may be plugged in here)
# | (= "raster driver")
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# V
# backend
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
</pre><pre class="screen">
#########################################################################
#
# This is how "cupsomatic" would come into play with ESP PrintPro:
# ================================================================
#
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
# | V
# V cupsomatic
# gsrip (constructs complicated
# | (= "postscipt interpreter") Ghostscript commandline
# | to let the file be
# V processed by a
# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
# | call...)
# V |
# rastertosomething V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
# V |
# backend <------------------------------------+
# |
# V
# THE PRINTER
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
</pre><pre class="screen">
#########################################################################
#
# And this is how it works for CUPS from 1.1.15:
# ==============================================
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
# +------------------v------------------------------+
# | Ghostscript |
# | at work... |
# | (with |
# | "-sDEVICE=cups") |
# | |
# | (= "postscipt interpreter") |
# | |
# +------------------v------------------------------+
# |
# APPLICATION/VND.CUPS-RASTER >-------+
# |
# V
# rastertosomething
# | (= "raster driver")
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# V
# backend
#
#
# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
# Ghostscript. GNU Ghostscript needs to be patched to handle the
# CUPS requirement; ESP Ghostscript has this builtin. In any case,
# "gs -h" needs to show up a "cups" device. pstoraster is now a
# calling an appropriate "gs -sDEVICE=cups..." commandline to do
# the job. It will output "application/vnd.cup-raster", which will
# be finally processed by a CUPS raster driver "rastertosomething"
# Note the difference to "cupsomatic", which will <span class="emphasis"><em>not</em></span> output
# CUPS-raster, but a final version of the printfile, ready to be
# sent to the printer. cupsomatic also doesn't use the "cups"
# devicemode in Ghostscript, but one of the classical devicemodes....
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
</pre><pre class="screen">
#########################################################################
#
# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
# ========================================================================
#
# SOMETHNG-FILEFORMAT
# |
# V
# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
# V
# pstops
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
# +------------------v------------------------------+
# | Ghostscript . Ghostscript at work.... |
# | at work... . (with "-sDEVICE= |
# | (with . s.th." |
# | "-sDEVICE=cups") . |
# | . |
# | (CUPS standard) . (cupsomatic) |
# | . |
# | (= "postscript interpreter") |
# | . |
# +------------------v--------------v---------------+
# | |
# APPLICATION/VND.CUPS-RASTER >-------+ |
# | |
# V |
# rastertosomething |
# | (= "raster driver") |
# V |
# SOMETHING-DEVICE-SPECIFIC >------------------------+
# |
# V
# backend
#
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
##########################################################################
</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964919"></a>Trouble Shooting Guidelines to fix typical Samba printing
Problems</h3></div></div><div></div></div><p>
This is a short description of how to debug printing problems
with Samba. This describes how to debug problems with printing from
a SMB client to a Samba server, not the other way around.
</p><div class="variablelist"><dl><dt><span class="term">Win9x client can't install driver</span></dt><dd><p>For Win9x clients require the printer names to be 8
chars (or "8 plus 3 chars suffix") max; otherwise the driver files
won't get transferred when you want to download them from
Samba.</p></dd><dt><span class="term">testparm</span></dt><dd><p>Run <b class="command">testparm</b>: It will tell you if
<tt class="filename">smb.conf</tt> parameters are in the wrong
section. Many people have had the "printer admin" parameter in the
<i class="parameter"><tt>[printers]</tt></i> section and experienced
problems. "testparm" will tell you if it sees
this.</p></dd><dt><span class="term">"cupsaddsmb" keeps asking for a root password in a
neverending loop</span></dt><dd><p>Have you <i class="parameter"><tt>security = user</tt></i>? Have
you used <b class="command">smbpasswd</b> to give root a Samba account?
You can do 2 things: open another terminal and execute
<b class="command">smbpasswd -a root</b> to create the account, and
continue with entering the password into the first terminal. Or break
out of the loop by hitting ENTER twice (without trying to type a
password).</p></dd><dt><span class="term">"cupsaddsmb" gives "No PPD file for printer..."
message (but I swear there is one!)</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><p>Have you enabled printer sharing on CUPS? This means:
do you have a <i class="parameter"><tt><Location
/printers>....</Location></tt></i> section in CUPS
server's <tt class="filename">cupsd.conf</tt> which doesn't deny access to
the host you run "cupsaddsmb" from? It <span class="emphasis"><em>could</em></span> be
an issue if you use cupsaddsmb remotely, or if you use it with a
<i class="parameter"><tt>-h</tt></i> parameter: <b class="command">cupsaddsmb -H
sambaserver -h cupsserver -v printername</b>.
</p></li><li><p>Is your
"TempDir" directive in
<span class="emphasis"><em>cupsd.conf</em></span>
set to a valid value and is it writeable?
</p></li></ul></div></dd><dt><span class="term">I can't connect client to Samba printer.</span></dt><dd><p>Use <b class="command">smbstatus</b> to check which user
you are from Samba's point of view. Do you have the privileges to
write into the <i class="parameter"><tt>[print$]</tt></i>
share?</p></dd><dt><span class="term">I can't reconnect to Samba under a new account
from Win2K/XP</span></dt><dd><p>Once you are connected as the "wrong" user (for
example as "nobody", which often occurs if you have <i class="parameter"><tt>map to
guest = bad user</tt></i>), Windows Explorer will not accept an
attempt to connect again as a different user. There won't be any byte
transfered on the wire to Samba, but still you'll see a stupid error
message which makes you think that Samba has denied access. Use
<b class="command">smbstatus</b> to check for active connections. Kill the
PIDs. You still can't re-connect and get the dreaded
<tt class="computeroutput">You can't connect with a second account from the same
machine</tt> message, as soon as you are trying? And you
don't see any single byte arriving at Samba (see logs; use "ethereal")
indicating a renewed connection attempt? Shut all Explorer Windows.
This makes Windows forget what it has cached in its memory as
established connections. Then re-connect as the right user. Best
method is to use a DOS terminal window and <span class="emphasis"><em>first</em></span>
do <b class="command">net use z: \\SAMBAHOST\print$ /user:root</b>. Check
with <b class="command">smbstatus</b> that you are connected under a
different account. Now open the "Printers" folder (on the Samba server
in the <span class="emphasis"><em>Network Neighbourhood</em></span>), right-click the
printer in question and select
<span class="emphasis"><em>Connect...</em></span></p></dd><dt><span class="term">Avoid being connected to the Samba server as the
"wrong" user</span></dt><dd><p>You see per <b class="command">smbstatus</b> that you are
connected as user "nobody"; while you wanted to be "root" or
"printeradmin"? This is probably due to <i class="parameter"><tt>map to guest = bad
user</tt></i>, which silently connects you under the guest account,
when you gave (maybe by accident) an incorrect username. Remove
<i class="parameter"><tt>map to guest</tt></i>, if you want to prevent
this.</p></dd><dt><span class="term">Upgrading to CUPS drivers from Adobe drivers on
NT/2K/XP clients gives problems</span></dt><dd><p>First delete all "old" Adobe-using printers. Then
delete all "old" Adobe drivers. (On Win2K/XP, right-click in
background of "Printers" folder, select "Server Properties...", select
tab "Drivers" and delete here).</p></dd><dt><span class="term">I can't use "cupsaddsmb"on a Samba server which is
a PDC</span></dt><dd><p>Do you use the "naked" root user name? Try to do it
this way: <span class="emphasis"><em>cupsaddsmb -U DOMAINNAME\\root -v
printername</em></span> (note the two backslashes: the first one is
required to "escape" the second one).</p></dd><dt><span class="term">I deleted a printer on Win2K; but I still see
its driver</span></dt><dd><p>Deleting a printer on the client won't delete the
driver too (to verify, right-click on the white background of the
"Printers" folder, select "Server Properties" and click on the
"Drivers" 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.</p></dd><dt><span class="term">Win2K/XP "Local Security
Policies"</span></dt><dd><p><span class="emphasis"><em>Local Security Policies</em></span> may not
allow the installation of unsigned drivers. "Local Security Policies"
may not allow the installation of printer drivers at
all.</p></dd><dt><span class="term">WinXP clients: "Administrator can not install
printers for all local users"</span></dt><dd><p>Windows XP handles SMB printers on a "per-user" basis.
This means every user needs to install the printer himself. To have a
printer available for everybody, you might want to use the built-in
IPP client capabilities of WinXP. Add a printer with the print path of
<span class="emphasis"><em>http://cupsserver:631/printers/printername</em></span>.
Still looking into this one: maybe a "logon script" could
automatically install printers for all
users.</p></dd><dt><span class="term">"Print Change Notify" functions on
NT-clients</span></dt><dd><p>For "print change notify" functions on NT++ clients,
these need to run the "Server" service first (re-named to
<span class="emphasis"><em>File & Print Sharing for MS Networks</em></span> in
XP).</p></dd><dt><span class="term">WinXP-SP1</span></dt><dd><p>WinXP-SP1 introduced a <span class="emphasis"><em>Point and Print
Restriction Policy</em></span> (this restriction doesn't apply to
"Administrator" or "Power User" groups of users). In Group Policy
Object Editor: go to <span class="emphasis"><em>User Configuration -->
Administrative Templates --> Control Panel -->
Printers</em></span>. The policy is automatically set to
<span class="emphasis"><em>Enabled</em></span> and the <span class="emphasis"><em>Users can only Point
and Print to machines in their Forest</em></span> . You probably need
to change it to <span class="emphasis"><em>Disabled</em></span> or <span class="emphasis"><em>Users can
only Point and Print to these servers</em></span> in order to make
driver downloads from Samba possible.</p></dd><dt><span class="term">I can't set and save default print options for all
users on Win2K/XP</span></dt><dd><p>How are you doing it? I bet the wrong way (it is not
very easy to find out, though). There are 3 different ways to bring
you to a dialog that <span class="emphasis"><em>seems</em></span> to set everything. All
three dialogs <span class="emphasis"><em>look</em></span> the same. Only one of them
<span class="emphasis"><em>does</em></span> 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:
</p><div class="orderedlist"><ol type="A"><li><p>The first "wrong" way:
</p><div class="orderedlist"><ol type="1"><li><p>Open the <span class="emphasis"><em>Printers</em></span>
folder.</p></li><li><p>Right-click on the printer
(<span class="emphasis"><em>remoteprinter on cupshost</em></span>) and
select in context menu <span class="emphasis"><em>Printing
Preferences...</em></span></p></li><li><p>Look at this dialog closely and remember what it looks
like.</p></li></ol></div><p>
</p></li><li><p>The second "wrong" way:
</p><div class="orderedlist"><ol type="1"><li><p>Open the <span class="emphasis"><em>Printers</em></span>
folder.</p></li><li><p>Right-click on the printer (<span class="emphasis"><em>remoteprinter on
cupshost</em></span>) and select in the context menu
<span class="emphasis"><em>Properties</em></span></p></li><li><p>Click on the <span class="emphasis"><em>General</em></span>
tab</p></li><li><p>Click on the button <span class="emphasis"><em>Printing
Preferences...</em></span></p></li><li><p>A new dialog opens. Keep this dialog open and go back
to the parent dialog.</p></li></ol></div><p>
</p></li><li><p>The third, the "correct" way: (should you do
this from the beginning, just carry out steps 1. and 2. from second
"way" above)
</p><div class="orderedlist"><ol type="1"><li><p>Click on the <span class="emphasis"><em>Advanced</em></span>
tab. (Hmmm... if everything is "Grayed Out", then you are not logged
in as a user with enough privileges).</p></li><li><p>Click on the <span class="emphasis"><em>Printing
Defaults...</em></span> button.</p></li><li><p>On any of the two new tabs, click on the
<span class="emphasis"><em>Advanced...</em></span>
button.</p></li><li><p>A new dialog opens. Compare this one to the other,
identical looking one from "B.5" or A.3".</p></li></ol></div><p>
</p></li></ol></div><p>
Do you see any difference? I don't either... However, only the last
one, which you arrived at with steps "C.1.-6." 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 <span class="emphasis"><em>as
Administrator</em></span> (<i class="parameter"><tt>printer admin</tt></i> in
<tt class="filename">smb.conf</tt>) <span class="emphasis"><em>before</em></span> a client
downloads the driver (the clients can later set their own
<span class="emphasis"><em>per-user defaults</em></span> by following the
procedures <span class="emphasis"><em>A.</em></span> or <span class="emphasis"><em>B.</em></span>
above).</p></dd><dt><span class="term">What are the most common blunders in driver
settings on Windows clients?</span></dt><dd><p>Don't use <span class="emphasis"><em>Optimize for
Speed</em></span>: use <span class="emphasis"><em>Optimize for
Portability</em></span> instead (Adobe PS Driver) Don't use
<span class="emphasis"><em>Page Independence: No</em></span>: always
settle with <span class="emphasis"><em>Page Independence:
Yes</em></span> (Microsoft PS Driver and CUPS PS Driver for
WinNT/2K/XP) If there are problems with fonts: use
<span class="emphasis"><em>Download as Softfont into
printer</em></span> (Adobe PS Driver). For
<span class="emphasis"><em>TrueType Download Options</em></span>
choose <span class="emphasis"><em>Outline</em></span>. Use PostScript
Level 2, if you are having trouble with a non-PS printer, and if
there is a choice.</p></dd><dt><span class="term">I can't make <b class="command">cupsaddsmb</b> work
with newly installed printer</span></dt><dd><p>Symptom: the last command of
<b class="command">cupsaddsmb</b> doesn't complete successfully:
<b class="command">cmd = setdriver printername printername</b> result was
NT_STATUS_UNSUCCESSFUL then possibly the printer was not yet
"recognized" by Samba. Did it show up in <span class="emphasis"><em>Network
Neighbourhood</em></span>? Did it show up in <b class="command">rpcclient
hostname -c 'enumprinters'</b>? Restart smbd (or send a
<b class="command">kill -HUP</b> to all processes listed by
<b class="command">smbstatus</b> and try
again.</p></dd><dt><span class="term">My permissions on
<tt class="filename">/var/spool/samba/</tt> get reset after each
reboot</span></dt><dd><p>Have you by accident set the CUPS spool directory to
the same location? (<i class="parameter"><tt>RequestRoot
/var/spool/samba/</tt></i> in <tt class="filename">cupsd.conf</tt> or
the other way round: <tt class="filename">/var/spool/cups/</tt> is set as
<i class="parameter"><tt>path</tt></i> in the <i class="parameter"><tt>[printers]</tt></i>
section). These <span class="emphasis"><em>must</em></span> be different. Set
<i class="parameter"><tt>RequestRoot /var/spool/cups/</tt></i> in
<tt class="filename">cupsd.conf</tt> and <i class="parameter"><tt>path =
/var/spool/samba</tt></i> in the <i class="parameter"><tt>[printers]</tt></i>
section of <tt class="filename">smb.conf</tt>. Otherwise cupsd will
sanitize permissions to its spool directory with each restart, and
printing will not work reliably.</p></dd><dt><span class="term">My printers work fine: just the printer named "lp"
intermittently swallows jobs and spits out completely different
ones</span></dt><dd><p>It is a very bad idea to name any printer "lp". 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
loadbalancing the jobs across them in a round-robin fashion. Chances
are high that someone else has an "lp" named printer too. You may
receive his jobs and send your own to his device unwittingly. To have
tight control over the printer names, set <i class="parameter"><tt>BrowseShortNames
No</tt></i>. It will present any printer as "printername@cupshost"
then, giving you a better control over what may happen in a large
networked environment.</p></dd><dt><span class="term">How do I "watch" my Samba server?</span></dt><dd><p>You can use <b class="command">tail -f
/var/log/samba/log.smbd</b> (you may need a different path) to
see a live scrolling of all log messages. <b class="command">smbcontrol smbd
debuglevel</b> tells you which verbosity goes into the
logs. <b class="command">smbcontrol smbd debug 3</b> sets the verbosity to
a quite high level (you can choose from 0 to 10 or 100). This works
"on the fly", without the need to restart the smbd daemon. Don't use
more than 3 initially; or you'll drown in an ocean of
messages.</p></dd><dt><span class="term">I can't use Samba from my WinXP Home box, while
access from WinXP Prof works flawlessly</span></dt><dd><p>You have our condolences! WinXP home has been
completely neutered by Microsoft as compared to WinXP Prof: you can
not log into a WinNT domain. It cannot join a Win NT domain as a
member server. While it is possible to access domain resources, users
don't have "single sign-on". They need to supply username and password
each time they connect to a resource. Logon scripts and roaming
profiles are not supported. It can serve file and print shares; but
only in "share-mode security" level. It can not use "user-mode
security" (what Windows 95/98/ME still can
do).</p></dd><dt><span class="term">Where do I find the Adobe PostScript driver files
I need for "cupsaddsmb"?</span></dt><dd><p>Use <b class="command">smbclient</b> to connect to any
Windows box with a shared PostScript printer: <b class="command">smbclient
//windowsbox/print\$ -U guest</b>. You can navigate to the
<tt class="filename">W32X86/2</tt> subdir to <b class="command">mget ADOBE*</b>
and other files or to <tt class="filename">WIN40/0</tt> to do the same. --
Another option is to download the <tt class="filename">*.exe</tt> packaged
files from the Adobe website.</p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2966041"></a>An Overview of the CUPS Printing Processes</h3></div></div><div></div></div><p>
</p><div class="figure"><a name="id2966052"></a><p class="title"><b>Figure 19.15. CUPS Printing Overview</b></p><div class="mediaobject"><img src="projdoc/imagefiles/a_small.png" alt="CUPS Printing Overview"></div></div><p>
</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="printing.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="VFS.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 18. Classical Printing Support </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 20. Stackable VFS modules</td></tr></table></div></body></html>
|
