From: Ira McDonald (blueroofmusic@gmail.com)
Date: Mon Mar 09 2009 - 13:53:14 EDT
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@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@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
>
This archive was generated by hypermail 2.1.4 : Mon Mar 09 2009 - 13:53:22 EDT