PWG> RE: PMP> How should a PDF document be indicated in

PWG> RE: PMP> How should a PDF document be indicated in

Tom Hastings hastings at cp10.es.xerox.com
Mon Mar 17 17:40:19 EST 1997


>Return-Path: <pmp-owner at pwg.org>
>From: Bob Pentecost <bpenteco at boi.hp.com>
>To: "'Tom Hastings'" <hastings at cp10.es.xerox.com>
>Cc: "'PWG-pmp'" <pmp at pwg.org>
>Subject: RE: PMP> How should a PDF document be indicated in thePrinterMIB,
JobMonitoring MIB and IPP?
>Date: Mon, 17 Mar 1997 14:11:29 PST
>Encoding: 243 TEXT
>Sender: pmp-owner at pwg.org
>
>Tom,
>
>Here are some answers to your questions...
>
>> ----------
>From:  Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> Sent:  Monday, March 17, 1997 10:39 AM
>> To:  Bob Pentecost
>> Subject:  RE: PMP> How should a PDF document be indicated in 
>thePrinterMIB, JobMonitoring MIB and IPP?
>>
>> Bob,
>>
>> I'm not familiar with MIME types that have been registered.
>> 1. Is PCL a registered type?
>
>Yes. HP recently registered PCL, PCLXL and HP-GL.
>
>> 2. Or do you have some printer-independent form of PCL registered?
>
>We chose to register PCL as a single type. A viewer that recognizes the PCL 
>MIME type must be able to understand all PCL commands if it is going to be 
>able to display PCL files created for all printers.
>
>> 3. Where is the MIME registry?
>
>See http://www.isi.edu/in-notes/iana/assignments/media-types/application/
>where you can find vnd.hp-HPGL, vnd.hp-PCL and vnd.hp-PCLXL.
>
>> 4. When you use such a MIME type, are the document contents no longer
>> printer-specific?  I.e., such a PCL MIME type would
>> be printable on both the LaserJet 5 and 5Si?
>
>A file with MIME type PCL could be any level of PCL and could be intended 
>for any printer from DeskJet to LaserJet to Color LaserJet.
>
>Would it be printable on any printer? I think that depends on the software 
>being used. If the software just dumps the file to a printer, it may not 
>work. However, if the software converts the file to some intermediate 
>format and then prints through a printer driver, it could be printed on any 
>printer (the same as the way I can print a .pdf file by using my browser to 
>view it and print it, even though my printer doesn't understand .pdf 
>format).
>
>>
>> This is the kind of *significant* discussion I'd like to have in the PWG
>> with regard to PostScript and PCL.  Can I make our mail discussion
>> public to the PWG, PMP, and JMP DLs?  It looks like a great start to the
>> discussion.
>
>Go ahead and make it public. In fact, I'll just cc PMP on this message.
>
>>
>> We need to understand the difference between a document format and
>> an interpreter (which is what I think is the distinction you are 
>raising).
>> We need to understand which we are specifying in a job submision protocol
>> and so are reporting in the Job Monitoring MIB.
>>
>> Thanks,
>> Tom
>
>Bob Pentecost
>HP
>
>
>>
>> At 15:03 03/14/97 PST, you wrote:
>> >Tom,
>> >
>> >For a document repository, wouldn't it make sense to use MIME types to 
>know
>> >the document format?
>> >
>> >For PCL, we tend to make slight changes from printer to printer even 
>though
>> >they are all considered to be PCL5e. There's no guarantee that a file
>> >generated for a LaserJet 5 will print correctly on a 5Si. Therefore, I
>> >would be hesitant to tie a language pairing to a document.
>> >
>> >Bob
>> >
>> >
>> >----------
>> >From:  Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> >Sent:  Thursday, March 13, 1997 5:06 PM
>> >To:  Bob Pentecost
>> >Subject:  RE: PMP> How should a PDF document be indicated in the
>> >PrinterMIB, JobMonitoring MIB and IPP?
>> >
>> >I think the PWG is aware of the appropriate language pairings for
>> >current levels, e.g., PCL4, PCL5, PCL5e, PS1, PS2, PS3.
>> >
>> >But is PDF part of PS3 or a separate document format or both?
>> >
>> >We really need help in deciding how to represent PCL and PS in these
>> >three standards:  Printer MIB, Job Monitoring MIB, and IPP.
>> >Also these registrations will be used in other places, such as document
>> >repositories where a user wants to know the document-format, so he can
>> >decide which piece of software to use to acces it and to which printers
>> >he/she can send the document, but maybe such use of enums in document
>> >repositories is clouding the issue with the use of these enums in these
>> >three
>> >standards.
>> >
>> >PCL and PostScript "belong" to HP and Adobe, though the rest of us are
>> >affected too.
>> >
>> >Tom
>> >
>> >At 13:48 03/13/97 PST, you wrote:
>> >>Tom,
>> >
>> >I'm not sure what you're asking for. You say "We need some help here   
>from
>> >>Adobe and HP on what is the best course to follow for the Printer MIB, 
>Job
>> >>Monitoring MIB, and IPP." Is help needed to know which are the 
>appropriate
>> >>language-version pairings? Or is help needed to understand whether or 
>not
>> >>this feature is needed at all?
>> >>
>> >>Bob
>> >>
>> >>
>> >>
>> >>----------
>> >>From:  Tom Hastings[SMTP:hastings at cp10.es.xerox.com]
>> >>Sent:  Thursday, March 13, 1997 1:31 PM
>> >>To:  pmp at pwg.org; ipp at pwg.org; jmp at pwg.org
>> >>Subject:  PMP> How should a PDF document be indicated in the Printer 
>MIB,
>> >>JobMonitoring MIB and IPP?
>> >>
>> >>Currently there is no enum registered for a PDF document-format for use
>> >>in the Printer MIB, the Job Monitoring MIB, and IPP.
>> >>
>> >>How should a PDF document be indicated in the Printer MIB, Job 
>Monitoring
>> >>MIB and IPP?
>> >>
>> >>IPP is part of PostScript level 3, I understand, so that the PostScript
>> >>enum langPD(6) with a level of "3" in prtInterpreterLangLevel in the
>> >>Printer MIB could indicate a Printer that is capabile of consuming a 
>PDF
>> >>file.  But what about the Job Monitoring MIB where we don't have level
>> >>and IPP where we don't have level?
>> >>
>> >>Also it seems that a Printer might be able to consume PDF, but not any
>> >>PostScript level 3.  Finally, in a document repository, it would be 
>useful
>> >>to know that a document is a PDF file, so that a PDF reader can be used
>> >>to image it.
>> >>
>> >>We've discussed at several Printer Working Group meetings the idea of
>> >>registering combinations of language family and level in order to give
>> >them
>> >>distinct enums.  So we could register PS1, PS2, PS3, and PDF.  Also 
>PCL5e,
>> >>PCL5, and PCL4 as separate enums for use when a particular level is
>> >>important.
>> >>And we could keep the current langPCL(3) and langPS(6) for use when 
>level
>> >>is not important, or when the level is specified by other attributes,
>> >>such as in the Printer MIB.
>> >>
>> >>The advantage of keeping the family separate from the level, is that an 
>> >old
>> >>application would still have a clue that a new level of document is 
>really
>> >>an upwards compatible level with the enum that it understands, where as 
>if
>> >>we register a new enum for each level, the old application will have no
>> >>clue
>> >>that the document is PostScript.
>> >>
>> >>For IPP, we might have a string, in which the family and level are
>> >>syntactially
>> >>distinguished, so that an old application could separate the family 
>from
>> >>the level.
>> >>
>> >>In the Job Monitoring MIB we have the Printer MIB enum.  But we might
>> >>change to the text string that has both family and level, if that is 
>the
>> >>way that IPP goes.  Then we wouldn't need to register the different 
>levels
>> >>of PostScript and PCL.
>> >>
>> >>However, we may still want to register a PDF enum, since it is such a
>> >>common document format these days.
>> >>
>> >>We need some help here from Adobe and HP on what is the best course to
>> >>follow for the Printer MIB, Job Monitoring MIB, and IPP.
>> >>
>> >>I'd like to see this issue come up in the PWG agenda, since it affect
>> >>all three PWG progjects, if we can't resolve this via e-mail.
>> >>
>> >>Thanks,
>> >>Tom
>> >>
>> >>
>> >>See the current 1.5 or 1.6 IPP Model and Semantics.
>> >>
>> >>Here is the extracted text from that:
>> >>
>> >>5.2.7.1 document-format (type2Enumformat)
>> >>This job attribute identifies the document format of this document, and 
>> >may
>> >>be a per-document attribute.
>> >>
>> >>This printer attribute indicates default value. It also indicates the
>> >>values
>> >>of the attribute supported by this printer and the states of readiness 
>for
>> >>each value. One possible supported and default value is "auto-sense".
>> >>
>> >>The following standard values have been reviewed with the Printer 
>Working
>> >>Group and are registered with IANA as part of the IETF Printer MIB
>> >project.
>> >>The token value assigned by the PWG starts with the four letters: 
>"lang",
>> >>in
>> >>order to follow SNMP ASN.1 rules that all enum symbols shall start with 
>a
>> >>lower case letter.  The token values in IPP shall be the same as the 
>IANA
>> >>token values, with the "lang" removed.  The MIB (integer) value is
>> >included
>> >>here for reference only, the MIB value shall not be used in IPP;  the
>> >token
>> >>value shall be used instead:
>> >>
>> >>Token Value	MIB value	Description
>> >> <<values deleted>
>> >
>> >
>> >
>
>
>
>
>
>



More information about the Pwg mailing list