-
Notifications
You must be signed in to change notification settings - Fork 16
/
README
2876 lines (2459 loc) · 115 KB
/
README
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
Foomatic Database
=================
foomatic-db
-----------
The collected knowledge about printers, drivers, and driver options in
XML files, used by foomatic-db-engine to generate PPD files.
Till Kamppeter <till.kamppeter@gmail.com>
http://www.openprinting.org/
This README contains mainly info for developers. See the file USAGE if
you want to know how to use Foomatic.
Copying
-------
To most of this package the GPL applies (see http://www.gnu.org/),
exception are the PPD files in db/source/PPD, they can have different
licenses (mostly MIT), see the comments in the beginning of the PPD
files and the license texts in the corresponding driver XML files.
Bugs
----
If you spot a data error or any other bug, please report it on the
OpenPrinting bug tracking system:
http://bugs.linux-foundation.org/
Choose "OpenPrinting" as the product and "foomatic-db-engine" as the
component.
Intro
-----
This is the stable version of Foomatic. This version is also the base
of our database web interface on
http://www.openprinting.org/
Programs and important files from this package
----------------------------------------------
configure.ac
The source from which GNU autoconf generates the "configure" script
acinclude.m4
Additional macros for the "configure" script
make_configure
Calls aclocal and autoconf to generate "configure" from "configure.ac"
and "acinclude.m4"
Makefile.in
The template from which "configure" generates the Makefile
install-sh
Helper script for "configure"
sanitize-ppd-names
This script sanitizes the file names of the files in db/source/PPD/,
the ready-made PPD files, usually contributed by printer
manufacturers for their PostScript printers. Sometimes these files
have spaces or other special characters in their names, which makes
handling them with shell scripts difficult. This script sanitixes
the names removing these characters.
It should be run after accepting each manufacturer PPD file
contribution into the GIT repository. When running in a cloned GIT
repository (with ".git/" directory) it renames the files with "git
mv" so that the correction can easily get committed.
db/
The XML database. See below.
xmlschema/*.xsd
XML Schema files to verify the XML database entries. There is one for
each XML file type (printer, driver, option) and an additional one (types.xsd)
which is used by the first three.
To verify XML files run
xmllint --noout --schema xmlschema/<type>.xsd db/source/<type>/<file>.xml
For example for a driver:
xmllint --noout --schema xmlschema/driver.xsd db/source/driver/ljet4.xml
For all printers use:
xmllint --noout --schema xmlschema/printer.xsd db/source/printer/*.xml\
Do this check whenever you create or edit XML files to assure that your
XML file is correct.
Dependencies
------------
This package does not require anything else. It is needed by
foomatic-db-engine, the database engine of Foomatic. It is required to
use foomatic-db-engine 4.0.0 or newer, as it contains important bug
fixes and also support for nested composite options. Do not use this
database with older versions of Foomatic.
See the USAGE file for installation details.
About the database
------------------
The database is provided by this package, additional database entries
are in "foomatic-db-hpijs", other Foomatic XML files and PPDs are
supplied with the drivers. "foomatic-db-engine" is needed to make use
of the Foomatic XML data.
The database is located in one system directory, usually
/usr/share/foomatic, but it can be also at other places (Install this
package at first and after that foomatic-db-engine so that
foomatic-db-engine gets configured correctly automatically). In this
directory there is the following structure:
db/ - the database
db/oldprinterids - translation table for old numerical
printer IDs
db/kitload.log - list of third-party "kit" files, logged
by foomatic-kitload
db/source/ - "source" data, provided by humans, etc
db/source/printer/<poid>.xml - printer-specific data, one per printer id
db/source/driver/<driver>.xml - driver-specific data, one per driver name
db/source/opt/<idx>.xml - option data, one file per option
db/source/PPD/ - Ready-made PPD files, usually supplied by
printer manufacturers for their PostScript
printers.
You can edit the files whenever you want and regenerate the affected
printer queues with foomatic-configure, there is no on-disk cache, the
data is always directly derived from the source files. So your changes
will be taken into account without any special steps.
Data
----
There are three main source datafiles (printers, drivers, and options;
annotated examples:
printer/HP-LaserJet_4000.xml
============================
# The printer file contains information specific to a particular
# printer.
<printer id="printer/HP-LaserJet_4000">
# Make and model are not internationalized. There will eventually be
# an "alias" mechanism, but the need is different.
<make>HP</make>
<model>LaserJet 4000</model>
# According to the Adobe specifications for PPD files every PPD file
# must contain a unique DOS-compatible file name (the "*PCFileName"),
# a file name with an up to 8 characters log base name and an up to 3
# characters long extension, and upper and lower case letters being
# considered as equal. As every PPD file is for a printer/driver
# combo, we let the first 6 characters being provided by the printer
# entry:
<pcmodel>HPLJ4K</pcmodel>
# The first two characters should be the manufacturer prefix as listed
# in Appendix D of Adobe's "PostScript Printer Description (PPD) File
# Format Specification Version 4.3", available on
# http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf
# Various stuff about the machine
<mechanism>
# Printer types can be <laser />, <led />, <inkjet />, <dotmatrix />,
# <impact />, <sublimation />, <transfer />, <thermal />. Other types
# we have to add to the CGI script on OpenPrinting to make the web
# interface displaying them properly.
<laser/>
# At some point we can make color be less of a boolean flag and more
# of a section full of goodies.
<!--not "color"-->
<resolution>
# In theory this is a list. In practice We've only got one per
# printer which is the maximum resolution the manufacturer claims for
# this printer. Do not put empty tags (like "<x></x>" or "<x />" here
# if the resolution is not known. Leave out the tags (or the whole
# <resolution> section).
<dpi>
<x>1200</x>
<y>1200</y>
</dpi>
</resolution>
<consumables>
# Information about ink, drums, etc.
# The comments are supposed to be qualitative ("Separate drum and
# toner cartridges")
<comments>
<en>toner</en>
</comments>
# There can be <partno>12A1975</partno> elements with manufacturer
# part numbers for the various carts, etc it takes. Unfortunately,
# this is not made use of, one could make a consumable database with
# this for example.
<!--one or more "partno" elements.-->
</consumables>
</mechanism>
<url>http://www.pandi.hp.com/pandi-db/prod_info.show?model=C4118A&name=LaserJet4000</url>
# The lang section. In practice this will be only minimally useful;
#
# - Backends can pstops the ps down a level if needed
# - Backends know if pjl options apply
# - Backends can know if direct text printing will work
#
# Commonly used language tags: <pcl level="x" />, <escp2 />, <proprietary />
<lang>
<postscript level="2" />
<pjl/>
<text>
<charset>us-ascii</charset>
</text>
</lang>
# The autodetection stuff
<autodetect>
# There are three ways to auto-detect a printer, via the parallel port
# (<parallel>...</parallel>), the USB (<usb>...</usb>), or SNMP
# (TCP/Socket-connected printer, <snmp>...</snmp>). Through these
# interfaces the printers report back an IEEE-1284-complient ID string
# from which the fields "MFG" (<manufacturer>...</manufacturer>),
# "MDL" (<model>...</model>), "DES" (<description>...</description>),
# and "CMD" (<commandset>...</commandset>) are used. The string itself
# can be put between <ieee1284>...</ieee1284> tags, but all items
# which are not constant for all printers of this model, as the serial
# number ("SERN:...;") and the device status ("VSTATUS:...;") have to
# be removed here. As the ID string is usually the same for all
# detection methods, one can put the entries between
# <general>...</general> tags, then the <parallel>...</parallel>,
# <usb>...</usb>, and <snmp>...</snmp> are only used for
# differences to the data between the <general>...</general> tags. A
# complete entry could look like:
#
# <autodetect>
# <general>
# <ieee1284>MFG:HEWLETT-PACKARD;MDL:DESKJET 600;CMD:MLC,PCL,PML;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard DeskJet 600;</ieee1284>
# <commandset>MLC,PCL,PML</commandset>
# <description>Hewlett-Packard DeskJet 600</description>
# <manufacturer>HEWLETT-PACKARD</manufacturer>
# <model>DESKJET 600</model>
# </general>
# </autodetect>
#
# If you use CUPS, you get the device IDs of all locally connected
# (USB, parallel) printers and of printers in the local network by
# running:
lpinfo -l -m
# On Linux you find this info for the parallel ports (/dev/lp<N>, <N>
# = 0, 1, 2, ...) in the files
#
# /proc/sys/dev/parport/parport<N>/autoprobe*
#
# for the USB under Linux it is more complicated, easiest is to use a little
# Perl script, called "getusbprinterid.pl":
# You need to find the IOCTL call value to pass to the perl ioctl function.
# Here is a little C program that does this. This is easier than trying to
# use p2h and convert the *.h files to perl.
# --------------------------------------------------------------------------
# /*
# print the IOCTL call value for printer information
# */
# #include <stdio.h>
# #include <sys/ioctl.h>
# /* From the /usr/src/linux<version>/drivers/usb/printer.c */
# #define DRIVER_VERSION "v0.11"
# #define DRIVER_AUTHOR "Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal"
# #define DRIVER_DESC "USB Printer Device Class driver"
#
# #define USBLP_BUF_SIZE 8192
# #define DEVICE_ID_SIZE 1024
#
# /* ioctls: */
# #define LPGETSTATUS 0x060b /* same as in drivers/char/lp.c */
# #define IOCNR_GET_DEVICE_ID 1
# #define IOCNR_GET_PROTOCOLS 2
# #define IOCNR_SET_PROTOCOL 3
# #define IOCNR_HP_SET_CHANNEL 4
# #define IOCNR_GET_BUS_ADDRESS 5
# #define IOCNR_GET_VID_PID 6
# /* Get device_id string: */
# #define LPIOC_GET_DEVICE_ID(len) _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)
# /* The following ioctls were added for http://hpoj.sourceforge.net */
# /* (HPOJ is replaced by HPLIP, http://hplipopensource.com/): */
# /* Get two-int array:
# * [0]=current protocol (1=7/1/1, 2=7/1/2, 3=7/1/3),
# * [1]=supported protocol mask (mask&(1<<n)!=0 means 7/1/n supported): */
# #define LPIOC_GET_PROTOCOLS(len) _IOC(_IOC_READ, 'P', IOCNR_GET_PROTOCOLS, len)
# /* Set protocol (arg: 1=7/1/1, 2=7/1/2, 3=7/1/3): */
# #define LPIOC_SET_PROTOCOL _IOC(_IOC_WRITE, 'P', IOCNR_SET_PROTOCOL, 0)
# /* Set channel number (HP Vendor-specific command): */
# #define LPIOC_HP_SET_CHANNEL _IOC(_IOC_WRITE, 'P', IOCNR_HP_SET_CHANNEL, 0)
# /* Get two-int array: [0]=bus number, [1]=device address: */
# #define LPIOC_GET_BUS_ADDRESS(len) _IOC(_IOC_READ, 'P', IOCNR_GET_BUS_ADDRESS, len)
# /* Get two-int array: [0]=vendor ID, [1]=product ID: */
# #define LPIOC_GET_VID_PID(len) _IOC(_IOC_READ, 'P', IOCNR_GET_VID_PID, len)
#
#
# int main( int argc, char *argv, char *envp[] )
# {
# int len = 1024;
# int v;
# /* _IOC(), _IOC_READ as defined in /usr/include/asm/ioctl.h
# LPIOC_GET_DEVICE_ID(len) = _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)
# */
# v = LPIOC_GET_DEVICE_ID(len); printf("$LPIOC_GET_DEVICE_ID = 0x%08x;\n", v );
# v = LPIOC_GET_BUS_ADDRESS(len); printf("$LPIOC_GET_BUS_ADDRESS = 0x%08x;\n", v );
# v = LPIOC_GET_VID_PID(len); printf("$LPIOC_GET_VID_PID = 0x%08x;\n", v );
# return(0);
# }
#
#
# save this to a file, say getv.c, compile and run it, and you get an output
$ like this:
# $LPIOC_GET_DEVICE_ID = 0x84005001;
# $LPIOC_GET_BUS_ADDRESS = 0x84005005;
# $LPIOC_GET_VID_PID = 0x84005006;
# Here is the getusbprinterid.pl PERL program to get the usb information
#
# !/usr/bin/perl
# open FILE, "$ARGV[0]" or die "cannot open $ARGV[0]";
# my $result;
# # len = 1024
# # LPIOC_GET_DEVICE_ID(len) = _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)
# # _IOC(), _IOC_READ as defined in /usr/include/asm/ioctl.h
# $LPIOC_GET_DEVICE_ID = 0x84005001;
# $LPIOC_GET_BUS_ADDRESS = 0x84005005;
# $LPIOC_GET_VID_PID = 0x84005006;
#
# ioctl(FILE, $LPIOC_GET_DEVICE_ID , $result) or die;
# # Cut resulting string to its real length
# my $length = ord(substr($result, 1, 1)) + (ord(substr($result, 0, 1)) << 8);
# $result = substr($result, 2, $length-2);
# # Remove non-printable characters
# $result =~ tr/[\x0-\x1f]/\./;
# print "DeviceID $result\n";
#
# $result = pack("LL",0);
# ioctl(FILE, $LPIOC_GET_BUS_ADDRESS , $result) or die;
# my( $v1, $v2 ) = unpack("LL", $result );
# print "Bus '$v1', Device '$v2'\n";
#
# $result = pack("LL",0);
# ioctl(FILE, $LPIOC_GET_VID_PID, $result) or die;
# my( $v1, $v2 ) = unpack("LL", $result );
# print "Vendor '$v1', Product '$v2'\n";
#
# close FILE;
#
#
# --------------------------------------------------------------------------
# Running the program with "perl getusbprinterid.pl /dev/usb/lp0" returns the
# ID string of the device on /dev/usb/lp0.
# For example: perl getusbprinter.pl /dev/usb/lp0
# DeviceID MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:\
# HP LaserJet 2200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 2200;\
# MEM:8MB;OPTRAY:250Sheets
# Bus '2', Device '2'
# Vendor '1008', Product '535'
#
# (lines broken for clarity)
<!--no known parport probe information-->
</autodetect>
# Our grading system. It's US-style letter grades A, B, D, and F,
# which the website shows as "Perfectly", "Mostly", "Partially" and
# "Paperweight" .
# THERE IS NO `C'!!!
<functionality>A</functionality>
# Arguably, the scores should live with the printer/driver association
# and not on the printer, but then it's a big hassle to figure out if
# a printer works... So the score is the one reached with the driver
# working best, the "recommended" driver.
# There's a spot for this "recommended" driver, usually the driver
# which gives the maximum output quality. It is for user information
# on the web site, but newbie-friendly printer setup GUIs should use
# it, too. system-config-printer, printer setup tool of Fedora/Red
# Hat, Ubuntu, and Mandriva Linux makes use of it, also the former
# printerdrake of Mandriva Linux.
<driver>Postscript-HP</driver>
# The following optional section describes with which drivers this
# printer works. A valid printer/driver pair can be defined by either
# adding the printer to the driver's printer list (the way how it
# worked all the time) but also by adding the driver to the printer's
# driver list. This way a printer can get associated with a driver for
# which there is no driver XML file and a driver can list a supported
# printer which is not in the printer XML database. For providing a
# PPD file both printer and driver XML files must exist, but it is not
# important in which of the two the printer/driver relationship is
# defined.
# The driver list in the printer XML files was introduced for once
# defining links to ready-made PPD files (relative paths without "/",
# "http:", "https:", or "ftp:" in the beginning are relative to
# $libdir/db/source/, absolute links can point to external sites, as
# for example the site of a printer manufacturer, but they must always
# provide the non-interactive download of the PPD file, for example
# via "wget") and second, listing the supported drivers for
# visitor-contributed printer entries (from web input form). The
# comments section is for adding comments specific to the
# printer/driver combo. As it is human-readable it is
# internationalized. Each driver entry here must have a driver ID. PPD
# file link and comment are optional.
<drivers>
<driver>
<id>Postscript-HP</id>
<ppd>PPD/HP/HP_LaserJet_4000_Series.ppd</ppd>
<comments><en>...</en></comments>
</driver>
</drivers>
# The <unverified /> tag marks entries which are entered by visitors
# via the printer input form on the OpenPrinting web site. It does not
# appear in approved entries (= all entries in the BZR repository of
# the foomatic-db package).
<!--not "unverified"-->
# If there is a web site with additional interesting info about this
# printer, it can be mentioned in the entry by putting it between
# <contrib_url>...</contrib_url> tags,
<!--no "contrib_url"-->
# The regular notes section. The allowed tags are: <p>, <a
# href="foobar"> </a> and many other simple tags (<b>, <i>, <tt>,
# ...). Note that to distinguish what is XML and what is the embedded
# HTML, the following replacements have to be made:
#
# < --> <
# > --> >
# " --> "
# ' --> '
# & --> &
#
<comments>
<en>
I don't believe this:<p>
<i>1200x1200 dpi only possible with Windows drivers,
600x600 can be reached w/o particular software.
The difference is visible, but only slightly, so
the Functionality got "Mostly"<p></i><p>
Do the following:<p>
Set the resolution on the front panel to "Prores 1200", not
to "Fastres 1200". When you use CUPS with HPs PPD file, turn
off "Fastres 1200" in the printer configuration
options.<p>
Try the generic PostScript PPD file which comes with KUPS 1.0 or newer.
</en>
</comments>
</printer>
driver/md2k.xml
===============
The driver files contain information about drivers. There are a few
things, but the two biggies are the prototype and the printers list
<driver id="driver/md2k">
<name>md2k</name>
# According to the Adobe specifications for PPD files every PPD file
# must contain a unique DOS-compatible file name (the "*PCFileName"),
# a file name with an up to 8 characters log base name and an up to 3
# characters long extension, and upper and lower case letters being
# considered as equal. As every PPD file is for a printer/driver combo,
# we let the last 2 characters being provided by the driver entry:
<pcdriver>M2</pcdriver>
# The drivers listed by the OpenPrinting database are usually not
# developed by OpenPrinting. Most free software printer drivers come
# from independent projects, initiated by peopke who want to get their
# printers to work under Linux, some other drivers come from the
# printer manufacturers. So even if OpenPrinting hosts a downloadable
# package of the driver the development of the driver is not part of
# OpenPrinting. Therefore every driver entry has to contain a
# reference to the developers of the driver, where the driver can be
# actually downloaded. The appropriate link goes into the <url> tag:
<url>http://plaza26.mbn.or.jp/~higamasa/gdevmd2k/</url>
# The driver XML files can contain the following tags to describe the
# driver's properties, so that a user can easily find the driver which
# is most suitable for him. The properties are shown in the gray
# driver info boxes on the OpenPrinting web site and they are also
# supposed to be shown by printer setup tools when they offer to
# download a driver from OpenPrinting. It is especially important to
# supply them if a downloadable driver package or PPD files are
# supplied.
# Supplier's name, internationalization (with <en>...</en><de>...</de>...)
# optional
# <supplier>SpliX project</supplier>
# Does the driver come from the printer's manufacturer or from a third
# party. The third form tells also the manufacturer names of the
# printers which are from the manufacturer which developed the
# driver. If there are also printers from other manufacturers
# supported (like for the PCL driver HPIJS) then the OpenPrinting web
# site does not show this driver as manufacturer-supplied on the pages
# of the printers of other manufacturers.
# <thirdpartysupplied /> OR <manufacturersupplied /> OR
# <manufacturersupplied>HP|Apollo</manufacturersupplied>
# License name. Here should be put the common short name or
# abbreviation if the license is one of the common free software
# licenses. Otherwise it should contain something short and
# descriptive, for non-free drivers simply "Commercial". The license
# name can be internationalized with language tags
# (<en>...</en><de>...</de>...).
# <license>GPL</license>
# The license text does not need to be supplied for common free
# software licenses. It should be supplied if:
#
# - The license is not free (<nonfreesoftware /> tag set)
# - The driver has patent issues (<patents /> tag set, describe the
# patent issues here in that case)
# - The license of the driver is free but none of the common licenses
# (<nonfreesoftware /> tag not set)
# <licensetext>
# <en>
# ...
# </en>
# </licensetext>
# License texts can also be linked from external sites:
# <licensetext>
# <en url="http://www.laserstar.com/licenses/en/gl-series-eula.txt" />
# <de url="http://www.laserstar.com/licenses/de/gl-series-eula.txt" />
# ...
# </licensetext>
# License texts have to be given always as plain text, UTF-8-encoded.
# Mark with this tag whether the driver is non-free software
# <nonfreesoftware />
# All driver entries without this tag are considered to be free
# software.
# This tag tells whether there are any patent issues with the driver
# <patents />
# The absence of the tag tells that the driver is free of patent
# issues.
# If a driver entry provides a <licensetext> and is <nonfreesoftware
# /> or with <patents /> printer setup tools which download this
# driver are supposed to present the license text and ask the user
# whether he agrees with it.
# Printer manufacturers could want to package their drivers for
# different market regions (Europe, Asia/Pacific, Americas, ...) as
# the markets demand different capabilities of printer drivers and
# different user-settable options (CJK-language-related stufff for
# example). So there could even be two different driver flavors for
# the same printer but adapted to different regions. To express these
# driver properties there are special tags.
# For each flavor of the driver a separate driver entry (driver XML
# file) has to be supplied. There is no requirement of certain
# properties of the driver flavors to be equal or not. Especially the
# printer lists can contain printers which are not in all flavors, for
# example if printers are only sold in certain regions. To mark which
# entries are belonging together one adds a group tag to each XML
# file, with the same group name, but the name must be different to
# the names of all already existing groups. A locales tag contains all
# language/country codes for which the driver flavor is intended:
# <group>epson-inkjet</group>
# <locales>de en_UK en_IE fr_FR es_ES</locales>
# The codes in the locales tags should be different for the group
# members, to allow to automatically select the most suitable flavor
# if the detected printer is supported by more than one flavor.
# For downloadable drivers support contacts should be given, so that
# users get informed before they do the download and do not complain
# at their OS distribution vendor if the driver downloaded from
# OpenPrinting does not work. The human-readable string for the
# support contact can be internationalized with language tags
# (<en>...</en><de>...</de>...).
# <supportcontacts>
# <supportcontact level="voluntary" url="http://sourceforge.net/forum/?group_id=175815">SpliX forum at SourceForge</supportcontact>
# <supportcontact level="commercial" url="http://www.laserstar.com/support/">LaserStar Support</supportcontact>
# </supportcontacts>
# This is an internationalized short description of the driver,
# typically one line, to be used in the gray driver info boxes, in the
# driver overview list, and also by printer setup tools. If a driver
# entry is for a development version of a driver, tell it here, as the
# long description is not shown everywhere.
# <shortdescription>
# <en>
# Driver for Samsung SPL2 (ML-1710, ...) and SPLc (CLP-500, ...) laser
# printers
# </en>
# </shortdescription>
# If there are downloadable packages for this driver entry on the
# OpenPrinting web site, a <packages> section has to be supplied. This
# tag tells which package files on the OpenPrinting web server belong
# to this driver or on which external server to find packages for this
# driver. It also allows assigning files or locations to different
# components of this driver and to assign scopes to them. Scopes can
# be: "general", "gui", "printer", "scanner", "fax", ... Uses the
# "general" scope if packages are not split. Wild cards are the same
# as used for file masks in the shell (NOT regular expressions). They
# must match both Debian and RPM package file names. Note that between
# file name and version number is a "-" for RPMs and a "_" for Debian
# packages.
# <packages>
# <package scope="general">*splix[_-]1.[0-9].[0-9]*</package>
# </packages>
# It is possible to give absolute paths which can point to external
# sites, as for example the site of a printer manufacturer, so that
# the package can be hosted there but auto-downloaded via
# OpenPrinting. Important is that these packages are auto-downloadable
# LSB packages and that a non-interactive download is provided (should
# also work with utilities like "wget"). Licenses which the users have
# to agree on have to get supplied in the driver XML file. Printer
# setup tools are supposed to ask the user for agreeing if the driver
# is marked as non-free or with patent issues.
# Example for packages provided by an external site:
# <packages>
# <package scope="general" fingerprint="http://download.example.com/printerdrivers/gpg/key-fingerprint.txt">http://download.example.com/printerdrivers/RPMS/i486/*laserstar*;http://download.example.com/printerdrivers/RPMS/x86_64/*laserstar*;http://download.example.com/printerdrivers/debian/dists/lsb3.2/main/binary-i386/*laserstar*;http://download.example.com/printerdrivers/debian/dists/lsb3.2/main/binary-amd64/*laserstar*</package>
# </packages>
# Note that more than one mask can be supplied separating them with
# semicolons (";").
# The masks with absolute paths must match all package files, of all
# architectures (usually i386/i486 and amd64/x86_64) and all package
# systems (RPM and Debian). Use more than one mask if needed. On your
# server each directory with package files inside must be browsable,
# so that a client can expand the wildcards. In addition the packages
# itself need to be readable for everyone so that they can get
# downloaded.
# Note also that the packages on the external server must be in
# regular package repositories, so that automatic updates with the
# package manager tools provided by the user's Linux distribution
# (currently apt, yum, and zypper) can be performed. The configuration
# data for the local tools is derived from the actual file locations,
# which get determined by the masks.
# Important is also that with paths (absolute starting with "http://",
# "https://", or "ftp://" and relative simply having at least a slash
# somewhere) wildcards can only be used after the last slash ("/"). So
# wildcards are only allowed for the file name and not for the
# directory names.
# If the packages are signed, all packages of the same <package> entry
# should be signed with the same key and the key should be registered
# on the key server network. The key fingerprint should be made
# available as a text file on the web site of the driver issuer and
# the site should be with an SSL certificate which has been signed by
# an official registrar. The "fingerprint=..." parameter should then
# provide the link to the file with the key fingerprint. The link must
# be an "https://..." URL and point to a file on a server of the
# driver issuer. Packages must be signed for fully automatic upload by
# default on Linux distributions. See also
# https://www.linuxfoundation.org/collaborate/workgroups/openprinting/writingandpackagingprinterdrivers
# The <functionality> section should make it easier for a user to
# compare different drivers by giving some technical properties and
# ratings (0...100) for common document types, system load, and
# execution speed. The higher the number, the better the driver
# performs here. It is not required to supply all items. Items can be
# left out or can stay empty. <functionality> sections of the same
# format can also be used in the <printer> entries in the <printers>
# list, to describe exceptions for particular printers. If an item is
# left out or empty there, the appropriate item in the general
# <functionality> section is used, so only the items which are
# different for the given printer need to be listed.
# <functionality>
# <maxresx>1200</maxresx>
# <maxresy>1200</maxresy>
# <color /> OR <monochrome />
# <text>100</text>
# <lineart>100</lineart>
# <graphics>100</graphics>
# <photo>80</photo>
# <load>50</load>
# <speed>90</speed>
# </functionality>
# Not all tags are required here, if the valur for a tag is not known,
# the tag has to be left out. Do not put empty tags (like
# "<text></text>" or "<text />" here.
# The <execution> section describes everything needed to execute the
# driver.
<execution>
# Sometimes it is possible that a driver depends on another driver,
# for example a manufacturer publishes a core driver which is
# completely free software and supports most of their printer. In
# addition, he publishes closed-source plugins for the core driver to
# support additional printers where they cannot open the driver code
# for IP reasons. He wants to link in all his driver packages for
# automatic download with the <packages> tags. To make everything work
# correctly he creates one driver entry for the core driver and one
# for each plugin. The printers which do not need the plugin get
# listed as supported by the core driver, the printers needing a
# plugin are listed as supported by the plugin. To avoid that then
# only a plugin gets automatically downloaded one adds a <requires>
# tag to each entry of a plugin, to the beginning of the <execution>
# section:
# <requires version=">= 5.0.1">gutenprint</requires>
# <requires version=">= 2.7.10">hpijs</requires>
# The version attribute is optional, without, every version is
# accepted. Optional relationships (>=, <=, =, <, >) allow to not only
# accept the given version. The '>´ and '<' have to be replaced by the
# appropriate XML entities, as described earlier here for other text
# in the XML files. More than one <requires> tag is allowed.
# Driver types are
#
# <ghostscript /> : The driver code is compiled into Ghostscript
#
# <ijs /> : IJS plug-in. These are raster drivers which connect
# to the IJS interface of the renderer, usually of
# Ghostscript but also of pdftoijs or others. The
# interface is based on pipes and is bi-directional.
# It makes the driver independent of the renderer.
#
# <cups /> : CUPS Raster driver. The raster driver standard
# introduced by CUPS. The renderer generates the CUPS
# Raster format, a bitmap format optimized for printing,
# and it gets piped into the driver.
#
# <opvp /> : OpenPrinting Vector driver. DLL and IPC interface for
# plugging printer drivers into the renderer. This is
# the only solution of mudular printer drivers for high-
# level graphics (vector) PDLs.
#
# <uniprint /> : A uniprint driver, consisting of one or more .upp
# files for Ghostscript.
#
# <filter /> : The driver code is a separate executable and the
# driver does not fit into the groups listed above,
# usually either a filter which converts generic
# bitmap output of Ghostscript to the printer's
# language, or a wrapper around Ghostscript.
#
# <postscript /> : A driver which has PostScript as output (for
# PostScript printers). It usually does not call
# Ghostscript but only applies the user's option
# settings to the data stream. But Ghostscript can
# be called here, too, as for downgrading to a lower
# PostScript level or for handling PDF input.
#
# The driver type only provides information for the web pages (or
# driver auto-download facilities of printer setup tools), it is not
# used when generating PPD files.
<ghostscript />
# The driver's <execution> section can also contain a
#
# <nopjl />
#
# which suppresses the usage of PJL options (options which send PJL
# commands to the printer). This is done with drivers where the driver
# itself already produces a PJL header and where the PJL options
# defined for the supported printers would badly interfere. In most
# cases this is not needed, as foomatic-rip merges the PJL headers of
# the driver and of the PJL options.
# And the driver's <execution> section can also contain a
#
# <nopageaccounting />
#
# This suppresses the inserting of page accounting code (for CUPS)
# into the PostScript data stream. Some drivers lead to unexpected
# behavior with that. Especially for the generic PostScript drivers
# (which do not use Ghostscript in most cases) the accounting code
# should not be inserted.
# The prototype defines what command the backends run to drive this
# printer. It must take at least PostScript, preferably both PDF and
# PostScript on stdin and generate the printer's native language on
# stdout. Various %A, %B, etc substitution "spots" are specified; this
# is where substition options will be placed.
<prototype>gs -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -sDEVICE=md2k%A%Z -sOutputFile=- -</prototype>
</execution>
<comments>
<en>
Part of the gdevmd2k-0.2a package by Shinya Umino. The web page and
documentation are in Japanese.
<a href="/clippings/MD5000-translation.txt">Here</a>
is an English translation of the driver's web page, and <a
href="/clippings/alpsmd.txt">here</a> is the README from the
driver package.
</en>
</comments>
# if there is only a <prototype> and not a <prototype_pdf> entry,
# foomatic-rip will feed both PostScript and PDF into the command line
# defined with <prototype>, otherwise for PostScript input the
# <prototype> command line is used and for PDF input the
# <prototype_pdf> command line. Both are defined the same way and the
# same command line snippets are inserted from the option settings.
# If there is only a <prototype> defined, PDF will only be fed in if
# the command line begins with "gs " (this means Ghostscript is called
# and Ghostscript understands both PostScript and PDF) and there are
# no options based on inserting active PostScript code into the input
# data stream. Otherwise foomatic-rip converts PDF input to PostScript
# at first and feeds the PostScript through the command line.
# The printer list is a simple list of printers that this driver works
# with. Alternatively, one can tell that a given printer works with a
# given driver also by a <drivers> list in the printer's XML file (see
# above).
<printers>
<printer>
<id>printer/Alps-MD-1000</id><!-- Alps MD-1000 -->
</printer>
<printer>
<id>printer/Alps-MD-1300</id><!-- Alps MD-1300 -->
</printer>
<printer>
<id>printer/Alps-MD-2000</id><!-- Alps MD-2000 -->
</printer>
<printer>
<id>printer/Alps-MD-4000</id><!-- Alps MD-4000 -->
</printer>
</printers>
</driver>
# In the printer list it is also possible to place comments or
# exceptions in the driver's functionality (see above) specific to a
# certain printer/driver pair:
# <printer>
# <id>printer/HP-LaserJet_4050</id><!-- HP LaserJet 4050 -->
# <comments>
# <en>to 1200dpi</en>
# </comments>
# <functionality>
# <monochrome />
# </functionality>
# </printer>
# Note that printer/driver relationships can also be expressed by
# adding the driver to the <drivers> lists of the appropriate printer
# XML files.
source/opt/2.xml
================
# Every option exists independently from printers or drivers, because
# they might apply to arbitrary combinations of printers and/or
# drivers. In practice, some drivers have wholly unique options
# (gutenprint for example), while others (lots of generic basic
# Ghostscript drivers, for example) share some options.
<option type="enum" id="opt/2">
# Options are of a type "enum", "bool", "int", "float", "string", or
# "password", options have an ID. The id is also the filename.
# The shortname is a spaceless short name for the thing. It must not
# contain / or : (otherwise it will not be handled correctly in PPD
# files). It should be one of the standard Adobe PPD option names if
# apropriate
<arg_shortname>
# Various things here, and all <comments>, are internationalized.
# They take the usual posix locale codes in the form xx[_YY], where xx
# is a two-letter iso language code, and YY is two-letter country code
# to distinguish differing national dialects.
#
# Generally the national dialects won't be very common or necessary
# here. The backends currently require that <en> content be provided.
<en>PageSize</en><!-- backends only know <en> shortnames! -->
</arg_shortname>
# The longname is a short phrase describing the thing in more detail
# GUI tools usually show longnames
<arg_longname>
<en>Page Size</en>
</arg_longname>
# The <comments> are used to form documentation. In theory these can
# become man pages or the like. Example:
# <comments>
# <en>
# This option allows the user to get a lighter or darker printout, but
# keeping totally black areas black and not making white areas gray.
# </en>
# </comments>
<!-- A multilingual <comments> block can appear here, too;
it should be treated as documentation for the user. -->
# The execution section describe how the backend should execute this
# option. The order and spot apply to the *driver*'s prototype for
# <arg_substitution /> (once called commandline) style options, or
# just the order applies for <arg_postscript /> and <arg_pjl />