Hi Rick,
Yes, the DESCRIPTION clause should document this oddity.
For the record we (Rick and Ira) didn't do this.
This property had a pre-existing WRONG enum list - I just
added some to the end from Printer MIB v2 3 years ago.
The (machine-translated) enum list in new CIM_PrintInterpreter
LangType property is CORRECT - it does NOT match this
old stinker.
Since CIM_Printer.DefaultLanguage will be DEPRECATED,
CIM_Printer.LanguagesSupported should be DEPRECATED
- use instead PrintInterpreter.LangType values for both - so
we can make them MUST NOT implement in our future CIM
Network Printer Profile - right?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Mon, Mar 9, 2009 at 1:02 PM, <Richard_Landau at dell.com> wrote:
> Another, um, anomaly in CIM_Printer. Not a bug. Sort of. Maybe we did
> this deliberately, since it appears to make sense, but we ought at least to
> say something to warn poor, naive coders.
>> The enum list of property CIM_Printer.LanguagesSupported does not quite
> match that of prtInterpreterLangFamily, which makes a direct mapping
> impossible. Note that after value 6(PostScript), the numbers do not match.
> Actually, the numbers 7 thru 41 are all shifted up by one because we moved
> number 42 to number 7 in the enum list and shifted all the others up to make
> room. Since 42 was then missing, the numbers after 43 align again. Tricky,
> tricky.
>> I will paint over this nicely in the prototype. I don't think we ought to
> fix it. But we ought to document it. Who would read a 3-page-long enum
> list if he didn't have to?
>> CIM_Printer.mof says (highly abridged excerpts of all docs)
>> ValueMap { "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
>> "11", "12", "13", "14", "15", "16", "17", "18", "19",
>> . . .
>> Values { "Other", "Unknown", "PCL", "HPGL", "PJL", "PS",
>> "PSPrinter", "IPDS", "PPDS",
>> // 10
>> "EscapeP",
>> "Epson", "DDIF", "Interpress", "ISO6429", "Line Data",
>> . . .
>> But RFC3805 says
>> PrtInterpreterLangFamilyTC ::= TEXTUAL-CONVENTION
>> SYNTAX INTEGER {
>> other(1),
>> unknown(2), -- Not in RFC 1759
>> langPCL(3), -- PCL. Starting with PCL version 5,
>> langHPGL(4), -- Hewlett-Packard Graphics Language.
>> langPJL(5), -- Peripheral Job Language. Appears in
>> langPS(6), -- PostScript (tm) Language
>> langIPDS(7), -- Intelligent Printer Data Stream
>> langPPDS(8), -- IBM Personal Printer Data Stream.
>> langEscapeP(9), -- Epson Corp.
>> langEpson(10),
>> langDDIF(11), -- Digital Document Interchange Format
>> langInterpress(12),
>> langISO6429(13), -- ISO 6429. Control functions for
>> langLineData(14), -- line-data: Lines of data as
>> langMODCA(15), -- Mixed Object Document Content
>> And RFC1759 says -- now watch closely, the fingers will never leave the
> hands --
>> prtInterpreterLangFamily OBJECT-TYPE
>> -- This value is a type 2 enumeration
>> SYNTAX INTEGER {
>> other(1),
>> langPCL(3), -- PCL. Starting with PCL version 5,
>> langHPGL(4), -- Hewlett-Packard Graphics Language.
>> langPJL(5), -- Peripheral Job Language. Appears in the
>> langPS(6), -- PostScript Language (tm)
>> langPSPrinter(42), -- The PostScript Language used for
>> langIPDS(7), -- Intelligent Printer Data Stream
>> langPPDS(8), -- IBM Personal Printer Data Stream.
>> langEscapeP(9),
>> langEpson(10),
>> langDDIF(11), -- Digital Document Interchange Format
>> langInterpress(12),
>> langISO6429(13), -- ISO 6429. Control functions for Coded
>> langLineData(14), -- line-data: Lines of data as separate
>> langMODCA(15), -- Mixed Object Document Content Architecture
>> See that tricky out-of-order sequence there, 5, 6, 42, 7, 8, . . . . Once
> again proving the wisdom and foresight of The Hitchhiker's Guide to the
> Galaxy that 42 is more important than it appears at first.
>> I caught this only because one of the languages in the (fake) printer I test
> with most of the time is "Automatic," the value of which changed from 37 to
> 38 as a result of this shift.
>> rick
>> ----------------------
> Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office
> +1-512-728-9023, One Dell Way, RR5-3, MS RR5-32, Round Rock, TX 78682
>