From pzaan at us.ibm.com Thu Jan 24 14:46:14 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] IJS and capabilities? Message-ID: Robert L Krawitz @freestandards.org on 01/24/2002 06:15:37 AM From: Raph Levien Date: Tue, 22 Jan 2002 16:07:35 -0800 On Mon, Jan 21, 2002 at 05:01:22PM -0600, Mark Hamzy wrote: > > The best order in which to set these parameters is a tricky question. > > What I just proposed will probably work fine for command-line clients, > > but for interactive selection of resolution and quality, there are > > potentially a lot more interactions. > > This is, in my opinion, why one should pass all of the job properties > at once: to avoid problems like this. The options should be passed in > and then the application (Ghostscript) will query what is in effect > (what is the resolution?). It also has the benefit of consolidating the > job properties where there are two places to set things. For example, > there is a Ghostscript option for resolution (-r) but an IJS option for > color space/depth (-dIjsSpace/Depth). > I don't think it's realistic to determine _all_ job properties in > advance. In particular, if you consider the printable area to be > one of the job properties, the client can't really determine this > until it's set a bunch of parameters and then queried for margins. > How about passing all command line parameters, in the order in which > they're presented, followed by all device parameters from the file, > again in the order in which they're presented? Based on the different properties that can be set for a printer, we the capability information is most likely a two pass process. First you have to set a number of the parameters for the printer driver. The easiest ones to think about that typically have a direct correlation on the actual information a renderer or application needs to know are: - Resolution - Printing mode (mono, color, ....) - Media type (possibly causes some changes in values) - Orientation - Form size The above should be done to set the driver's configuration on the first pass then a second pass kind of should be done to query back all of the settings that are pertinent to the print output from the renderer and application point of view. The second pass will allow you the ability to get accurate information about the printable area, color information for rendering, and margins so the page can be accurately displayed or drawn to by the application. The second pass is typically a query against the settings to set up the printable page. On top of this simple approach is how do we get these properties across the network if needed and in what data format? Do we need to store them in something like a job ticket utilizing IPP naming in an XML structure or what? This set of properties needs to be managed between all of the systems and it should be transparent no matter whether it is used locally or not. Should the same way we get these properties into the driver be the same from the spool, application capabilities, and render perspective? Just some additional thoughts about the capabilities and setting of properties. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From rlk at alum.mit.edu Thu Jan 24 17:52:32 2002 From: rlk at alum.mit.edu (Robert L Krawitz) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] Re: [printing-driver] IJS and capabilities? In-Reply-To: (pzaan@us.ibm.com) References: Message-ID: <200201250152.g0P1qWH31290@tiac.net> From: "Pete Zannucci" Date: Thu, 24 Jan 2002 16:46:14 -0600 Robert L Krawitz @freestandards.org on 01/24/2002 06:15:37 AM > How about passing all command line parameters, in the order in which > they're presented, followed by all device parameters from the file, > again in the order in which they're presented? Based on the different properties that can be set for a printer, we the capability information is most likely a two pass process. First you have to set a number of the parameters for the printer driver. The easiest ones to think about that typically have a direct correlation on the actual information a renderer or application needs to know are: - Resolution - Printing mode (mono, color, ....) - Media type (possibly causes some changes in values) - Orientation - Form size And other arbitrary driver-specific options (quality -- which in Gimp-print amounts to resolution plus other information, ink type, etc.) What I propose is to split the first pass, giving highest priority to the command line parameters, and second priority to device parameters in the Postscript file. That's an implementation detail; I agree with your architecture. The above should be done to set the driver's configuration on the first pass then a second pass kind of should be done to query back all of the settings that are pertinent to the print output from the renderer and application point of view. This is necessary, really. I'm agnostic about exactly how this is done; that it is done is what's important. -- Robert Krawitz http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton From alimpich at us.ibm.com Wed Feb 6 13:52:33 2002 From: alimpich at us.ibm.com (Claudia Alimpich) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] Use of job ticket to pass job attributes/properties Message-ID: I am new to this group, so I have gone through and read the previous appends to the various printing forums on Free Standards. There has been some mention of how to pass job attributes. At one point there was mention of using a job ticket. I have spent some time looking at the JDF (Job Definition Format) job ticket which is being developed by CIP4 (International Cooperation for Integration of Processes in Prepress, Press, and Postpress). See www.cip4.org. CIP4 is an international standards organization that currently is comprised of 110 members (companies). JDF is XML-based. There is a JDF API written in C++ that parses the XML into C++ objects (using JDF XML Schema) that are meaningful in context of JDF and creates JDF from the JDF C++ objects. There is currently work going on to port the JDF API to Java. IPP functionality is already supported by JDF. The first version of the JDF specification came out April 2001, and the next version is work in progress. I don't know if anyone in this group is considering the use of JDF, but if not then I think that it is worth the consideration. What is nice about using a job ticket is being able to encapsulate the job control information in a file. What is nice about JDF is that it is XML-based, it is a standard that a lot of companies who do print are involved in, it not only includes job control information (like type of media, orientation, duplex/simplex, tray selection) but also allows the inclusion of status and audit information. So a JDF job ticket could be created by the device driver or some other user interface based on user input, passed along to the spooler, a transform, the printer device, and a finishing device where each would extract the information that it needs and add status and audit information. Another nice thing about JDF is that it is extensible by additional namespaces, so if there is functionality that is unique to a specific vendor that vendor can easily add an attribute for that functionality. Of course, if the functionality is something that should be included as part of JDF then the vendor can propose that it be added to JDF. I just wanted to bring this up to see what you all think about using the job ticket approach and possibly JDF. Claudia Alimpich IBM Printing Systems Division Boulder, CO 303-924-4418 alimpich@us.ibm.com From hlava at us.ibm.com Thu Feb 7 09:28:11 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] Meta-question: NNTP access? Message-ID: Sorry for the meta-question, but is there a news server I can use to get NNTP access to this discussion? (I find using a newsreader instead of e-mail or the web interface a much easier way to follow discussions.) I poked around at http://freestandards.org/mailman/listinfo/printing-spool but didn't see any reference to a news server. Alan Hlava IBM Printing Systems Division -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020207/b0bfa081/attachment.htm From papowell at astart.com Fri Feb 8 18:02:10 2002 From: papowell at astart.com (Patrick Powell) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] Use of job ticket to pass job attributes/properties In-Reply-To: Message-ID: <200202090202.g1922Al62587@h110.private> > From printing-spool-admin@freestandards.org Wed Feb 6 13:54:09 2002 > From: "Claudia Alimpich" > To: printing-spool@freestandards.org > Subject: [printing-spool] Use of job ticket to pass job attributes/properties > Date: Wed, 6 Feb 2002 14:52:33 -0700 > > I am new to this group, so I have gone through and read the previous > appends to the various printing forums on Free Standards. There has been > some mention of how to pass job attributes. At one point there was mention > of using a job ticket. > > I have spent some time looking at the JDF (Job Definition Format) job > ticket which is being developed by CIP4 (International Cooperation for > Integration of Processes in Prepress, Press, and Postpress). See > www.cip4.org. CIP4 is an international standards organization that > currently is comprised of 110 members (companies). JDF is XML-based. There > is a JDF API written in C++ that parses the XML into C++ objects (using JDF > XML Schema) that are meaningful in context of JDF and creates JDF from the > JDF C++ objects. There is currently work going on to port the JDF API to > Java. IPP functionality is already supported by JDF. The first version of > the JDF specification came out April 2001, and the next version is work in > progress. > > I don't know if anyone in this group is considering the use of JDF, but if > not then I think that it is worth the consideration. What is nice about > using a job ticket is being able to encapsulate the job control information > in a file. What is nice about JDF is that it is XML-based, it is a standard > that a lot of companies who do print are involved in, it not only includes > job control information (like type of media, orientation, duplex/simplex, > tray selection) but also allows the inclusion of status and audit > information. So a JDF job ticket could be created by the device driver or > some other user interface based on user input, passed along to the spooler, > a transform, the printer device, and a finishing device where each would > extract the information that it needs and add status and audit information. > Another nice thing about JDF is that it is extensible by additional > namespaces, so if there is functionality that is unique to a specific > vendor that vendor can easily add an attribute for that functionality. Of > course, if the functionality is something that should be included as part > of JDF then the vendor can propose that it be added to JDF. > > I just wanted to bring this up to see what you all think about using the > job ticket approach and possibly JDF. > > Claudia Alimpich > IBM Printing Systems Division > Boulder, CO > 303-924-4418 > alimpich@us.ibm.com > There is general agreement that some sort of 'higher order' information about a job is needed. The problem is when you start to get to the details about content (what is there) and encoding (xml! HTTP headers! Dumb String Tricks!). I think that the choice of using XML for encoding this information is similar to the choice of a goose feather or a pheasant feather for your quill pen. The big question is 'What do you write with it?' The encoding of the information, the identification of the information, and the requiments for information to be present are far harder to resolve than just choosing XML to encode this information. Patrick Patrick Powell Astart Technologies, papowell@astart.com 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.lprng.com) From alimpich at us.ibm.com Fri Feb 8 20:01:43 2002 From: alimpich at us.ibm.com (Claudia Alimpich) Date: Thu Jul 12 13:10:46 2007 Subject: [printing-spool] Re: Use of job ticket to pass job attributes/properties Message-ID: Patrick Powell wrote: > There is general agreement that some sort of 'higher order' > information about a job is needed. The problem is when you start > to get to the details about content (what is there) and encoding > (xml! HTTP headers! Dumb String Tricks!). > > I think that the choice of using XML for encoding this information > is similar to the choice of a goose feather or a pheasant feather > for your quill pen. The big question is 'What do you write with > it?' > >The encoding of the information, the identification of the > information, and the requiments for information to be present are > far harder to resolve than just choosing XML to encode this > information. > > Patrick > > Patrick Powell Astart Technologies, > papowell@astart.com 9475 Chesapeake Drive, Suite D, > Network and System San Diego, CA 92123 > Consulting 858-874-6543 FAX 858-279-8424 > LPRng - Print Spooler (http://www.lprng.com) Maybe I wasn't clear about what JDF is. I agree that it does not make sense to just state that we should use XML, and if that is what came across in my note that was not my intention. Sorry about the confusion. JDF is a job definition format that is XML-based. It has a defined syntax specifically for describing how a job should be printed. So the structure of the XML for a JDF job ticket as well as the specific XML elements and attributes have already been defined for a lot of the printing function. JDF is extensible by the use of namespaces so if, as a printer vendor (software and hardware), you want to specify a function that only your printers understand and support you can easily add it. What we've found is that a lot of the job attributes that describe printing function are already defined in JDF and what isn't there can either be proposed as an addition to JDF (if it is something that could be used by others) or added as a an extension. As I mentioned in my original append, JDF already supports the function provided by IPP, meaning that JDF has JDF-specific XML elements and attributes that define IPP function. My suggestion to look at using a job ticket and in particular JDF is to solve the problem where the information about how to print the job gets transformed multiple times as the job moves through the print system (from UI to print driver to spool to transform to printer to finishing device, etc). The job properties can be left in the job ticket from start to finish and status and audit information can even be added to the job ticket as the job progresses through the print system. Everything any component in the print system needs to know about how to print the job or the job's status is in the job ticket. As an example, here is a snippet of JDF that specifies that the job is to be printed simplex on media pulled from the top tray and stapled in the top left corner. . . . . . . Claudia Alimpich IBM Printing Systems Division alimpich@us.ibm.com From hlava at us.ibm.com Wed Apr 3 10:00:51 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Proposed Spool/Job API standard Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: papi.pdf Type: application/octet-stream Size: 180717 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020403/d306be50/papi.obj From kugler at us.ibm.com Wed Apr 3 11:45:07 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Proposed Spool/Job API standard Message-ID: In section 3.7. Attribute (papi_attribute_t): >This is the structure containing an attribute and its associated value(s). This structure >closely mirrors the IPP model of an attribute. >typedef struct papi_attribute_s >{ >struct papi_attribute_s *next; /* Next attribute in list */ >papi_tag_t group_tag, /* Job/Printer/Oper group tag */ >value_tag; /* What type of value is it? */ >char *name; /* Name of attribute */ >int num_values; /* Number of values */ >papi_value_t values[1]; /* Values */ >} papi_attribute_t; This seems to assume that all the values are of the same type (i.e., share a single value_tag). That isn't necessarily the case. For example, the "media-supported" printer description job template attribute could contain multiple values of multiple types, including keywords, nameWithoutLanguage values, and nameWithLanguage values (presumably corresponding to PAPI_TAG_KEYWORD, PAPI_TAG_NAME, and PAPI_TAG_NAMELANG, respectively). -Carl Kugler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020403/7564ed14/attachment.htm From mike at easysw.com Wed Apr 3 12:13:28 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Proposed Spool/Job API standard Message-ID: <3CAB6268.2070901@easysw.com> Carl Kugler wrote: > ... > This seems to assume that all the values are of the same type > (i.e., share a single value_tag). That isn't necessarily the > case. For example, the "media-supported" printer description > job template attribute could contain multiple values of multiple > types, including keywords, nameWithoutLanguage values, and > nameWithLanguage values (presumably corresponding to > PAPI_TAG_KEYWORD, PAPI_TAG_NAME, and PAPI_TAG_NAMELANG, > respectively). While this is strictly true, the CUPS IPP API (from which the PAPI implementation is based) handles this by tagging all string values with the initial attribute type. Basically, you can have a 1setOf value containing a mix of string values - from the application's standpoint it just sees an array of string values which may or may not have an associated language... I've been thinking about adding the value tag to the string structure (so that strings are properly tagged), however we still have the issue of passing this information in with options (e.g. is "string" a keyword, name, etc...) Currently CUPS is the only IPP implementation I've seen that actually implements the media attributes for a printer or printing system, and it accepts keyword strings tagged as names, and visa-versa (which goes along with the definition of the media attribute in the IPP spec...) For attributes that require a specific value tag, CUPS uses a lookup table of IPP attribute names to figure things out... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Wed Apr 17 05:51:40 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Open Standard Print API (PAPI) Version 0.2 Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: papi.pdf Type: application/octet-stream Size: 199170 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020417/d0fee841/papi.obj From luke.kendall at cisra.canon.com.au Tue Apr 23 19:36:09 2002 From: luke.kendall at cisra.canon.com.au (luke.kendall@cisra.canon.com.au) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Open Standard Print API (PAPI) Version 0.2 In-Reply-To: Message-ID: <20020424021046.79D4D8B20@bellmann.research.canon.com.au> On 17 Apr, Alan Hlava wrote: > Here is Version 0.2 of the Open Print Standard API (PAPI). The major FWIW, I actually had trouble printing this PDF document (and version 0.1 too), from Acrobat 4.0 on Linux. I tried on an HP LaserJet 8000 DN (failed), an 8100 DN (failed), and an 8150 DN (succeeded). It prints fine from xpdf on Linux, and Acrobat 5.0 on Windows, however. luke On the 8100 there was a PS error report printed - a typecheck error for the CCRun command, with a dictionary and what appears to be binary data following it on the stack. From jacobs at printing.eng.sun.com Fri Apr 26 02:49:24 2002 From: jacobs at printing.eng.sun.com (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Comments on: Open Standard Print API (PAPI) Version 0.2 Message-ID: <200204261003.g3QA3Me17192@printing.eng.sun.com> Before I begin, I also had trouble printing out the attached PDF file. Same error, "typecheck" in CCRun. I tried different versions of acroread on Windows and Solaris and xpdf on linux. I ultimately ran "pdf2ps -dLanguageLevel=1" to get something that I could print. Anyway, here are some ramblings on the proposed job/spooler API... I like that it uses the IPP model for printing. The model is simple and covers basic printing. I could be misreading something, but It appears to be a fairly low level mapping of IPP functionality. It surfaces some things that are IPP specific and may require more than a cursory understanding of IPP to use effectively. Personally, I would like to see it abstracted further than it currently is. The API doesn't appear to surface a printer(queue) object or a job object, but rather a server(connection), operations, attributes, and results (a stream of IPP data). This means that when you request a list of queues or jobs, you get back a result and walk through an IPP stream of data, noting the IPP seperators in the stream. As a result, the application developer may need to know more about printing than the existence of printers and jobs. They may need to understand the IPP operations, attribute groups, and encoding (not wire encoding). I would much rather see the result be returned as objects and not a stream of IPP data that the application developer needs to structure. Also, It is likely that some will want to implement the API with more than just IPP at the backend. For example, I know that I will want to support non-IPP print services using rfc-1179, smb, and/or who knows what. In supporting these other print services, it seems to me to be more intuitive to build printer/job structures to pass back, instead of a stream of attributes with IPP groupings and seperators embedded in it. I was thinking more along the lines of ... (this is a stripped down version of an interface that I have been working on/using for a while, but it should illustrate some of what I'm talking about.) #ifdef STRONGLY_TYPED typedef enum { PAPI_STRING, PAPI_INTEGER, PAPI_BOOLEAN, ... } papi_attribute_value_type_t; typedef struct { union { char *string; int integer; char boolean; : } value; } * papi_attribute_value_value_t; #else /* not STRONGLY_TYPED */ #define PAPI_STRING 0x0001 #define PAPI_INTEGER 0x0002 #define PAPI_BOOLEAN 0x0003 : : typedef uint16_t papi_attribute_value_type_t; typedef void * papi_attribute_value_type_t; #endif /* STRONGLY_TYPED */ typedef struct { papi_attribute_value_type_t type; /* type of value */ papi_attribute_value_value_t value; /* opaque data */ } papi_attribute_type_t; typedef struct { char *name; /* attribute name */ attribute_value_t **values; /* NULL terminated list of attribute values */ } papi_attribute_t; typedef struct { papi_attribute_t **attributes; /* NULL terminated attribute list */ papi_document_t **documents; /* optional NULL terminated document list */ } papi_job_t; typedef struct { char *name; /* name used at reference */ char *binding; /* binding used at reference */ papi_attribute_t **attributes; /* NULL terminated attribute list */ } papi_printer_t; /* * Attribute handling routines */ extern int papi_get_value(papi_attribute_t **attributes, const char *name, papi_attribute_value_type_t *type, papi_attribute_value_value_t *value, void **iter); /* performs type conversion if possible */ extern int papi_get_value_as(papi_attribute_t **attributes, const char *name, papi_attribute_value_type_t *type, papi_attribute_value_value_t *value, void **iter); /* performs type conversion if possible */ extern int papi_get_values_as(papi_attribute_t **attributes, /* const char *name, papi_attribute_value_type_t *type, papi_attribute_value_value_t *value, */ ...); extern int papi_add_attribute(papi_attribute_t ***attributes, int flags, char *name, /* papi_attribute_value_type_t *type, papi_attribute_value_value_t *value, */ ...); extern papi_attribute_t *walk_attributes(papi_attribute_t **attributes, void **iter); extern papi_attribute_value_t *walk_attribute_values( papi_attribute_value_t **values, void **iter); /* * Job handling routines (I actually have create/load/commit job * routines in my current API). */ extern int papiGetJobs(const char *queue, papi_job_t ***result, const char *requested_attributes[]); extern int papiGetJob(const char *queue, const char *job, papi_job_t **rslt, const char *requested_attributes[]); extern int papiCancelJob(const char *queue, const char *job_id, papi_job_t **rslt); extern int papiHoldJob(const char *queue, const char *job_id, papi_job_t **rslt); extern int papiReleaseJob(const char *queue, const char *job_id, papi_job_t **rslt); extern int papiSubmitJob(const char *queue, papi_job_t **job); /* * Queue handling routines */ extern int papiQueryPrinter(const char *queue, papi_printer_t **result, const char *requested_attributes[]); /* * Naming routines */ extern int papi_getprinterbyname(const char *name, papi_printer_t **result); extern int papi_getprinterentry(papi_printer_t **result); Ex: papi_printer_t *queue = NULL; char *requested_attributes[] = { "printer-uri", "pdl-supported", "location", NULL }; if (papiQueryPrinter("laser", &queue, requested_attributes) < 0) { fprintf(stderr, "failed to get queue info\n"); return (-1); } dump_queue_info(queue); Ex: int i; papi_job_t **jobs = NULL; char *requested_attributes[] = { "printer-uri", "job-k-octets", "job-owner", "job-name", NULL }; if (papiGetJobs("laser", &jobs, requested_attributes) < 0) { fprintf(stderr, "failed to get jobs\n"); return (-1); } for (i = 0; jobs[i] != NULL; i++) { dump_job(stdout, jobs[i]); : : } Ex: int i; papi_job_t *job = NULL; papi_attribute_t **attrs = NULL; char *files[] = { "/etc/motd", "/etc/syslog.conf", "/tmp/foo", NULL }; job = papi_alloc_job(); papi_add_attribute(&job->attributes, PAPI_EXCL, "job-title", PAPI_STRING, "blah, blah, blah", NULL); papi_add_attribute(&job->attributes, PAPI_EXCL, "copies", PAPI_INTEGER, 1, NULL); : : for (i = 0; files[i] != NULL) { papi_document_t *document = papi_alloc_document(); papi_add_attribute(&document->attributes, PAPI_EXCL, "document-name", PAPI_STRING, files[i], NULL); : : papi_add_document(&job, document); } papiSubmitJob("laser", &job); dump_job(stdout, job); Regardless of whether or not the API is up levelled further, I think that we should avoid setting specific sizes of strings and arrays in the data structures. ex char short_name[PAPI_MAX_NAME]; would become char *short_name; I don't know that anyone else cares, I prefer NULL termination (to count) in arrays of pointers. I guess I just don't like keeping track of the list size and carrying it around. Ex: papi_result_t *papiListPrinters( const papi_object_id_t *object, const papi_common_args_t *common_args, const char *requested_attrs[], const int number_requested_attrs); would become papi_result_t *papiListPrinters( const papi_object_id_t *object, const papi_common_args_t *common_args, const char *requested_attrs[]); While I like the idea of being able to query a print server for the list of printers that it supports, I think that applications should probably be enumerating the list of possible printers(queues) via a naming/configuration db interface, not via a connection to a print server. It is likely that no single print server will contain a complete list. Finally, I tend to look at printer-name (the short name), and printer-uri as being roughly equivalent. That is, if an API caller provides me a URI in the place of a printer name, I simply use it. If they supply me a short name, I resolve it for them (using a naming interface) and use the resulting URI. Something similiar can be said about printer/job name and job-uri. Anyway, that's enough babbling for a while. -Norm From mike at easysw.com Fri Apr 26 12:17:22 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) References: Message-ID: <3CC9A7C2.8020208@easysw.com> Norm Jacobs wrote: > ... > I like that it uses the IPP model for printing. The model is simple > and covers basic printing. I could be misreading something, but It > appears to be a fairly low level mapping of IPP functionality. It surfaces > some things that are IPP specific and may require more than a cursory > understanding of IPP to use effectively. Personally, I would like to see it > abstracted further than it currently is. FWIW, CUPS provides both low-level and high-level interfaces; we might be able to provide PAPI versions of those; I've attached the cups.h header file for your reference (substitute "papi" for "cups" in the file for the generic interface...) Basically, there are convenience interface for options, destinations (printers or classes), and jobs, which is not tied specifically to IPP and can be fairly easily mapped to LPD, etc. > The API doesn't appear to surface a printer(queue) object or a job object, > but rather a server(connection), operations, attributes, and results (a > stream of IPP data). This means that when you request a list of queues or > jobs, you get back a result and walk through an IPP stream of data, noting the > IPP seperators in the stream. As a result, the application developer may need > to know more about printing than the existence of printers and jobs. They > may need to understand the IPP operations, attribute groups, and encoding (not > wire encoding). I would much rather see the result be returned as objects and > not a stream of IPP data that the application developer needs to structure. Well, you get a decoded stream of attributes for an object; it's not the most convenient, but sometimes you need that level of control. (That's one of the reasons we include both the low and high level interfaces in CUPS; most apps don't need the low-level access) > Also, It is likely that some will want to implement the API with more than > just IPP at the backend. For example, I know that I will want to support > non-IPP print services using rfc-1179, smb, and/or who knows what. In > supporting these other print services, it seems to me to be more intuitive to > build printer/job structures to pass back, instead of a stream of attributes > with IPP groupings and seperators embedded in it. Well, there are several ways to handle this. One is to use a URI to specify a particular printer, with the API providing aliases to "short" names (e.g. LaserJet maps to ipp://server/printers/LaserJet, while DeskJet maps to lpd://server/DeskJet) Another is to map this in the scheduler (this is how CUPS does it) so that apps only need to "speak" using one protocol. FWIW, we chose the scheduler route when writing CUPS because it offers the easiest expansion capabilities, makes the resident size of apps smaller, and avoids dependence on shared libraries/ plug-ins to the API. It also means that any filtering can be done locally or on the destination server - putting the protocol support in the application forces the application to do the filtering or depend on the destination server only. > I was thinking more along the lines of ... > (this is a stripped down version of an interface that I have been working > on/using for a while, but it should illustrate some of what I'm talking about.) > ... I think the main problem with this is that you end up with an interface that is neither high nor low level, but something in between. > ... > While I like the idea of being able to query a print server for the > list of printers that it supports, I think that applications should > probably be enumerating the list of possible printers(queues) via a > naming/configuration db interface, not via a connection to a print > server. It is likely that no single print server will contain a > complete list. > ... Again, we need to identify if the API or the printing system should be responsible for device discovery; in general, we've found it to be more efficient to cache the results in one place and provide the "global view" to clients as needed, rather than putting the burden on applications. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com -------------- next part -------------- /* * "$Id: cups.h,v 1.41 2002/03/15 15:43:27 mike Exp $" * * API definitions for the Common UNIX Printing System (CUPS). * * Copyright 1997-2002 by Easy Software Products. * * These coded instructions, statements, and computer programs are the * property of Easy Software Products and are protected by Federal * copyright law. Distribution and use rights are outlined in the file * "LICENSE.txt" which should have been included with this file. If this * file is missing or damaged please contact Easy Software Products * at: * * Attn: CUPS Licensing Information * Easy Software Products * 44141 Airport View Drive, Suite 204 * Hollywood, Maryland 20636-3111 USA * * Voice: (301) 373-9603 * EMail: cups-info@cups.org * WWW: http://www.cups.org * * This file is subject to the Apple OS-Developed Software exception. */ #ifndef _CUPS_CUPS_H_ # define _CUPS_CUPS_H_ /* * Include necessary headers... */ # include "ipp.h" # include "ppd.h" /* * C++ magic... */ # ifdef __cplusplus extern "C" { # endif /* __cplusplus */ /* * Constants... */ # define CUPS_VERSION 1.0115 # define CUPS_DATE_ANY -1 /* * Types and structures... */ typedef unsigned cups_ptype_t; /**** Printer Type/Capability Bits ****/ enum /* Not a typedef'd enum so we can OR */ { CUPS_PRINTER_LOCAL = 0x0000, /* Local printer or class */ CUPS_PRINTER_CLASS = 0x0001, /* Printer class */ CUPS_PRINTER_REMOTE = 0x0002, /* Remote printer or class */ CUPS_PRINTER_BW = 0x0004, /* Can do B&W printing */ CUPS_PRINTER_COLOR = 0x0008, /* Can do color printing */ CUPS_PRINTER_DUPLEX = 0x0010, /* Can do duplexing */ CUPS_PRINTER_STAPLE = 0x0020, /* Can staple output */ CUPS_PRINTER_COPIES = 0x0040, /* Can do copies */ CUPS_PRINTER_COLLATE = 0x0080, /* Can collage copies */ CUPS_PRINTER_PUNCH = 0x0100, /* Can punch output */ CUPS_PRINTER_COVER = 0x0200, /* Can cover output */ CUPS_PRINTER_BIND = 0x0400, /* Can bind output */ CUPS_PRINTER_SORT = 0x0800, /* Can sort output */ CUPS_PRINTER_SMALL = 0x1000, /* Can do Letter/Legal/A4 */ CUPS_PRINTER_MEDIUM = 0x2000, /* Can do Tabloid/B/C/A3/A2 */ CUPS_PRINTER_LARGE = 0x4000, /* Can do D/E/A1/A0 */ CUPS_PRINTER_VARIABLE = 0x8000, /* Can do variable sizes */ CUPS_PRINTER_IMPLICIT = 0x10000, /* Implicit class */ CUPS_PRINTER_DEFAULT = 0x20000, /* Default printer on network */ CUPS_PRINTER_OPTIONS = 0xfffc /* ~(CLASS | REMOTE | IMPLICIT) */ }; typedef struct /**** Printer Options ****/ { char *name; /* Name of option */ char *value; /* Value of option */ } cups_option_t; typedef struct /**** Destination ****/ { char *name, /* Printer or class name */ *instance; /* Local instance name or NULL */ int is_default; /* Is this printer the default? */ int num_options; /* Number of options */ cups_option_t *options; /* Options */ } cups_dest_t; typedef struct /**** Job ****/ { int id; /* The job ID */ char *dest, /* Printer or class name */ *title, /* Title/job name */ *user, /* User the submitted the job */ *format; /* Document format */ ipp_jstate_t state; /* Job state */ int size, /* Size in kilobytes */ priority; /* Priority (1-100) */ time_t completed_time, /* Time the job was completed */ creation_time, /* Time the job was created */ processing_time; /* Time the job was processed */ } cups_job_t; /* * Functions... */ extern int cupsCancelJob(const char *printer, int job); #define cupsDoRequest(http,request,resource) cupsDoFileRequest((http),(request),(resource),NULL) extern ipp_t *cupsDoFileRequest(http_t *http, ipp_t *request, const char *resource, const char *filename); extern http_encryption_t cupsEncryption(void); extern void cupsFreeJobs(int num_jobs, cups_job_t *jobs); extern int cupsGetClasses(char ***classes); extern const char *cupsGetDefault(void); extern int cupsGetJobs(cups_job_t **jobs, const char *dest, int myjobs, int completed); extern const char *cupsGetPPD(const char *printer); extern int cupsGetPrinters(char ***printers); extern ipp_status_t cupsLastError(void); extern int cupsPrintFile(const char *printer, const char *filename, const char *title, int num_options, cups_option_t *options); extern int cupsPrintFiles(const char *printer, int num_files, const char **files, const char *title, int num_options, cups_option_t *options); extern char *cupsTempFile(char *filename, int len); extern int cupsTempFd(char *filename, int len); extern int cupsAddDest(const char *name, const char *instance, int num_dests, cups_dest_t **dests); extern void cupsFreeDests(int num_dests, cups_dest_t *dests); extern cups_dest_t *cupsGetDest(const char *name, const char *instance, int num_dests, cups_dest_t *dests); extern int cupsGetDests(cups_dest_t **dests); extern void cupsSetDests(int num_dests, cups_dest_t *dests); extern int cupsAddOption(const char *name, const char *value, int num_options, cups_option_t **options); extern void cupsEncodeOptions(ipp_t *ipp, int num_options, cups_option_t *options); extern void cupsFreeOptions(int num_options, cups_option_t *options); extern const char *cupsGetOption(const char *name, int num_options, cups_option_t *options); extern int cupsParseOptions(const char *arg, int num_options, cups_option_t **options); extern int cupsMarkOptions(ppd_file_t *ppd, int num_options, cups_option_t *options); extern const char *cupsGetPassword(const char *prompt); extern const char *cupsServer(void); extern void cupsSetEncryption(http_encryption_t e); extern void cupsSetPasswordCB(const char *(*cb)(const char *)); extern void cupsSetServer(const char *server); extern void cupsSetUser(const char *user); extern const char *cupsUser(void); # ifdef __cplusplus } # endif /* __cplusplus */ #endif /* !_CUPS_CUPS_H_ */ /* * End of "$Id: cups.h,v 1.41 2002/03/15 15:43:27 mike Exp $". */ From toratani.yasumasa at canon.co.jp Fri Apr 26 21:28:03 2002 From: toratani.yasumasa at canon.co.jp (Yasumasa Toratani) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Simple question on PAPI Version 0.2 References: <3CC9A7C2.8020208@easysw.com> Message-ID: <117701c1eda3$ebb2f2b0$6a5714ac@torapc> I think PAPI is simple and good to make some printer control applications, and I'd like to confirm the return string of the "papiGetErrorString" function. I assume the "papiGetErrorString" function returns the string based on the status code described in RFC2911, for instance, "successful-ok", "client-error-not-possible", etc, valid? If it's not, and if the application will have to localize some other message strings, we need the list of them, or some other translation mechanism. Tora. From mike at easysw.com Sat Apr 27 03:48:33 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Simple question on PAPI Version 0.2 References: <3CC9A7C2.8020208@easysw.com> <117701c1eda3$ebb2f2b0$6a5714ac@torapc> Message-ID: <3CCA8201.8060503@easysw.com> Yasumasa Toratani wrote: > I think PAPI is simple and good to make some printer control > applications, and I'd like to confirm the return string of the > "papiGetErrorString" function. I assume the "papiGetErrorString" > function returns the string based on the status code described in > RFC2911, for instance, "successful-ok", "client-error-not-possible", > etc, valid? > ... We should probably specify this explicitly; this is how the CUPS code works... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From jacobs at printing.eng.sun.com Thu May 2 11:59:18 2002 From: jacobs at printing.eng.sun.com (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) Message-ID: <200205021913.g42JDMe25202@printing.eng.sun.com> >From: Michael Sweet >Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) > >Norm Jacobs wrote: >> ... >> I like that it uses the IPP model for printing. The model is simple >> and covers basic printing. I could be misreading something, but It >> appears to be a fairly low level mapping of IPP functionality. It surfaces >> some things that are IPP specific and may require more than a cursory >> understanding of IPP to use effectively. Personally, I would like to see it >> abstracted further than it currently is. > >FWIW, CUPS provides both low-level and high-level interfaces; we >might be able to provide PAPI versions of those; I've attached the >cups.h header file for your reference (substitute "papi" for "cups" >in the file for the generic interface...) > >Basically, there are convenience interface for options, destinations >(printers or classes), and jobs, which is not tied specifically to >IPP and can be fairly easily mapped to LPD, etc. It's the higher level that I am interested in seeing standardized and exposed. It isn't bound to a particular spooler/protocol/implementation and provides applications what they need to interact with the print service. There are things that are not addressed at this level, but they tend to be spooler/protocol/implementation specific. Types: papi_job_t, papi_dest_t, papi_attribute_t, papi_error_t Operations: papi_submit_job, papi_cancel_job, papi_hold_job, papi_release_job, papi_modify_job, papi_get_job, papi_get_jobs, ... papi_get_dest, papi_add_dest, papi_set_dest, ... I don't know what attributes a job or destination might contain and which of those attributes a particular application might be interested in. As a result, I would have an attribute list as part of the structures used in the high level interface. This allows the high level interface consumers more complete access to information about the objects without going to a lower level interface. Ex: typedef struct { /* some list of preprocessed attributes, if you like: * id, destination, title, user, ... * I prefer to treat them all equally and access them all * through the same interface. */ papi_attribute_t **attributes; /* using IPP Model as the basis of a schema */ } papi_job_t; extern int papiGetJobs(const char *dest, const papi_attribute_t **match, papi_job_t ***jobs, papi_error_t ***errors); extern int papiPrintFile(const char *dest, const char *file, papi_attribute_t ***attributes, papi_error_t ***errors); extern int papiPrintFiles(const char *dest, const char **files, papi_attribute_t ***attributes, papi_error_t ***errors); Question: Are URLs allowed in place of your filename? In the interface you provide in cups.h, your options (I am using them synonomously with attributes) are neither typed or multi-value. If the types and multi-value are made part if the structure, the application can be more explicit about what it is requesting and have a better understanding of what it received. > >> The API doesn't appear to surface a printer(queue) object or a job object, >> but rather a server(connection), operations, attributes, and results (a >> stream of IPP data). This means that when you request a list of queues or >> jobs, you get back a result and walk through an IPP stream of data, noting the >> IPP seperators in the stream. As a result, the application developer may need >> to know more about printing than the existence of printers and jobs. They >> may need to understand the IPP operations, attribute groups, and encoding (not >> wire encoding). I would much rather see the result be returned as objects and >> not a stream of IPP data that the application developer needs to structure. > >Well, you get a decoded stream of attributes for an object; it's >not the most convenient, but sometimes you need that level of >control. > >(That's one of the reasons we include both the low and high level >interfaces in CUPS; most apps don't need the low-level access) > Your higher level interface from cups.h is more in line with what I was thinking. This provides the more structured results that I was hoping to have. As I said above, this is the level that I am hoping to standardize on. There are a few things in that interface that I might drop or change, but it is closer to the level I was expecting. >> Also, It is likely that some will want to implement the API with more than >> just IPP at the backend. For example, I know that I will want to support >> non-IPP print services using rfc-1179, smb, and/or who knows what. In >> supporting these other print services, it seems to me to be more intuitive to >> build printer/job structures to pass back, instead of a stream of attributes >> with IPP groupings and seperators embedded in it. > >Well, there are several ways to handle this. > >One is to use a URI to specify a particular printer, with the API >providing aliases to "short" names (e.g. LaserJet maps to >ipp://server/printers/LaserJet, while DeskJet maps to >lpd://server/DeskJet) > >Another is to map this in the scheduler (this is how CUPS does it) >so that apps only need to "speak" using one protocol. > >FWIW, we chose the scheduler route when writing CUPS because it >offers the easiest expansion capabilities, makes the resident >size of apps smaller, and avoids dependence on shared libraries/ >plug-ins to the API. It also means that any filtering can be >done locally or on the destination server - putting the protocol >support in the application forces the application to do the >filtering or depend on the destination server only. > True, the applications may have a smaller RSS, but they are now bound to a local server that may or may not be running for a variety of reasons. I'm not saying this is right or wrong, it's simply a different approach. The plug-in approach allows the applications to drop the intermediary and communicate with the print service directly if they like. If they want to use a local intermediary, they can use a plug-in to talk to it. In this case, I expect that difference in RSS would be very small. Regardless, I expect that the API will be at a high enough level to allow implementations of either approach. >> I was thinking more along the lines of ... >> (this is a stripped down version of an interface that I have been working >> on/using for a while, but it should illustrate some of what I'm talking about.) >> ... > >I think the main problem with this is that you end up with an >interface that is neither high nor low level, but something in >between. I don't think that's necessarily true, but you could easily end up with something in between. >> ... >> While I like the idea of being able to query a print server for the >> list of printers that it supports, I think that applications should >> probably be enumerating the list of possible printers(queues) via a >> naming/configuration db interface, not via a connection to a print >> server. It is likely that no single print server will contain a >> complete list. > > ... > >Again, we need to identify if the API or the printing system should >be responsible for device discovery; in general, we've found it to >be more efficient to cache the results in one place and provide >the "global view" to clients as needed, rather than putting the >burden on applications. To make sure we are using the same terminology, I view device discovery as locating a physical device. This would be a feature the print service would use to automatically configure queues for new devices. I view destination enumeration as providing an application with a list of destinations that It can operate against. The list of destinations that can be operated against should not be limitted to a local print services "global" view of the available destinations, but include information from network name services and a user specific view where available. Just because the printer at the local copy shop isn't part of the "global" view that the local print service provides, doesn't mean that I don't want it in my list of available printers. More often than not, each user uses a different subset of printers from the "global" view. There is no reason to require them to look through the entire list for those that they use. There are times when they may want to, but most of the time I wouldn't expect them to. I would hope that the API will address both situations. -Norm From mike at easysw.com Thu May 2 13:37:44 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) References: <200205021913.g42JDMe25202@printing.eng.sun.com> Message-ID: <3CD1A398.7060704@easysw.com> Norm Jacobs wrote: > ... > It's the higher level that I am interested in seeing standardized and > exposed. It isn't bound to a particular spooler/protocol/implementation > and provides applications what they need to interact with the print service. > There are things that are not addressed at this level, but they tend to > be spooler/protocol/implementation specific. > > Types: > papi_job_t, papi_dest_t, papi_attribute_t, papi_error_t > > Operations: > papi_submit_job, papi_cancel_job, papi_hold_job, papi_release_job, > papi_modify_job, papi_get_job, papi_get_jobs, ... > papi_get_dest, papi_add_dest, papi_set_dest, ... > > I don't know what attributes a job or destination might contain and which of > those attributes a particular application might be interested in. As a result, > I would have an attribute list as part of the structures used in the high level > interface. This allows the high level interface consumers more complete access > to information about the objects without going to a lower level interface. > > Ex: > typedef struct { > /* some list of preprocessed attributes, if you like: > * id, destination, title, user, ... > * I prefer to treat them all equally and access them all > * through the same interface. > */ > papi_attribute_t **attributes; /* using IPP Model as the basis > of a schema */ > } papi_job_t; Hmm, I'd offer an opposing view: by only listing attributes you force a compliant implementation to use a particular set of names (e.g. IPP) for specific defined attributes. Better to provide direct-access fields for the common attributes and list the rest, I think. > ... > Question: > Are URLs allowed in place of your filename? Not generally; IPP does support URI-based printing, but CUPS current does not, and there are some serious security implications that may prevent their use. CUPS 1.2 will support URI-based printing, but will have serious security controls available to limit their use. > In the interface you provide in cups.h, your options (I am using them > synonomously with attributes) are neither typed or multi-value. If the > types and multi-value are made part if the structure, the application can > be more explicit about what it is requesting and have a better understanding > of what it received. Multiple values are separated by commas ("1,2,3,4", "1-4,9-12", "letter,transparency,red", etc.) Options are not the same as attributes in CUPS - options are the human-consumable strings, while attributes are the computer-consumable ones. The cupsEncodeOptions() function converts from string options to IPP attributes, mapping known IPP attributes to the correct attribute types, and all unknown attributes to name values. > ... > Your higher level interface from cups.h is more in line with what I was > thinking. This provides the more structured results that I was hoping to > have. As I said above, this is the level that I am hoping to standardize > on. There are a few things in that interface that I might drop or change, > but it is closer to the level I was expecting. There are some additional things being added to the destination structure in CUPS 1.2 (URI, printer type, etc.) as well that we already use in a GUI-based API for ESP Print Pro; I'm not sure how well they will map to other printing systems. The printer instance stuff is unique to CUPS; the closest analogue is SVR4 forms. However, printer instances are very useful and popular among our users and can be implemented without printing system support (they are, after all, just a collection of saved options for the base queue) > ... > True, the applications may have a smaller RSS, but they are now bound > to a local server that may or may not be running for a variety of reasons. > I'm not saying this is right or wrong, it's simply a different approach. > The plug-in approach allows the applications to drop the intermediary > and communicate with the print service directly if they like. If they want > to use a local intermediary, they can use a plug-in to talk to it. In this > case, I expect that difference in RSS would be very small. Regardless, I > expect that the API will be at a high enough level to allow implementations > of either approach. True. > ... >>Again, we need to identify if the API or the printing system should >>be responsible for device discovery; in general, we've found it to >>be more efficient to cache the results in one place and provide >>the "global view" to clients as needed, rather than putting the >>burden on applications. > > > To make sure we are using the same terminology, I view device discovery as > locating a physical device. This would be a feature the print service would > use to automatically configure queues for new devices. I view destination > enumeration as providing an application with a list of destinations that It > can operate against. > > The list of destinations that can be operated against should not > be limitted to a local print services "global" view of the available > destinations, but include information from network name services and a user > specific view where available. Just because the printer at the local copy > shop isn't part of the "global" view that the local print service provides, > doesn't mean that I don't want it in my list of available printers. More > often than not, each user uses a different subset of printers from the "global" > view. There is no reason to require them to look through the entire list for > those that they use. There are times when they may want to, but most of the > time I wouldn't expect them to. I would hope that the API will address > both situations. OK, assuming we provide the printer URI in the high-level interface, the API can hide how this happens. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From jacobs at printing.eng.sun.com Thu May 2 22:41:19 2002 From: jacobs at printing.eng.sun.com (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) Message-ID: <200205030555.g435tNe25975@printing.eng.sun.com> >From: Michael Sweet > >Norm Jacobs wrote: >> ... >> >> I don't know what attributes a job or destination might contain and which of >> those attributes a particular application might be interested in. As a result, >> I would have an attribute list as part of the structures used in the high level >> interface. This allows the high level interface consumers more complete access >> to information about the objects without going to a lower level interface. >> >> Ex: >> typedef struct { >> /* some list of preprocessed attributes, if you like: >> * id, destination, title, user, ... >> * I prefer to treat them all equally and access them all >> * through the same interface. >> */ >> papi_attribute_t **attributes; /* using IPP Model as the basis >> of a schema */ >> } papi_job_t; > >Hmm, I'd offer an opposing view: by only listing attributes you >force a compliant implementation to use a particular set of >names (e.g. IPP) for specific defined attributes. Better to >provide direct-access fields for the common attributes and >list the rest, I think. One way or another, you are going to force compliant implementations to support a common set of attributes. There is simply no way around it. The reality is that all jobs and destinations must contain some small set of common attributes. For me, the rub is that direct-access attributes are accessed differently than other attributes. If I want to dump or search the attributes in a job or destination, I need to have special cases for all of the direct-access attributes. The question then becomes: Which attributes are common attributes? I can live with pulling a small set of "common" attributes, but would prefer to utilize them all through the same method. >> In the interface you provide in cups.h, your options (I am using them >> synonomously with attributes) are neither typed or multi-value. If the >> types and multi-value are made part if the structure, the application can >> be more explicit about what it is requesting and have a better understanding >> of what it received. > >Multiple values are separated by commas ("1,2,3,4", "1-4,9-12", >"letter,transparency,red", etc.) Options are not the same as >attributes in CUPS - options are the human-consumable strings, >while attributes are the computer-consumable ones. The >cupsEncodeOptions() function converts from string options to >IPP attributes, mapping known IPP attributes to the correct >attribute types, and all unknown attributes to name values. Originally, I used strings and separators to represent multi-value attributes, but eventually ran into cases where the separator was part of the value. It was also suggested to me that I might run into issues with strings in charater sets other than ASCII. That is part of the reason I switched to attribute value lists. That, and the fact that I thought I might need to support values of differing type for a single multi-value attribute. While the IPP encoding appears to allow this, it has turned out to be a feature that I haven't really had much use for. >> ... >> Your higher level interface from cups.h is more in line with what I was >> thinking. This provides the more structured results that I was hoping to >> have. As I said above, this is the level that I am hoping to standardize >> on. There are a few things in that interface that I might drop or change, >> but it is closer to the level I was expecting. > >There are some additional things being added to the destination >structure in CUPS 1.2 (URI, printer type, etc.) as well that we >already use in a GUI-based API for ESP Print Pro; I'm not sure >how well they will map to other printing systems. > >The printer instance stuff is unique to CUPS; the closest analogue >is SVR4 forms. However, printer instances are very useful and >popular among our users and can be implemented without printing >system support (they are, after all, just a collection of saved >options for the base queue) I have heard what you are refering to as templating. Not that this necessarily has to do with the API, but are you or have you considered allowing users to maintain their own templates? -Norm From mike at easysw.com Fri May 3 13:42:28 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm Jacobs) References: <200205030555.g435tNe25975@printing.eng.sun.com> Message-ID: <3CD2F634.5050003@easysw.com> Norm Jacobs wrote: > ... > One way or another, you are going to force compliant implementations > to support a common set of attributes. There is simply no way around > it. The reality is that all jobs and destinations must contain > some small set of common attributes. For me, the rub is that > direct-access attributes are accessed differently than other > attributes. If I want to dump or search the attributes > in a job or destination, I need to have special cases for > all of the direct-access attributes. > > The question then becomes: Which attributes are common attributes? > I can live with pulling a small set of "common" attributes, but would > prefer to utilize them all through the same method. Providing an efficient interface requires some level of specialization in the API. I would expect that the job ID and destination (URI?) at a minimum should be kept separate, as they are often used for sorting/filtering. Forcing a lookup for every attribute will result in slow code. It is also possible that you could provide direct access to specific attributes, but also list them in the common list (so either method would work). Then the underlying API code need only reference a handful of common values rather than storing some data in one place and some in another. > ... > Originally, I used strings and separators to represent multi-value > attributes, but eventually ran into cases where the separator was part > of the value. It was also suggested to me that I might run into issues > with strings in charater sets other than ASCII. That is part of the reason Quoting and use of UTF-8 eliminate these problems, and working with strings is necessary when dealing with values that are passed on the command-line. (Strings may not be the most efficient way to deal with attributes, but at some level the API has to provide standard functions for converting to and from strings) > I switched to attribute value lists. That, and the fact that I thought I > might need to support values of differing type for a single multi-value > attribute. While the IPP encoding appears to allow this, it has turned out > to be a feature that I haven't really had much use for. Currently any 1setOf attributes that support different value types are always collections of string values (usually name and keyword) and so are fairly easy to deal with. I don't see that changing anytime soon... > ... >>The printer instance stuff is unique to CUPS; the closest analogue >>is SVR4 forms. However, printer instances are very useful and >>popular among our users and can be implemented without printing >>system support (they are, after all, just a collection of saved >>options for the base queue) > > > I have heard what you are refering to as templating. Not that > this necessarily has to do with the API, but are you or have > you considered allowing users to maintain their own templates? They do; the API provides a standard interface to them, and CUPS includes a user application (lpoptions) for manipulating them. Making this part of the API ensures that users will be able to use these templates/instances/forms from any PAPI application, and will generally improve the end-user experience under UNIX/Linux. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From luke.kendall at cisra.canon.com.au Sun May 5 17:53:25 2002 From: luke.kendall at cisra.canon.com.au (luke.kendall@cisra.canon.com.au) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm J acobs) In-Reply-To: <3CD2F634.5050003@easysw.com> Message-ID: <20020506002730.BFA998B10@bellmann.research.canon.com.au> On 3 May, Michael Sweet wrote: > Providing an efficient interface requires some level of > specialization in the API. I would expect that the job ID and > destination (URI?) at a minimum should be kept separate, as > they are often used for sorting/filtering. Forcing a lookup > for every attribute will result in slow code. Aren't these attributes only examined once per page? 99.999% of the time will be spent in pixel shuffling. > It is also possible that you could provide direct access to > specific attributes, but also list them in the common list > (so either method would work). Then the underlying API code > need only reference a handful of common values rather than > storing some data in one place and some in another. In general, I find duplication of information opens up the danger of the multiple copies of the information becoming inconsistent. I quite like the idea of a dynamic array of attributes. On the topic of UTF8 encoding avoiding problems in attribute separators turning up accidentally in other encodings - that obviously depends on what the attribute separator is. UTF8 only protects you from NUL characters, and / and \, I thought; maybe a few more. Norm Jacobs wrote: > Regardless of whether or not the API is up levelled further, I think that we > should avoid setting specific sizes of strings and arrays in the data > structures. > ex > char short_name[PAPI_MAX_NAME]; > would become > char *short_name; I agree with this. When I read the spec, and saw that all the strings in all the structures were of fixed length, possibly with different maximum sizes (e.g. in papi_object_id_t we have char hostname[HTTP_MAX_HOST], uri[HTTP_MAX_URI], short_name[PAPI_MAX_NAME]), that seemed to have some disadvantages. I wondered whether it was to try to reduce memory fragmentation; but then in the explanation for papi_result_t in section 3.3, I read that it's allocated on the heap. So that theory died. I would suggest that wherever the API is returning a string that is coming from a fixed set of possibilities (like a list of supported paper type names, or a list of known printer model names), that you may as well return a pointer to the actual string. This absolutely minimises fragmentation, simplifies the API (since you don't need to worry about buffers with different maximum sizes), reduces memory cost (since the structures don't contain fixed buffers of the maximum allowed sizes), and speeds the code. I also think that the API needs to specify all known attribute names that can be used, like "printer-name" and "job-uri". I don't see how it's possible to write a generic print-to-any-printer function in an application without knowing all the attribute names - especially, what each means. > I don't know that anyone else cares, I prefer NULL termination (to count) in > arrays of pointers. I guess I just don't like keeping track of the list size > and carrying it around. Sure. The only time it's not suitable is when you're storing binary data that has been returned from the printer, or which is to be sent to it. I also have a suggestion about the return value of many of the functions. Currently, some return an error of papi_result_t type, and some don't. This is allocated on the heap. It is used to return error results - sometimes. For some other range of errors, NULL is used instead. (I don't understand why. Wouldn't it be good to distinguish an incorrect URI from a printer not communicating?) Some functions - e.g. papiGetNextAttribute() - don't return an error like this. What about having a single error result value, which is set via an internal error function at any point? This function records the error in this single private area if it's currently "clean". (Depending on debug or other options, it may also log errors to a specified file.) If the error value is currently "dirty" it doesn't alter it. There would be functions for converting the error value to a string, for reporting whether the current value represents an error or not, and for clearing the error. Warnings are not considered to be errors (nor to "dirty" the error result). *All* functions should return a simple success or failure condition. This would simplify the implementation (*), I feel, as well as the API, and at the same time reduce memory fragmentation. (*) Since errors can be reported at the point at which they first occur, where the maximum amount of information is available, and noted then. And the error result value doesn't have to be percolated up in complex ways. luke From mike at easysw.com Sun May 5 21:32:10 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: Comments on: Open Standard Print API (PAPI) Version 0.2 (Norm J acobs) References: <20020506002730.BFA998B10@bellmann.research.canon.com.au> Message-ID: <3CD6074A.7060807@easysw.com> luke.kendall@cisra.canon.com.au wrote: > On 3 May, Michael Sweet wrote: > >> Providing an efficient interface requires some level of >> specialization in the API. I would expect that the job ID and >> destination (URI?) at a minimum should be kept separate, as >> they are often used for sorting/filtering. Forcing a lookup >> for every attribute will result in slow code. >> > > Aren't these attributes only examined once per page? 99.999% of the > time will be spent in pixel shuffling. But that's a different interface... I'm talking efficient for applications that are querying and displaying the information. > ... > In general, I find duplication of information opens up the danger of > the multiple copies of the information becoming inconsistent. Possibly, however when dealing with a *small* subset of attributes, it should be easy for the API to keep things consistent. Also, in most cases the information will be created once, used, and then destroyed. > ... > On the topic of UTF8 encoding avoiding problems in attribute separators > turning up accidentally in other encodings - that obviously depends on > what the attribute separator is. UTF8 only protects you from NUL > characters, and / and \, I thought; maybe a few more. Well, there are two issues: 1. Support for Unicode text in attribute values. 2. Support for sending attribute values on the command-line. #1 almost requires UTF-8, since otherwise you end up with all sorts of problems with nul-termination, word order, etc. #2 requires a text representation of attributes; users have to be able to specify options on the command-line, and then again when you pass those options to the print drivers. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Thu May 16 06:44:37 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.2 Issues Message-ID: I have tried to sift through the posts here and in the private e-mails I've gotten in order to distill a more formal list of PAPI issues that we can discuss and track. Attached is the current list (I'll re-post it as it's updated, unless/until we get some kind of document repository set up). I'll be setting up a conference call (separate from the regular Thursday calls) to discuss these issues further. I'll post date/time/call-in when I have it set up. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com ISSUES WITH PAPI V0.2 ===================== (Last Updated: May 16 2002) ---------------------------------------------------------------------- 1) Would like the API to be abstracted further from IPP, and be able to handle protocols other than IPP RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: [printing-spool, April 26 2002, Michael Sweet] CUPS provides both low and high-level interfaces, we might want to do something similar in PAPI [printing-spool, May 2 2002, Norm Jacobs] High-level interface should be only one standardized [private correspondence, May 14 2002, Michael Sweet] My point was that protocol mapping should 1) be hidden from the application, and 2) may be more efficiently handled at the printing system level rather than in the client API. The problem is akin to embedding printer drivers in the client API. There are scaling issues beyond a single desktop, the inevitable security and memory use issues, and the somewhat newer issue of "DSO hell" (aka "DLL hell" under Windows) In short, while it should be possible for a compliant implementation of the API to speak multiple protocols, we should do everything possible to hide this and specifically only support those printers that the client API exports to the application. That will ensure that application A works with printing systems B and C without recompilation, etc. If a vendor wants to allow a user to define their own network printers, then their API and supporting tools will have to provide these printers to the application transparently, as if they were a standard print queue. It should hide how the API is talking to the printer/queue. Basically, if the goal is to come up with a generic printing API that can support LPD, IPP, etc., we should only expose a printer URI string for informational purposes. It should not be possible for an application to provide an arbitrary URI for printing, since that could introduce dependencies on other libraries (libsmb for example) and also creates security issues that are beyond the scope of the API. I'd like to see an API that an application developer can link to, e.g.: cc -o app app.c -lpapi -lnsl -lsocket That developer should trust that the application binary will be compatible with multiple implementations of the API for that architecture/OS. Specifically, if Sun provides a PAPI implementation for Solaris and the SVR4 spooler, it should be possible for a user to replace that spooler with CUPS without any changes to the application. Note that this does not preclude a PAPI implementation from supporting different protocols or user-defined queues - the implementation just has to hide that mapping from the application and dlopen() any additional libraries/plug-ins that are required. It might be worth looking at the API that RFC2614 defined for the SLP client library. [private correspondence, May 16 2002, Norm Jacobs] I agree that application compiled and dynamically linked with a PAPI implementation should be able to use an alternate PAPI shared library transparently, via whatever means. (ldconfig, LD_PRELOAD, LD_LIBRARY_PATH, different installed libpapi.so, ...) This means that all PAPI implementations MUST be linked accordingly. If libpapi.so is dependent on libnsl and libsocket, libpapi.so should be built with the dependencies (and not the application). So the example would become: cc -o app app.c -lpapi (libpapi.so would have been built with something like: ld -o libpapi.so ... -lnsl -lsocket so it would already contain references to libnsl and libsocket for it's own use.) If the application requires libnsl or libsocket for it's own use, then it would still have to link with them. Shared libraries should have their dependencies explicitly declared when generated. In other words, as an API consumer, I shouldn't need to know what the API uses, only what it provides. [private correspondence, May 16 2002, Michael Sweet] Unfortunately, many run-time linkers are not this smart so the extra libraries sometimes need to be included when you link your app, too. (AIX is like that, for example) ANSWER: STATUS: open ---------------------------------------------------------------------- 2) Would like results returned as objects instead of IPP attributes RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: [printing-spool, April 26 2002, Michael Sweet] CUPS provides this in its high-level interfaces [printing-spool, May 2 2002, Norm Jacobs] High-level interface should include attribute-type and allow multi-valued attributes, which CUPS interface does not [printing-spool, May 2 2002, Norm Jacobs] Return all attributes the same - in a list of names/values [printing-spool, May 2 2002, Michael Sweet] Return common attributes in fixed fields, return others in list of names/values [printing-spool, May 2 2002, Michael Sweet] CUPS does allow multiple values, separated by commas [printing-spool, May 2 2002, Norm Jacobs] Issues with character sets and parsing comma-separated lists [printing-spool, May 3 2002, Michael Sweet] Possibly return common attrs in fixed fields AND in list [printing-spool, May 5 2002, Luke Kendall] Concern with synching duplicated attr information [printing-spool, May 5 2002, Michael Sweet] Does not feel synching is a problem in this case ANSWER: STATUS: open ---------------------------------------------------------------------- 3) Avoid fixed-size strings in structures, use char* instead RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: [printing-spool, May 5 2002, Luke Kendall] Also in favor of pointers to strings instead of fixed-length ANSWER: STATUS: open ---------------------------------------------------------------------- 4) Use null-termination instead of counts in pointer arrays RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 5) Printer enumeration should be through service/DB outside of the print server RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 6) Printer short-name and URI should be equivalent (use URI if provided, otherwise have the server map/resolve it) RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: [private correspondence, May 14 2002, Michael Sweet] Basically, if the goal is to come up with a generic printing API that can support LPD, IPP, etc., we should only expose a printer URI string for informational purposes. It should not be possible for an application to provide an arbitrary URI for printing, since that could introduce dependencies on other libraries (libsmb for example) and also creates security issues that are beyond the scope of the API. [private correspondence, May 16 2002, Norm Jacobs] I don't see why the API has to disallow the use of arbitrary URIs for printing. If the API implementation doesn't support the URI, it can simply respond that the destination was unknown (and/or unsupported). Regardless of what the application initially supplies, it will ultimately resolve to some form of URI that may or may not be supported by the API implementation. Personally, I tend to prefer using known names for "configured" printer when I print, but there are occasions that I would like to be able to access a printer that is "unconfigured" via something akin to a URI. I have two printers in my home that I use all the time. For convenience, I have named them "hp4050" and "color". I print to them using those names rather than "ipp://server/printers/hp4050" and "ipp://server/printers/color". I also print to a number of printers at work via a VPN. Again, for convenience, I have "configuration" for the printers I use most often, but there are literally thousands of them on the network at work. When I want to print to one that is not "configured" on the client, I use something equivalent to a URI. [private correspondence, May 16 2002, Michael Sweet] If we allow arbitrary URIs, then we should have some interface for reporting the supported URI schemes. It's important that the user and developer get a consistent interface, otherwise the standard provides no benefit. ANSWER: STATUS: open ---------------------------------------------------------------------- 7) Job ID and URI should be equivalent (use URI if provided, otherwise have the server map/resolve it) RAISED: [printing-spool, April 26 2002, Norm Jacobs] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 8) Are URIs allowed in place of the print filename? RAISED: [printing-spool, May 2 2002, Norm Jacobs] EXPLANATION/DISCUSSION: [printing-spool, May 2 2002, Michael Sweet] CUPS 1.2 will allow this, but with strict security controls ANSWER: STATUS: open ---------------------------------------------------------------------- 9) Clarification of printer-enumeration and how the API addresses local vs "global" lists of printer RAISED: [printing-spool, May 2 2002, Norm Jacobs] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 10) Should the API include the concept of printer "templates" (in CUPS, "printer instances") to make job submission easier? local vs "global" lists of printer RAISED: [printing-spool, May 2 2002, Norm Jacobs] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 11) Add IPP attribute list in document for easy reference RAISED: [printing-spool, May 5 2002, Luke Kendall] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 12) Make the error/status data returned simpler and more consistent across all the functions RAISED: [printing-spool, May 5 2002, Luke Kendall] EXPLANATION/DISCUSSION: ANSWER: STATUS: open ---------------------------------------------------------------------- 13) Should job tickets be the ONLY way to specify job options? RAISED: [private correspondence, May 13 2002, Mike Munger] EXPLANATION/DISCUSSION: Concern expressed that we are complicating the implementation by allowing specification of job options in both/either IPP-style attributes and in a job ticket. Suggests that we ONLY allow job option specification via job tickets in the API. ANSWER: STATUS: open -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020516/235a2dea/attachment.htm From hlava at us.ibm.com Thu May 16 13:32:35 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.2 Issues - conference call Message-ID: Here is the information on the teleconference I've set up to discuss issues with PAPI V0.2. Please note that the 8 AM time is USA MOUNTAIN TIME. If you call in, make sure you have a copy of the PAPI V0.2 document and the issues list that I posted earlier since that will be the reference point for discussion. CALL DATE: MAY-21-2002 (Tuesday) CALL TIME: 08:00 AM MOUNTAIN TIME DURATION: 2 hr USA Toll Free Number: 888-603-7011 USA Toll Number: +1-630-395-0142 PASSCODE: 49458 LEADER: Mr Alan Hlava Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020516/42eab01c/attachment.htm From hastings at cp10.es.xerox.com Tue Jun 4 16:21:55 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PWG Job Ticket - schema and simple example Message-ID: <918C79AB552BD211A2BD00805F15CE8506A336F8@x-crt-es-ms1.cp10.es.xerox.com> Following up on the PWG Semantic Model and PWG Job Ticket work, here is a schema and simple Job Ticket example. It follows the semantics of the IPP Model and Semantics, but is in XML. I've attached a .zip file with the schema files and the simple example that is embedded in the mail message below. Single-valued attributes are represented simply as: value Multi-valued attributes (whether one or more values) are represented as: one value one value ... Attributes are separated into Operation Attributes and Job Template attributes, as in the IPP Model and Semantics. Here is the simple example: O. Wright Travel Invoice letter duplex stapeled in triplicate 3 staple two-sided-long-edge na_letter_8.5x11_in -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020604/54d84558/attachment.htm From hlava at us.ibm.com Fri Jun 28 12:07:07 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.3 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ you can find the new version of the Open Standard Print API (PAPI) that Michael, Norm, and I have been working on for the last few weeks. This version (V0.3) is a significant rewrite of the previous version. Please review and post comments to the printing-spool mailing list. (I've tried since Monday to post the document directly to this mailing list, but it gets held because it's too big and no admin seems to let it go through. Thanks to Tom Hastings for giving us access to this ftp site!) Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020628/392e7cee/attachment.htm From hastings at cp10.es.xerox.com Tue Jul 2 18:20:45 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Java 1.4 has Print Service API based on IPP Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90806F6BE@x-crt-es-ms1.cp10.es.xerox.com> Java 1.4 available from Sun in March 2002 has a Print Service API based on IPP/1.1. See: http://java.about.com/library/weekly/aa052002a.htm The [print-spool] free standards WG should take a look at this for consideration of the Print API (PAPI). Here is some more information on the Java 1.4 Print Service API: Print Service API The new Print Service API enables Java applications to: * discover and select print services based on their capabilities; * specify the format of print data; * submit print jobs to services that support the document type to be printed. For more information, see Java Print Service . Here is the initial paragraph from the above URL: The JavaTM Print Service is a new Java Print API that allows printing on all Java platforms, including platforms requiring a small footprint, such as a J2ME profile, but still supports the current Java 2 Print API. Thie Java Print Service API includes an extensible print attribute set based on the standard attributes specified in the Internet Printing Protocol (IPP) 1.1 from the IETF. With the attributes, client and server applications can discover and select printers that have the capabilities specified by the attributes. In addition to the included StreamPrintService, which allows applications to transcode data to different formats, a third party can dynamically install their own print services through the Service Provider Interface Congratulations to Bob Herriot for working with the Java team to come up with this specification that builds on IPP and gets IPP semantics into yet another standard. Tom From carl at manros.com Wed Jul 3 06:40:28 2002 From: carl at manros.com (Carl) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] RE: IPP> Java 1.4 has Print Service API based on IPP In-Reply-To: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90806F6BE@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <003b01c22297$314f93a0$6501a8c0@UnknownUser> Great work Bob, We are gradually getting there. It looks like IPP is becoming the de facto printing standard out in the market although it takes time. Carl-Uno Carl-Uno Manros 10701 S Eastern Ave #1117 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-310-251-7103 Email carl@manros.com > -----Original Message----- > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Hastings, > Tom N > Sent: Tuesday, July 02, 2002 6:21 PM > To: ipp; printing-spool@freestandards.org > Cc: Herriot, Bob > Subject: IPP> Java 1.4 has Print Service API based on IPP > > > Java 1.4 available from Sun in March 2002 has a Print Service API based on > IPP/1.1. See: > > http://java.about.com/library/weekly/aa052002a.htm > > The [print-spool] free standards WG should take a look at this for > consideration of the Print API (PAPI). > > Here is some more information on the Java 1.4 Print Service API: > > Print Service API > The new Print Service API enables Java applications to: > * discover and select print services based on their capabilities; > * specify the format of print data; > * submit print jobs to services that support the document type to be > printed. > For more information, see Java Print Service > ide/jps/in > dex.html>. > > Here is the initial paragraph from the above URL: > > The JavaTM Print Service is a new Java Print API that allows > printing on all > Java platforms, including platforms requiring a small footprint, such as a > J2ME profile, but still supports the current Java 2 Print API. Thie Java > Print Service API includes an extensible print attribute set based on the > standard attributes specified in the Internet Printing Protocol (IPP) 1.1 > from the IETF. With the attributes, client and server applications can > discover and select printers that have the capabilities specified by the > attributes. In addition to the included StreamPrintService, which allows > applications to transcode data to different formats, a third party can > dynamically install their own print services through the Service Provider > Interface > > Congratulations to Bob Herriot for working with the Java team to come up > with this specification that builds on IPP and gets IPP semantics into yet > another standard. > > Tom > > > > > From hlava at us.ibm.com Mon Jul 22 11:19:21 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.4.pdf you can find a new version of the Open Standard Print API (PAPI). This version (V0.4) contains some miscellaneous small changes but the major change is to make the printer and job types (papi_printer_t and papi_job_t) opaque handles instead of defined structures. See the Change History section for more details. (I also sent the PDF file out to printing-spool as an attachment, but that mail appears to be blocked due to the size.) Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020722/c608fb29/attachment.htm From hlava at us.ibm.com Mon Jul 22 11:11:00 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: papi_v0.4.pdf Type: application/octet-stream Size: 321019 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020722/36ae4c6f/papi_v0.4.obj From papowell at astart.com Tue Jul 23 10:12:23 2002 From: papowell at astart.com (Patrick Powell) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 In-Reply-To: Message-ID: <200207231712.g6NHCNU70206@h110.private> > From printing-spool-admin@freestandards.org Mon Jul 22 11:39:16 2002 > To: printing-spool@freestandards.org > From: "Alan Hlava" > Subject: [printing-spool] PAPI V0.4 > Date: Mon, 22 Jul 2002 12:11:00 -0600 > > > Attached is a new version of the Open Standard Print API (PAPI). This > version (V0.4) contains some miscellaneous small changes but the major > change is to make the printer and job types (papi_printer_t and > papi_job_t) opaque handles instead of defined structures. See the Change > History section for more details. > > Regards, > > Alan Hlava > IBM Printing Systems Division > hlava@us.ibm.com > > Comments on the section on Authentication: I suspect that you might want to make this a bit more generic so that you can support other models than the IPP/HTTP authentication. I think that a bit more vagueness is appropriate: --------- Authentication will be done by using methods appropriate to the underlying server/printer being used. For example, if the underlying printer/server is using IPP protocol then either HTTP Basic or or HTTP Digest authentication by be used. Authentication is supported by supplying a user name and password. If the user name and password are not passed on the API call, the call may fail an error code indicating an authentication problem. ---------- Patrick Powell Astart Technologies papowell@astart.com 6741 Convoy Court Network and System San Diego, CA 92111 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.lprng.com) From hlava at us.ibm.com Thu Jul 25 12:00:09 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: On Tuesday, 07/23/2002 at 10:12 MST, Patrick Powell wrote: ... > I suspect that you might want to make this a bit more generic > so that you can support other models than the IPP/HTTP authentication. > I think that a bit more vagueness is appropriate: Thanks for the suggestion. This will be incorporated into the next version. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020725/3d6a3cce/attachment.htm From imcdonald at sharplabs.com Sun Aug 4 11:29:47 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] RE: RESEND: PAPI Chapter 9 ISSUE: Reference to a document which l ists all attributes Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD24@mailsrvnt02.enet.sharplabs.com> Hi folks, I posted Tom's Acrobat (PDF) file to the requested URL: ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.pdf After six tries, I still can't FTP transfer the (large) MS Word source file to the PWG server without the PWG server dropping the connection before it completes. No matter - the PDF file should be used for comments anyway. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Saturday, August 03, 2002 8:33 PM To: printing-spool@freestandards.org; printing-cap@freestandards.org Cc: Zehler, Peter; McDonald, Ira at Sharp Subject: RESEND: PAPI Chapter 9 ISSUE: Reference to a document which lists all attributes I misspelled the spool and cap DLs. Sorry for the resend. Tom -----Original Message----- From: Hastings, Tom N Sent: Saturday, August 03, 2002 16:53 To: 'spool@freestandards.org' Cc: printing-jobticket@freestandards.org; 'cap@freestandards.org'; 'ipp@pwg.org'; Zehler, Peter Subject: PAPI Chapter 9 ISSUE: Reference to a document which lists all attributes Alan, Chapter 9 of the FSG Print API (PAPI) spec, version V0.4 (ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi_v0.4.pdf) has the following: Chapter 9. Attributes * ISSUE: Waiting for reference to single document from Tom H. I assume that this PAPI reference should be to a short document that lists all attributes and points to the specifications where they are described in detail, right? ISSUE: We need to discuss whether this short document should be to the PWG Semantic Model or to a more IPP specific document which contains references to all of the IPP attributes with the same IPP spellings and attribute syntaxes. I'm also copying this mail note to the FSG jobticket mailing list, since the job ticket API should provide mappings to the appropriate Job and Document attributes in the attached document. I'm also copying this mail note to the FSG cap (capabilities) mailing list, since the Capabilities API should provide mappings to the appropriate Printer attributes in the attached document. To see a draft of the PWG Semantic Model see: See ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Mode-06-020617.pdf ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Mode-06-020617.doc or later If the short document that the PAPI reference in Chapter 9 should be more IPP-specific, I've attached such a document. It only lists IPP WG approved IPP attributes, plus a few additions for a Document object proposal being worked on as part of the PWG Semantic Model and as an extension to IPP. The Document object proposal mostly re-uses job level attributes at the document level. Peter Zehler is incorporating all these attributes into the PWG Semantic Model and schema. Please send any comments to the mailing list. I'm in the process of registering with IANA those attributes in this document that have been published in RFCs. Unfortunately, I was unable to down load this file to the PWG FTP server: ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.pdf ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.doc so I've attached them as a single .zip file. I hope that it makes it through the freestandards mail system, since there is some limits to the size of attachments. Could somebody down load them to the above URLs this week? I'm leaving on vacation tomorrow (Sunday) and will return Thursday, August 15. Peter, If you want them in the PWG Semantic_model directory, please down load them there too. Thanks, Tom From hastings at cp10.es.xerox.com Sat Aug 3 17:33:10 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] RESEND: PAPI Chapter 9 ISSUE: Reference to a document which lists all attributes Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90806FE0B@x-crt-es-ms1.cp10.es.xerox.com> I misspelled the spool and cap DLs. Sorry for the resend. Tom -----Original Message----- From: Hastings, Tom N Sent: Saturday, August 03, 2002 16:53 To: 'spool@freestandards.org' Cc: printing-jobticket@freestandards.org; 'cap@freestandards.org'; 'ipp@pwg.org'; Zehler, Peter Subject: PAPI Chapter 9 ISSUE: Reference to a document which lists all attributes Alan, Chapter 9 of the FSG Print API (PAPI) spec, version V0.4 (ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi_v0.4.pdf) has the following: Chapter 9. Attributes * ISSUE: Waiting for reference to single document from Tom H. I assume that this PAPI reference should be to a short document that lists all attributes and points to the specifications where they are described in detail, right? ISSUE: We need to discuss whether this short document should be to the PWG Semantic Model or to a more IPP specific document which contains references to all of the IPP attributes with the same IPP spellings and attribute syntaxes. I'm also copying this mail note to the FSG jobticket mailing list, since the job ticket API should provide mappings to the appropriate Job and Document attributes in the attached document. I'm also copying this mail note to the FSG cap (capabilities) mailing list, since the Capabilities API should provide mappings to the appropriate Printer attributes in the attached document. To see a draft of the PWG Semantic Model see: See ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Mode-06-020617.pdf ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Mode-06-020617.doc or later If the short document that the PAPI reference in Chapter 9 should be more IPP-specific, I've attached such a document. It only lists IPP WG approved IPP attributes, plus a few additions for a Document object proposal being worked on as part of the PWG Semantic Model and as an extension to IPP. The Document object proposal mostly re-uses job level attributes at the document level. Peter Zehler is incorporating all these attributes into the PWG Semantic Model and schema. Please send any comments to the mailing list. I'm in the process of registering with IANA those attributes in this document that have been published in RFCs. Unfortunately, I was unable to down load this file to the PWG FTP server: ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.pdf ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.doc so I've attached them as a single .zip file. I hope that it makes it through the freestandards mail system, since there is some limits to the size of attachments. Could somebody down load them to the above URLs this week? I'm leaving on vacation tomorrow (Sunday) and will return Thursday, August 15. Peter, If you want them in the PWG Semantic_model directory, please down load them there too. Thanks, Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: IPP-Object-Attributes.zip Type: application/octet-stream Size: 257615 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020803/87c32b75/IPP-Object-Attributes.obj From pzaan at us.ibm.com Thu Aug 8 13:04:31 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: While looking at the papi specification, I did not see anything that was equivalent or similar to an openPrinter call. I don't know if it actually existed in the ipp spec. because the attrs. were set for the job. I think that we might want to add it to the API specification since there might be a different implementation than what we currently are working with that would have to load up driver/render support and have requests filled based on a handle that was passed back from an openPrinter, especially for capabilities access. With dynamic driver support and supporting higher end features, we would likely have to create device "contexts" and destroy contexts so it would be nice to have a handle to that context to work with. A little bit more explicit than with the papiPrinterQuery call. A query doesn't sound like I might have created and/or need to delete something. I view queries as something to be done with an object that has been created. Thoughts? Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com Alan Hlava/Boulder/IBM@IBMUS@freestandards.org on 07/22/2002 01:11:00 PM Please respond to printing-spool@freestandards.org Sent by: printing-spool-admin@freestandards.org To: printing-spool@freestandards.org cc: Subject: [printing-spool] PAPI V0.4 Attached is a new version of the Open Standard Print API (PAPI). ?This version (V0.4) contains some miscellaneous small changes but the major change is to make the printer and job types (papi_printer_t and papi_job_t) opaque handles instead of defined structures. ?See the Change History section for more details. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From mike at easysw.com Thu Aug 8 17:14:21 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 References: Message-ID: <3D53095D.6080404@easysw.com> Pete Zannucci wrote: > While looking at the papi specification, I did not see anything that > was equivalent or similar to an openPrinter call. > ... The service/server connection is the closest equivalent; basically, all accesses are done through the papi_service_t object, which allows you to access printer and job resources on the server, but there is no notion of persistent access to them. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From steve_folker at hotmail.com Tue Aug 13 06:18:11 2002 From: steve_folker at hotmail.com (Steve Folker) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Do not read this if you do not own a satellite ! Message-ID: <200208131318.g7DDIBG28475@web1.securehost.com> If you own a satellite, please visit http://www.dssdimensions.com If you do not own a satellite, please visit http://www.dssdimensions.com webmaster@dssdimensions.com online all the time ------------------------------------------------------------------------- To be removed from this mailing list click on the link below http://www.dssmobster.com/cgi-bin/mail.cgi?printing-spool@freestandards.org From pzaan at us.ibm.com Tue Aug 13 08:04:15 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: >> While looking at the papi specification, I did not see anything that >> was equivalent or similar to an openPrinter call. > The service/server connection is the closest equivalent; basically, > all accesses are done through the papi_service_t object, which > allows you to access printer and job resources on the server, but > there is no notion of persistent access to them. Since there are some things that are not defined statically when a printer has been queried, how can we handle more advanced features, such as queries against a device specific representation for something like bits per pel support based on the specific device configuration? This is the type of thing a full rendering/driver implementation has been doing for a long time. Is there no way to implement this without the thought of having to construct something on the backend support each time we want to do a query? I can see more benefits to having an implementation of an open and a close then not having the feature especially if there is the thought of supporting a infrastructure with a more robust set of query and drawing calls. Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From hlava at us.ibm.com Tue Aug 13 08:29:53 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: OK, here is a proposal.... (1) Add new papiPrinterOpen() and papiPrinterClose() functions: papi_status_t papiPrinterOpen( papi_service_t handle, const char* name, papi_printer_t* printer); papi_status_t papiPrinterClose( papi_printer_t printer); (2) Add a note to papiPrinterQuery() that the printer handle is also an optional input argument. If it's set on input to a valid handle returned from papiPrinterOpen(), then the implementation *may* use information associated with the handle to make the query operation more efficient and/or complete. We should also note that the implementation is free to *not* support such printer session information by making the open/close functions no-ops and ignoring the input printer handle on papiPrinterQuery (this allows applications to use the functions on any implementation but preserves the possibility of supporting PAPI on top of simpler print systems). Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020813/d36e581b/attachment.htm From mike at easysw.com Tue Aug 13 09:06:27 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 References: Message-ID: <3D592E83.6060809@easysw.com> Pete Zannucci wrote: > ... > Since there are some things that are not defined statically when > a printer has been queried, how can we handle more advanced features, > such as queries against a device specific representation for something > like bits per pel support based on the specific device configuration? > This is the type of thing a full rendering/driver implementation has > been doing for a long time. Is there no way to implement this without > the thought of having to construct something on the backend support > each time we want to do a query? First, applications should not be working at this level, period. Applications should send a printer-independent document format (PostScript is king now, but PDF and other meta-formats could replace it) so that the *driver* and *printing system* can worry about how to best print the document. Printer drivers in applications do no scale (performance, resource usage, etc.) and produce inconsistent results, which is why the leading desktop OS's (Windows and MacOS) don't do it that way. (Should it be possible for an app to roll its own printer drivers? Sure, but PAPI doesn't need to support it!) PAPI is for applications. If you want a low-level device driver interface, then you MUST define a SEPARATE interface; the two interfaces should be able to share/use the same printer information (which is a function of the printing system), but you will probably find that applications and printer drivers have very different needs. That is one of many reasons why CUPS separates the API and imaging libraries. Forcing device independence in the application also means that you can print to any printer, use a common driver/filter interface, and interchange modules at whim to support any printing requirements that come in the future without redesigning everything. One good example is that while we recommend using the CUPS raster printer interface for printer drivers, it isn't the only way to support a non-PS printer - the foomatic and IJS wrappers around Ghostscript are good examples of alternative interfaces that work seemlessly within CUPS, and the application has no need or requirement to realize that this has happened. > I can see more benefits to having an implementation of an open and > a close then not having the feature especially if there is the thought > of supporting a infrastructure with a more robust set of query and > drawing calls. Adding printer open and close calls to an interface that is inherently based on communications with a server (whether that "server" handles multiple printers or not) isn't going to provide anything other than overhead. It might be useful to provide functions to enumerate the available servers/services which the application can choose from, however I really don't think we want explicit per-printer connections for the purpose of communicating with the printer driver, since that boxes us into a single printing system/printer driver architecture. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Aug 13 09:15:51 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 References: Message-ID: <3D5930B7.8020709@easysw.com> Alan Hlava wrote: > > OK, here is a proposal.... > > (1) Add new papiPrinterOpen() and papiPrinterClose() functions: > papi_status_t papiPrinterOpen( > papi_service_t handle, > const char* name, > papi_printer_t* printer); > papi_status_t papiPrinterClose( > papi_printer_t printer); > > (2) Add a note to papiPrinterQuery() that the printer handle is also > an optional input argument. If it's set on input to a valid handle > returned from papiPrinterOpen(), then the implementation *may* > use information associated with the handle to make the query > operation more efficient and/or complete. We should also note > that the implementation is free to *not* support such printer session > information by making the open/close functions no-ops and > ignoring the input printer handle on papiPrinterQuery (this allows > applications to use the functions on any implementation but preserves > the possibility of supporting PAPI on top of simpler print systems). > > Comments? I'm not sure what information could be cached, short of the URI for the printer object in an IPP implementation, but that information is probably already available, so we're just adding an unnecessary layer of "fluff" to the interface. Sure, we can no-op it in our PAPI implementations, but given that any implementation that needs to cache information will likely already be caching it "globally" for the service handle, how does a printer handle provide any better functionality? A few usec speedup for queries that might require a round-trip communication with the printer anyways? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From pzaan at us.ibm.com Thu Aug 15 09:07:05 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI V0.4 Message-ID: WARNING -- LONG Michael Sweet wrote: >> Since there are some things that are not defined statically when >> a printer has been queried, how can we handle more advanced features, >> such as queries against a device specific representation for something >> like bits per pel support based on the specific device configuration? >> This is the type of thing a full rendering/driver implementation has >> been doing for a long time. Is there no way to implement this without >> the thought of having to construct something on the backend support >> each time we want to do a query? > First, applications should not be working at this level, period. > Applications should send a printer-independent document format... You are absolutely right with what you said. I was not referring to working at a low level though. We can look at printer-independent document format as one of two things: 1. Page gets generated without knowledge of the output device specific information and the backend generates the phyical page. 2. A meta-format that can be generated that has intimate knowledge of the device so that when you print using 12 pt. fonts that the application knows precisely the location and size of the font placement on the page. This is also device independent but can use exacting information about the device to insure proper positioning on the page. Currently a .ppd can't correlate certain option groups to give me an intimate view of the device based on that option group so I can know what I will have come out on the page (Item 2). I think we need a different way to solve item 2. > (Should it be possible for an app to roll its own printer drivers? > Sure, but PAPI doesn't need to support it!) I am not looking for a way for applications to create their own printer drivers. I am looking for an open interface to implement device capabilities without limiting the capabilities to be only attributes that are typical of what a static file has in it. There are other correlations between groups of attributes that need to be applied to come up with the full correct capabilities grouping of information. > PAPI is for applications. If you want a low-level device driver > interface..... Correct, PAPI is for applications. Problem is that we haven't exposed everything we need to so that we can have a full blown capabilities implementation. That was part of the reason for the opaque container that was proposed by IPP. If things change based on a set of attributes selected by the application, the application should know how that affects things such as printable area and/or attributes it can use for color output. For instance the application might want to do something differently if it can't print color with the attribute selections that are chosen, say for a bar graph. Many shades of gray would cause the bars of the graph to blend with each other. If the application knew about the limitations due to the particular attributes grouping on the printer (queue) then they might replace the color (mapped to gray) with diagonal lines or a pattern when they draw the bars on a chart. > Forcing device independence in the application also means that > you can print to any printer.... You can only enforce so much independence. There are things that will not correlate between groupings of printers or if I want WYSIWYG printing. Yes the attrs for the job should be separate from the job itself. The attrs. of the job, call it Job Properties, should be applied at the end (I think some people call this late binding) so that the job can have printer specific data generated by the renderer/driver specific to its attributes and device features. I would also like to have a meta type format such as an Goca metafile or EMF from Windows but we have to put those parts in place so that applica- tions can utilize them as we build more function underneath the apis. It would be nice to run my high speed printer at rated speed which would mean we have to do a lot more to the backend than we currently have for non-postscript devices. >> I can see more benefits to having an implementation of an open and >> a close then not having the feature especially if there is the thought >> of supporting a infrastructure with a more robust set of query and >> drawing calls. > Adding printer open and close calls to an interface that is > inherently based on communications with a server (whether that > "server" handles multiple printers or not) isn't going to provide > anything other than overhead. We would have a lot less overhead if we were able to keep instance information around about the target's attributes or at least have a high speed mechanism to get the information when/if needed. We don't necessarily have to be talking to a printer driver (though that could be one implementation) but we could be talking to a queue backend that can give us a better picture than just a static snapshot we get when we as for the top level attributes since the attributes have to be correlated. > however I really don't think we > want explicit per-printer connections for the purpose of > communicating with the printer driver, since that boxes us into > a single printing system/printer driver architecture. If we can come up with a way and interface that we can get appropriate values based on a "grouping of attributes", that is really what we want for the end-game. We would need this information available and maybe not a continued explicit connection though we need insurance that what we are doing when drawing the page is valid based on the configuration selected by the user. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From mike at easysw.com Thu Aug 15 10:04:07 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 References: Message-ID: <3D5BDF07.2080508@easysw.com> Pete Zannucci wrote: > ... > 1. Page gets generated without knowledge of the output device > specific information and the backend generates the phyical > page. > 2. A meta-format that can be generated that has intimate knowledge > of the device so that when you print using 12 pt. fonts that > the application knows precisely the location and size of the > font placement on the page. This is also device independent > but can use exacting information about the device to insure > proper positioning on the page. > > Currently a .ppd can't correlate certain option groups to give me an > intimate view of the device based on that option group so I can know > what I will have come out on the page (Item 2). I think we need a > different way to solve item 2. For #2, you are really talking about font management, which is one problem that can be hard to solve (the other is color management). While it is true that an application needs to know the metrics for the fonts a printer supports, these days it is less relavent since: 1. Most printers do not come with a complete enough set of fonts to allow an application to use them (think: Unicode, Euro symbol, etc.) 2. Most of the current desktop toolkits embed their own fonts when printing, because of #1 and because they can depend on specific font metrics when printing or displaying. 3. Printers these days are increasingly falling into one of three categories: dumb raster (most inkjets), raster + some text caps (some inkjets and most lasers), and vector (PS and PCL 6/PCL XL, which are supported by most lasers) 4. Modern metafile formats do not rely on resident fonts; the only real exception I know of are the base 17 fonts in PDF, which have well defined metrics and fonts (but again, few people still use them because they aren't complete...) > ... > I am not looking for a way for applications to create their own > printer drivers. I am looking for an open interface to implement device > capabilities without limiting the capabilities to be only attributes > that are typical of what a static file has in it. There are other > correlations between groups of attributes that need to be applied > to come up with the full correct capabilities grouping of information. Can you list some specific attributes that you see changing based on options that couldn't be handled using the PPD conflict mechanism? Margins are one I know of, but I'd be interested to hear of any other example that wouldn't work... The margin issue can be addressed fairly easily with some simple additions to a PPD file, although I understand that *generating* the PPD file may be difficult if you have all the capability info embedded in code. > ... > Problem is that we haven't exposed everything we need to so that we can > have a full blown capabilities implementation. That was part of the > reason for the opaque container that was proposed by IPP. If things > change based on a set of attributes selected by the application, the > application should know how that affects things such as printable area > and/or attributes it can use for color output. For instance the > application might want to do something differently if it can't print > color with the attribute selections that are chosen, say for a bar graph. > Many shades of gray would cause the bars of the graph to blend with > each other. If the application knew about the limitations due to the > particular attributes grouping on the printer (queue) then they might > replace the color (mapped to gray) with diagonal lines or a pattern > when they draw the bars on a chart. Certainly we may need to add additional informational attributes to the PPD file that an app could look at, however none of that can't be done in a static file. One of the problems with exposing printer capabilities is that it is hard to define what they are - do you try to cover everything, or are you interested in just enumerating the allowed combinations and the basic capabilities/attributes? The IPP media-col-supported attribute tries to do this for media selections, however it requires you to list *every* possible combination, which can be a lot of values and is not a convenient way for the user to choose options... >>Forcing device independence in the application also means that >>you can print to any printer.... > > > You can only enforce so much independence. There are things that will > not correlate between groupings of printers or if I want WYSIWYG printing. Specific media attributes (size, color, type, etc.) might not be honored, but the appearance of the prints would be as similar as possible for the devices; let the user choose to print hatch- filled bars instead of colored or shaded bars! > ... > We would have a lot less overhead if we were able to keep instance > information around about the target's attributes or at least have > a high speed mechanism to get the information when/if needed. That is already in the PAPI spec, using the query-printer call. We can provide *any* attribute info we need this way... > ... > can give us a better picture than just a static snapshot we get when > we as for the top level attributes since the attributes have to be > correlated. Why do you assume that you'll get the same values for every query-printer call? Nothing in the spec (PAPI, IPP, etc.) says that you'll always see the same values! > ... > If we can come up with a way and interface that we can get appropriate > values based on a "grouping of attributes", that is really what we want > for the end-game. We would need this information available and maybe > not a continued explicit connection though we need insurance that what > we are doing when drawing the page is valid based on the configuration > selected by the user. It sounds more like you want to be able to provide additional job template attributes when querying a printer, so that you'll get the attributes the correspond to the type of job you are printing. This is supported at a basic level by IPP already. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From pzaan at us.ibm.com Thu Aug 15 15:39:29 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 Message-ID: Sorry, another long one. >> Currently a .ppd can't correlate certain option groups to give me an >> intimate view of the device based on that option group so I can know >> what I will have come out on the page (Item 2). I think we need a >> different way to solve item 2. > For #2, you are really talking about font management, which is one > problem that can be hard to solve (the other is color management). We would be a lot closer to solving layout if we had all the pertinent information about the association between the attributes and was able to provide that back to the application for drawing. > While it is true that an application needs to know the metrics for > the fonts a printer supports, these days it is less relevant since: > > 1. Most printers do not come with a complete enough set of > fonts to allow an application to use them (think: Unicode, > Euro symbol, etc.) > 2. Most of the current desktop toolkits embed their own fonts > when printing, because of #1 and because they can depend on > specific font metrics when printing or displaying. So you are saying that we should go to the lowest common denominator and rasterize when printing and don't provide accelerated support by using device fonts? I believe that a number of printers, such as the Japanese printers, have what they would need for font support that could be exploited. > Modern metafile formats do not rely on resident fonts; > the only real exception I know of are the base 17 fonts > in PDF, which have well defined metrics and fonts > (but again, few people still use them because they aren't > complete...) The typical metafile contains a reference to the font along with its character box, increment and such, and it is up to the implementation when playing back the metafile to let the appropriate owner handle the font, be it the printer driver or the system rasterizer. I thought that we could get straight text and font information out of Ghostscript to start with? > Can you list some specific attributes that you see changing based > on options that couldn't be handled using the PPD conflict > mechanism? > > Margins are one I know of, but I'd be interested to hear of any > other example that wouldn't work... The margin issue can be > addressed fairly easily with some simple additions to a PPD file, > although I understand that *generating* the PPD file may be > difficult if you have all the capability info embedded in code. > > Certainly we may need to add additional informational attributes > to the PPD file that an app could look at, however none of that > can't be done in a static file. Printable area and margins are the major ones that need to have correlation done if we are not worried about fonts as much. Most of the additions can be done statically but if we have a large number of options, that task would be error-prone at best. BTW...We also didn't go down the path of being able to provide an adequate representation of a printer and its features. This would be beneficial so that we can determine what are the correct attrs. that can be used based on the printers configuration. > One of the problems with exposing printer capabilities is that > it is hard to define what they are - do you try to cover > everything, or are you interested in just enumerating the > allowed combinations and the basic capabilities/attributes? We did get some buyin from the UPDF folks for implementation of key properties such as a devmode structure and being able to utilize it more as a group then singular attributes. If it is an extensible object, we could add more attributes later. >> We would have a lot less overhead if we were able to keep instance >> information around about the target's attributes or at least have >> a high speed mechanism to get the information when/if needed. > That is already in the PAPI spec, using the query-printer call. > We can provide *any* attribute info we need this way... One of the major problems is that we don't pass back margin or printable area based on the configuration. That can't be done until we select the configuration currently then we have to have a way to find out how the attributes fit together. > Why do you assume that you'll get the same values for every > query-printer call? Nothing in the spec (PAPI, IPP, etc.) > says that you'll always see the same values! This is one of the things that I would like to avoid. If we have the concept of a device context or presentation space that is specific to a particular set of attributes, the query should always give me the same results. I'm not sure how do-able that is in CUPS currently though. I am just trying to think of different ways to get data in and out through a defined interface not worrying about what the particular implementation would be because it could be static or it could be dynamic and it should use the same API. >> If we can come up with a way and interface that we can get appropriate >> values based on a "grouping of attributes", that is really what we want >> for the end-game. We would need this information available and maybe >> not a continued explicit connection though we need insurance that what >> we are doing when drawing the page is valid based on the configuration >> selected by the user. > It sounds more like you want to be able to provide additional > job template attributes when querying a printer, so that you'll > get the attributes the correspond to the type of job you are > printing. This is supported at a basic level by IPP already. Unfortunately not all the info I need. We would have to extend IPP for a couple of items. Shawn from HP today also brought up some issues that will need to be resolved in an IPP based implementation. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From mike at easysw.com Fri Aug 16 03:50:38 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 References: Message-ID: <3D5CD8FE.8040501@easysw.com> Pete Zannucci wrote: > ... > So you are saying that we should go to the lowest common denominator > and rasterize when printing and don't provide accelerated support > by using device fonts? No, I'm saying that with the exception of high-level printers, trying to support device fonts (or downloaded fonts) is not a worthwhile goal, since simpler devices either 1) don't support text printing at all, or 2) don't offer sufficient text support to be useful beyond printing plain text. > I believe that a number of printers, such as the Japanese printers, > have what they would need for font support that could be exploited. Certainly you may be able to utilize CID fonts on Japanese models, however there is still the issue of screen-matching (in the application) and character coverage (which will vary from model to model). Can we provide font management/query support? Sure. Will it get used? Probably not, since it is easier to write an application that embeds a known font than to write a lot of code to inspect each on-board font to see if it contains all of the required characters. > ... > The typical metafile contains a reference to the font along with > its character box, increment and such, and it is up to the > implementation when playing back the metafile to let the > appropriate owner handle the font, be it the printer driver or > the system rasterizer. I thought that we could get straight > text and font information out of Ghostscript to start with? Windows metafiles do this, but it also requires that you have the *same* fonts on both the generating and playback systems. PDF supports this, but Adobe recommends that you embed your fonts since the viewer may not have the same fonts you do. Keep in mind that the "typical" printing environment will not be local app, local printer, but local app, network printer. Just because a font is available locally doesn't mean that the server has it, and visa-versa. > ... > Printable area and margins are the major ones that need to have > correlation done if we are not worried about fonts as much. > > Most of the additions can be done statically but if we have a > large number of options, that task would be error-prone at best. That's why you automate it... > BTW...We also didn't go down the path of being able to provide an > adequate representation of a printer and its features. This would > be beneficial so that we can determine what are the correct attrs. > that can be used based on the printers configuration. What is missing from the current PPD format? Installable options along with associated constraints handle anything we've run into. > ... >>That is already in the PAPI spec, using the query-printer call. >>We can provide *any* attribute info we need this way... > > > One of the major problems is that we don't pass back margin or printable > area based on the configuration. That can't be done until we select the > configuration currently then we have to have a way to find out how the > attributes fit together. But that doesn't mean we *couldn't* do that, and there is already some support in IPP for returning different values based on document format and so forth. >>Why do you assume that you'll get the same values for every >>query-printer call? Nothing in the spec (PAPI, IPP, etc.) >>says that you'll always see the same values! > > > This is one of the things that I would like to avoid. If we have > the concept of a device context or presentation space that is > specific to a particular set of attributes, the query should always > give me the same results. I'm not sure how do-able that is in Right, but for different attributes you might get different results. Also, a change in device configuration (whether by the user or by the system/printer) can also affect the available options, etc. (different ink cartridges, etc.) > CUPS currently though. I am just trying to think of different ways > to get data in and out through a defined interface not worrying > about what the particular implementation would be because it could > be static or it could be dynamic and it should use the same API. Don't worry so much about how it would map with CUPS; as long as the interface does not depend on direct communications with the printer or driver, then CUPS will be able to support it. > ... >>It sounds more like you want to be able to provide additional >>job template attributes when querying a printer, so that you'll >>get the attributes the correspond to the type of job you are >>printing. This is supported at a basic level by IPP already. > > > Unfortunately not all the info I need. We would have to extend IPP > for a couple of items. Shawn from HP today also brought up some > issues that will need to be resolved in an IPP based implementation. Thankfully, extending IPP is not a problem, and the PWG could certainly publish an extension spec that could be used by all... (and, FWIW, I'd be happy to author the spec based on what we work out here...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From pzaan at us.ibm.com Fri Aug 16 14:49:35 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 Message-ID: Sorry about going to two lists. Since the interfaces are driven through the same mechanism that the spooler uses, I think it ties together a lot of the api work between the groups. Michael Sweet wrote: > No, I'm saying that with the exception of high-level printers, > trying to support device fonts (or downloaded fonts) is not a > worthwhile goal, since simpler devices either 1) don't support > text printing at all, or 2) don't offer sufficient text support > to be useful beyond printing plain text. > Can we provide font management/query support? Sure. Will it > get used? Probably not, since it is easier to write an application > that embeds a known font than to write a lot of code to inspect > each on-board font to see if it contains all of the required > characters. You are stating that an application would rather embed a known font so basically you think that most applications will stick with particular groups of fonts that they know the metrics for than to go and get the specific information on metrics for a queried font? Or was this so that a rasterizer, such as Ghostscript, would be able the generate the font correctly? So by embed you are referring to actually putting the font information in the postscript file similar to downloaded postscript font. I think we need to see from other folks if there is any thinking that font or high level drawing support is needed. That will definitely direct the investment. >> BTW...We also didn't go down the path of being able to provide an >> adequate representation of a printer and its features. This would >> be beneficial so that we can determine what are the correct attrs. >> that can be used based on the printers configuration. > What is missing from the current PPD format? Installable options > along with associated constraints handle anything we've run into. How do we store the current device configuration so that we know the valid options that the printer has installed? >> One of the major problems is that we don't pass back margin or printable >> area based on the configuration. That can't be done until we select the >> configuration currently then we have to have a way to find out how the >> attributes fit together. > But that doesn't mean we *couldn't* do that, and there is already > some support in IPP for returning different values based on > document format and so forth. So we could end up doing a query based on a correlated grouping of attributes? If this is to be handled via a ppd wouldn't it be quite a convoluted grouping of information to store in the ppd? >> This is one of the things that I would like to avoid. If we have >> the concept of a device context or presentation space that is >> specific to a particular set of attributes, the query should always >> give me the same results. I'm not sure how do-able that is in > Right, but for different attributes you might get different > results. Also, a change in device configuration (whether by > the user or by the system/printer) can also affect the available > options, etc. (different ink cartridges, etc.) If you change something like the form in the middle of the job, I would hope you would get different results. The device configuration is something that no one will solve except through education or smart bidi enabled devices that can save configurations on the system. It still will not be solved but less likely to occur. >> CUPS currently though. I am just trying to think of different ways >> to get data in and out through a defined interface not worrying >> about what the particular implementation would be because it could >> be static or it could be dynamic and it should use the same API. > Don't worry so much about how it would map with CUPS; as long as > the interface does not depend on direct communications with the > printer or driver, then CUPS will be able to support it. CUPS could support dynamic printer drivers or a mechanism that plays host for the printer(s) configuration. Instead of going to a ppd, use the same interface to get you attributes or opaque object from somewhere else. > Thankfully, extending IPP is not a problem, and the PWG could > certainly publish an extension spec that could be used by all... > (and, FWIW, I'd be happy to author the spec based on what we > work out here...) We have been discussing a bunch of things and I would like to get a better feel about what others ideas are. We will have to definitely get a spec together describing function. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From imcdonald at sharplabs.com Fri Aug 16 15:13:16 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD4C@mailsrvnt02.enet.sharplabs.com> Hi Pete, Could you please enumerate what you think needs to be added to IPP? Dumb question - have you looked at the IPP extensions currently published in PWG 510x standards and IETF RFCs and I-Ds? I agree with you Pete - in-band support for dynamic discovery of exact CURRENT capabilities of a specific target printer device (or a target printer gateway that may do transforms) is highly desirable. [But then I co-wrote the SLP and LDAP Printer schemas, so I'm biased.] Cheers, - Ira McDonald High North Inc -----Original Message----- From: Pete Zannucci [mailto:pzaan@us.ibm.com] Sent: Thursday, August 15, 2002 6:39 PM To: printing-spool@freestandards.org; printing-cap@freestandards.org Subject: Re: [printing-cap] Re: [printing-spool] PAPI V0.4 >> If we can come up with a way and interface that we can get appropriate >> values based on a "grouping of attributes", that is really what we want >> for the end-game. We would need this information available and maybe >> not a continued explicit connection though we need insurance that what >> we are doing when drawing the page is valid based on the configuration >> selected by the user. > It sounds more like you want to be able to provide additional > job template attributes when querying a printer, so that you'll > get the attributes the correspond to the type of job you are > printing. This is supported at a basic level by IPP already. Unfortunately not all the info I need. We would have to extend IPP for a couple of items. Shawn from HP today also brought up some issues that will need to be resolved in an IPP based implementation. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com _______________________________________________ printing-cap mailing list printing-cap@freestandards.org http://freestandards.org/mailman/listinfo/printing-cap From mike at easysw.com Sat Aug 17 14:04:49 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 References: Message-ID: <3D5EBA71.50204@easysw.com> Pete Zannucci wrote: > ... > You are stating that an application would rather embed a known > font so basically you think that most applications will stick > with particular groups of fonts that they know the metrics for > than to go and get the specific information on metrics > for a queried font? It's not just metrics, it is the available characters. Metrics are actually pretty easy to deal, especially since the AFM files for Adobe fonts are readily available on most UNIX/Linux platforms. Most fonts shipped with printers only contain the "Standard" Adobe character set, which is sufficient for ISO-8859-1 but not for much of anything else. In particular, most printers do not have fonts with the Euro character in them, so an app must either 1) use a separate Euro font (which only contains the Euro character), 2) add the Euro character to the existing fonts, or 3) embed its own (or a printing-system supplied) fonts with all of the necessary characters. > Or was this so that a rasterizer, such as > Ghostscript, would be able the generate the font correctly? So > ... There can be issues with Ghostscript finding the necessary fonts (especially if the document is being RIP'd on a different system). Ultimately, it is best to think of Ghostscript as "just another PS printer" and not depend on its fonts, either... > ... >>What is missing from the current PPD format? Installable options >>along with associated constraints handle anything we've run into. > > > How do we store the current device configuration so that we know > the valid options that the printer has installed? The InstalledOptions group is usually used for this; look at any laser printer's PPD file for things like duplexer, envelope feeder, extra trays, memory, etc. UIConstraints are used to "block" access to options that are not compatible, i.e. if you don't have a duplexer installed, then selecting a duplex mode is an error. > ... > So we could end up doing a query based on a correlated grouping of > attributes? If this is to be handled via a ppd wouldn't it be > quite a convoluted grouping of information to store in the ppd? Nope, it would be pretty easy; first, the ImageableArea attributes would show the worst-case margins (i.e. margins that would work for all print modes), and then you'd list modifiers for each attribute and size, e.g.: *ImageableArea Letter: "0 0 36 36 576 756" *cupsPageAdjust OutputType/Photo: "0 0 -18 0 +18 0" *cupsPageAdjust InputSlot/RollFeed: "0 0 -18 -36 +18 +36" *cupsPageAdjust MediaType/PhotoPerf: "+36 +72 0 0 +36 +72" In the above example, the normal US letter size media area provides 1/2" margins all around; if Photo output is selected, the left and right margins are reduced to 1/4", rollfeed gets rid of all margins, and PhotoPerf media adds 1/2" to the width and 1" to the length (for perforations on the paper). For the popular HP DeskJet 900 series printers, you could specify that the margins are larger when printing in duplex mode (the HP printers flip the page, so the top and bottom margins are swapped for the back page...) > ... > CUPS could support dynamic printer drivers or a mechanism that > plays host for the printer(s) configuration. Instead of going to > a ppd, use the same interface to get you attributes or opaque object > from somewhere else. True, however currently the only "standard" printer description format is PPD, so at some point you need a PPD file. We've chosen to adopt a "let the printer driver modify the PPD file if/when it needs to" than to do an active poll without caching. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From Norm.Jacobs at Sun.COM Mon Aug 19 11:03:49 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue Message-ID: <3D613305.D4C595F@Sun.COM> Virtually every time that I use papiAttributeFind(), I follow it up with a test for existence, a test for type match, and an assignment from the value(s). It would be much more convenient to simply be able to retreive the value(s) directly. As a result, I am proposing the following addition: extern papi_status_t papiAttributeListGetValue(papi_attribute_t **list, void **iterator, const char *name, papi_attribute_value_type_t type, ...); description retreive an attribute value from an attribute list. When a name is supplied, the named attribute is retreived from the list, the iterator is set, and the first value(s) is(are) used in the results. If no name is supplied, the iterator is used to retreive the next value. If no name and no iterator are supplied, the call fails inputs list - attribute list iterator- an iterator use for retreval of multiple values from a multi-valued attribute. (optional) name - the name of the attribute to get values from. (optional) type - the type of data the attribute is expected to contain ... - type specific arguments: PAPI_STRING, char **string PAPI_INTEGER, int *integer PAPI_BOOLEAN, int boolean PAPI_DATETIME, time_t *dt PAPI_RANGE, int *lower, int *upper PAPI_RESOLUTION, int *x, int *y outputs (return) PAPI_OK for success PAPI_BAD_ARGUMENT - invalid argument(s) PAPI_NOT_FOUND - no such attribute in list PAPI_NOT_POSIBLE - type mismatch (initial call only) PAPI_GONE - values exausted ... type specific values returned in supplied pointers. if (return) is not PAPI_OK, type specific return values may not be set. Ex: papi_status_t status = PAPI_OK; papi_attribute_t **list = NULL; char *tmp = NULL; int lower, upper, copies; void *iter = NULL; : status = papiAttributeListGetValue(list, NULL, "copies", PAPI_INTEGER, &copies); if (status != PAPI_OK) copies = 1; for (status = papiAttributeListGetValue(list, &iter, "foo", PAPI_STRING, &tmp); status == PAPI_OK; status = papiAttributeListGetValue(list, &iter, NULL, PAPI_STRING, &tmp)) printf("value: %s\n", tmp); -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 11:03:53 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions Message-ID: <3D613309.468A2F99@Sun.COM> The more I use the interface, the more I find that some management functionality needs to make it's way in. I have only skimmed the IPP spec that covers this, but the following additions seem to be reasonably consistent with what was proposed for IPP and they seem to make some sense (at least to me). /* Delete the named attribute from the attribute list. */ extern papi_status_t papiAttributeDelete(papi_attribute_t ***attributes, const char *name); /* Modify the job (printer/id) using the supplied attributes, return the status and a resulting job. */ extern papi_status_t papiJobModify(papi_service_t svc, const char *printer, const int32_t id, const papi_attribute_t **attributes, papi_job_t *result); /* Modify a printer using the supplied attributes, return the status and a resulting printer object. */ extern papi_status_t papiPrinterModify(papi_service_t svc, const char *printer, const papi_attribute_t **attributes, papi_printer_t *result); /* Delete a printer, return status */ extern papi_status_t papiPrinterDelete(papi_service_t svc, const char *printer); -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 11:04:19 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: implementation Message-ID: <3D613323.A9B69120@Sun.COM> For those that are interested, I have a template implementation of the PAPI v0.4 draft. The implementation includes: papi.h - header file that incorporates the structures/types/enumerations/functions from the spec, attribute.c - complete implementation of attribute support in spec list.c - list (dynamic array) support for attribute/printer/job lists service.c - template implementation of papi_service_t and supporting functions printer.c - template implementation of papi_printer_t and supporting functions job.c - template implementation of papi_job_t and supporting functions status.c - papiStatusString(); papi_impl.h - example implementation specific header that can be used to build a print service specific implementation. This is code that I have based a Solaris LP prototype implementation of the current draft on. If is reasonably generic and builds on Linux. It is currently licensed under the LGPL and uses autoconf/automake in it's build environment. When v0.5 of the PAPI spec becomes available, I will incorporate the diffs from v0.4 to v0.5 and upload this code to the PWG ftp server for your viewing/implementing pleasure. Hopefully, this will relieve people of some of the pain involved in converting the specification to code. -Norm From mike at easysw.com Mon Aug 19 11:52:29 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue References: <3D613305.D4C595F@Sun.COM> Message-ID: <3D613E6D.8070401@easysw.com> Norm Jacobs wrote: > Virtually every time that I use papiAttributeFind(), I follow it > up > with a test for existence, a test for type match, and an assignment > from the value(s). It would be much more convenient to simply be able > to retreive the value(s) directly. As a result, I am proposing the > following > addition: > ... Hmm, I'm not too keen on the varargs approach, as it is error-prone. FWIW, the original CUPS implementation (ippFindAttribute and ippFindNextAttribute) provides an attribute type in the function call (with IPP_TAG_ZERO meaning "any type") for the very reasons you cite - you want to know if there is a named attribute of the proper type. You then access the value(s) directly if the returned pointer is non-NULL. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Mon Aug 19 11:55:11 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions References: <3D613309.468A2F99@Sun.COM> Message-ID: <3D613F0F.4010408@easysw.com> Norm Jacobs wrote: > ... > /* Delete the named attribute from the attribute list. */ > extern papi_status_t papiAttributeDelete(papi_attribute_t ***attributes, > const char *name); I agree. > /* Modify the job (printer/id) using the supplied attributes, return the > status and a resulting job. */ > extern papi_status_t papiJobModify(papi_service_t svc, > const char *printer, > const int32_t id, > const papi_attribute_t **attributes, > papi_job_t *result); Agreed. > /* Modify a printer using the supplied attributes, return the status and > a > resulting printer object. */ > extern papi_status_t papiPrinterModify(papi_service_t svc, > const char *printer, > const papi_attribute_t **attributes, > papi_printer_t *result); Agreed. > /* Delete a printer, return status */ > extern papi_status_t papiPrinterDelete(papi_service_t svc, > const char *printer); We don't have a papiPrinterAdd(), so why do we need papiPrinterDelete()? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Mon Aug 19 11:57:31 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: implementation References: <3D613323.A9B69120@Sun.COM> Message-ID: <3D613F9B.3050302@easysw.com> Norm Jacobs wrote: > For those that are interested, I have a template implementation of > the PAPI v0.4 draft. The implementation includes: > ... > This is code that I have based a Solaris LP prototype implementation > of the current draft on. If is reasonably generic and builds on > Linux. It is currently licensed under the LGPL and uses > autoconf/automake in it's build environment. When v0.5 of the PAPI > spec becomes available, I will incorporate the diffs from v0.4 to > v0.5 and upload this code to the PWG ftp server for your > viewing/implementing pleasure. Hopefully, this will relieve people > of some of the pain involved in converting the specification to code. Norm, Thanks for the implementation; if you'd like, I can contribute the CUPS implementation code as well to this as time permits, as well as code for generic LPR support. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From Norm.Jacobs at Sun.COM Mon Aug 19 12:00:24 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions References: <3D613309.468A2F99@Sun.COM> <3D613F0F.4010408@easysw.com> Message-ID: <3D614048.FDC40451@Sun.COM> Michael Sweet wrote: > > > /* Delete a printer, return status */ > > extern papi_status_t papiPrinterDelete(papi_service_t svc, > > const char *printer); > > We don't have a papiPrinterAdd(), so why do we need > papiPrinterDelete()? > At some point, I would like to be able to add/delete printers to/from a print service using a common API. We don't need to address this right now, but I would like a standard way of doing it. I know that there are some print service specific attributes that may be desirable to set at add time. I would, at least, expect "reasonable" defaults for service specific attributes that are required, but not specified. -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 12:30:47 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue References: <3D613305.D4C595F@Sun.COM> <3D613E6D.8070401@easysw.com> Message-ID: <3D614767.CE49B625@Sun.COM> Michael Sweet wrote: > > Norm Jacobs wrote: > > Virtually every time that I use papiAttributeFind(), I follow it > > up > > with a test for existence, a test for type match, and an assignment > > from the value(s). It would be much more convenient to simply be able > > to retreive the value(s) directly. As a result, I am proposing the > > following > > addition: > > ... > > Hmm, I'm not too keen on the varargs approach, as it is error-prone. > > FWIW, the original CUPS implementation (ippFindAttribute and > ippFindNextAttribute) provides an attribute type in the function > call (with IPP_TAG_ZERO meaning "any type") for the very reasons > you cite - you want to know if there is a named attribute of the > proper type. You then access the value(s) directly if the returned > pointer is non-NULL. > If you want strong type / compile-time checking, we could break it out into one per type (list the papiAttributeAdd*() calls. This would remove the chance that someone put the wrong varargs arguments in the call. extern papi_status_t papiAttributeListGetString(papi_attribute_t **list, void **iter, const char *name, char **string); extern papi_status_t papiAttributeListGetInteger(papi_attribute_t **list, void **iter, const char *name, int *integer); extern papi_status_t papiAttributeListGetBoolean(papi_attribute_t **list, void **iter, const char *name, int *boolean); extern papi_status_t papiAttributeListGetRange(papi_attribute_t **list, void **iter, const char *name, int *min, int *max); extern papi_status_t papiAttributeListGetResolution(papi_attribute_t **list, void **iter, const char *name, int *x, int *y, char **unit); extern papi_status_t papiAttributeListGetDatetime(papi_attribute_t **list, void **iter, const char *name, time_t *dt); Basically, I'm relatively lazy. If I can avoid typing in virtually the same code repeatedly, I will. In a number of places, I am using some variant of the following: attribute = papiAttributeFind(attributes, "copies"); if ((attribute != NULL) && (attribute->type != PAPI_INTEGER) && (attribute->values != NULL)) copies = attribute->values[0]->integer; I would prefer to type (and read): papiAttributeListGetValue(attributes, NULL, "copies", PAPI_INTEGER, &copies); and/or papiAttributeListGetInteger(attributes, NULL, "copies", &copies); -Norm From mike at easysw.com Mon Aug 19 13:13:03 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions References: <3D613309.468A2F99@Sun.COM> <3D613F0F.4010408@easysw.com> <3D614048.FDC40451@Sun.COM> Message-ID: <3D61514F.8040809@easysw.com> Norm Jacobs wrote: > ... > At some point, I would like to be able to add/delete printers to/from > a print service using a common API. We don't need to address this > right now, but I would like a standard way of doing it. I know that > there are some print service specific attributes that may be > desirable to set at add time. I would, at least, expect "reasonable" > defaults for service specific attributes that are required, but not > specified. Hmm, the main problem I see with this is that printer configuration/ setup is substantially different between OS's, printing systems, etc., and opens up a whole new can of security worms... (how do you enumerate supported devices/schemes, printer drivers/ interface scripts, etc?) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Mon Aug 19 13:16:33 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue References: <3D613305.D4C595F@Sun.COM> <3D613E6D.8070401@easysw.com> <3D614767.CE49B625@Sun.COM> Message-ID: <3D615221.6030303@easysw.com> Norm Jacobs wrote: > ... > papiAttributeListGetValue(attributes, NULL, "copies", PAPI_INTEGER, > &copies); > > and/or > > papiAttributeListGetInteger(attributes, NULL, "copies", &copies); With the CUPS approach, it would be something like: papiAttributeFind(attributes, iterator, "name", PAPI_TYPE, &attr); and then reference the integer value in "attr", which could be supported via macros to save typing? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From Norm.Jacobs at Sun.COM Mon Aug 19 14:31:08 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue References: <3D613305.D4C595F@Sun.COM> <3D613E6D.8070401@easysw.com> <3D614767.CE49B625@Sun.COM> <3D615221.6030303@easysw.com> Message-ID: <3D61639C.A71D2988@Sun.COM> Michael Sweet wrote: > > Norm Jacobs wrote: > > ... > > papiAttributeListGetValue(attributes, NULL, "copies", PAPI_INTEGER, > > &copies); > > > > and/or > > > > papiAttributeListGetInteger(attributes, NULL, "copies", &copies); > > With the CUPS approach, it would be something like: > > papiAttributeFind(attributes, iterator, "name", PAPI_TYPE, &attr); > > and then reference the integer value in "attr", which could be > supported via macros to save typing? > In the case of the type specific calls, I would prefer to get the actual attribute value in it's native type in one call. That way, I can do things like: papiAttributeListGetString(attributes, NULL, "printer-name", &r->destination); papiAttributeListGetInteger(attributes, NULL, "copies", &r->copies); papiAttributeListGetInteger(attributes, NULL, "number-up", &r->nup); instead of if (papiAttributeListGetString(attributes, NULL, "printer-name", &v) == PAPI_OK) r->destination = v->string; if (papiAttributeListGetString(attributes, NULL, "copies", &v) == PAPI_OK) r->copies = v->integer; if (papiAttributeListGetString(attributes, NULL, "number-up", &v) == PAPI_OK) r->nup = v->integer; In the generic call, we can use the papi_attribute_value_t instead of using varargs. So we would add: extern papi_status_t papiAttributeGetValue(papi_attribute_t **attributes, void **iterator, const char *name, papi_attribute_value_t **value); extern papi_status_t papiAttributeListGetString(papi_attribute_t **list, void **iter, const char *name, char **string); extern papi_status_t papiAttributeListGetInteger(papi_attribute_t **list, void **iter, const char *name, int *integer); extern papi_status_t papiAttributeListGetBoolean(papi_attribute_t **list, void **iter, const char *name, int *boolean); extern papi_status_t papiAttributeListGetRange(papi_attribute_t **list, void **iter, const char *name, int *min, int *max); extern papi_status_t papiAttributeListGetResolution(papi_attribute_t **list, void **iter, const char *name, int *x, int *y, char **unit); extern papi_status_t papiAttributeListGetDatetime(papi_attribute_t **list, void **iter, const char *name, time_t *dt); This pretty much mirrors the papiAttributeAdd*() calls. -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 14:40:00 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeListGetValue References: <3D613305.D4C595F@Sun.COM> <3D613E6D.8070401@easysw.com> <3D614767.CE49B625@Sun.COM> <3D615221.6030303@easysw.com> <3D61639C.A71D2988@Sun.COM> Message-ID: <3D6165B0.CD91A20C@Sun.COM> Norm Jacobs wrote: > > extern papi_status_t papiAttributeGetValue(papi_attribute_t **attributes, > void **iterator, const char *name, > papi_attribute_value_t **value); oops extern papi_status_t papiAttributeGetValue(papi_attribute_t **attributes, void **iterator, const char *name, papi_attribute_value_type_t type, papi_attribute_value_t **value); -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 15:07:29 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd Message-ID: <3D616C21.8BA6E0F0@Sun.COM> The papiAttributeAdd() call currently takes a void ** as the last argument. We may want to change this to papi_attribute_value_t *. It seems to make more sense that way. the change would be to extern papi_status_t papiAttributeAdd(papi_attribute_t ***attrs, const int update_type, const char *name, const papi_attribute_value_type_t type, const papi_attribute_value_t *value); -Norm From Norm.Jacobs at Sun.COM Mon Aug 19 15:15:25 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions References: <3D613309.468A2F99@Sun.COM> <3D613F0F.4010408@easysw.com> <3D614048.FDC40451@Sun.COM> <3D61514F.8040809@easysw.com> Message-ID: <3D616DFD.5ECEB03E@Sun.COM> Michael Sweet wrote: > > Norm Jacobs wrote: > > ... > > At some point, I would like to be able to add/delete printers to/from > > a print service using a common API. We don't need to address this > > right now, but I would like a standard way of doing it. I know that > > there are some print service specific attributes that may be > > desirable to set at add time. I would, at least, expect "reasonable" > > defaults for service specific attributes that are required, but not > > specified. > > Hmm, the main problem I see with this is that printer configuration/ > setup is substantially different between OS's, printing systems, > etc., and opens up a whole new can of security worms... > > (how do you enumerate supported devices/schemes, printer drivers/ > interface scripts, etc?) > Ok, we can scrap the add/delete printers for the time being. I would like ito ba able to add/delete printers some time down the road (I know wishful thinking;). -Norm From hlava at us.ibm.com Tue Aug 20 09:04:22 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions Message-ID: OK, here's what I think we have consensus to change in the next version of PAPI: * Add convenience functions to get attribute values from attribute lists with one call: papiAttributeListGetValue papiAttributeListGetString papiAttributeListGetInteger ...etc... * Add some management functions: papiAttributeDelete papiJobModify papiPrinterModify Please let me know ASAP if you disagree with these additions (I might have missed something in the flurry of recent posts). I'll plan to start adding these tomorrow unless I hear objections. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020820/0b83e55a/attachment.htm From imcdonald at sharplabs.com Tue Aug 20 10:14:24 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: management additions Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD5C@mailsrvnt02.enet.sharplabs.com> Hi Alan, By 'papiJobModify' I _think_ you mean the functionality in the IPP Admin extension operation 'SetJobAttributes'? The IPP spec is: "Internet Printing Protocol (IPP): Job and Printer Set Operations", T. Hastings, R. Herriot, R. Bergman, T. Hastings, 06-SEP-01, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-job-printer-set-ops-05.txt (In IPP, we did not distinguish betweening adding an attribute and modifying an attribute already present on the Job - the Set does both). Cheers, - Ira McDonald -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Tuesday, August 20, 2002 12:04 PM To: printing-spool@freestandards.org Subject: Re: [printing-spool] PAPI v0.4: management additions OK, here's what I think we have consensus to change in the next version of PAPI: * Add convenience functions to get attribute values from attribute lists with one call: papiAttributeListGetValue papiAttributeListGetString papiAttributeListGetInteger ...etc... * Add some management functions: papiAttributeDelete papiJobModify papiPrinterModify Please let me know ASAP if you disagree with these additions (I might have missed something in the flurry of recent posts). I'll plan to start adding these tomorrow unless I hear objections. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hastings at cp10.es.xerox.com Tue Aug 20 13:41:05 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 [and querying m edia capabilities] Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90807024D@x-crt-es-ms1.cp10.es.xerox.com> I wanted to correct a small detail in what Michael wrote about IPP and show how Alan's papiPrinterQuery works nicely with existing IPP media attributes: Michael wrote: "One of the problems with exposing printer capabilities is that it is hard to define what they are - do you try to cover everything, or are you interested in just enumerating the allowed combinations and the basic capabilities/attributes? The IPP media-col-supported attribute tries to do this for media selections, however it requires you to list *every* possible combination, which can be a lot of values and is not a convenient way for the user to choose options..." The IPP WG considered making the "media-col-supported" have the attribute syntax of '1setOf collection' which would have worked as Michael suggested above with the problems he indicated. However, the IPP WG abandoned that because a Printer that was configured to support 500 different media would have 500 collection values, where each collection value would have had the individual member attributes: "media-color", "media-size", "media-weight-metric", "media-type", etc for each media instance. Instead, the IPP "media-col-supported" attribute is a '1setOf keyword' and so returns the keyword names of the "media-col" member attributes supported by the Printer, i.e., 'media-color', 'media-size', 'media-weight-metric', 'media-type', etc. The client can then (or initially) query for the "media-color-supported", "media-size-supported", "media-weight-metric", "media-type-supported", etc, attributes. But such querying doesn't give the actual supported combinations, so a user could choose a combination that isn't actually supported. So IPP is still looking for a solution to the media capabilities problem that allows the application to determine which combinations of media attributes are supported. At Xerox we have a private IPP "media-col-database" (1setOf collection) attribute which does return all the supported combinations. The IPP WG felt that when it is needed to be able to query for all combinations, we should add an IPP Media object to IPP with its own proper query functions: Get-Media-Attributes and Get-Media operations. These operations, like Get-Job-Attributes and Get-Jobs, would have a specific filter appropriate to media, so that you could ask for all media of a certain size or a certain type, etc. Which brings us to Alan Hlava's proposed papiPrinterQuery call and what we can do about media. His proposal allows the client to supply any amount of IPP job context attributes and then the returned values are the ones that can still be supported, i.e., are still unconstrained by the supplied job context attributes. So if the client supplies a "media-col" (collection) attribute with, say, "media-size" filled in with 8.5 x 11, and "media-type" filled in with 'transparency', and asks for "media-name" and "media-color" attributes, the API will return the names of the media ("media-name-supported") and the colors ("media-color-supported") as separate independent lists. The user chooses, say, a color, and the application then makes a second query which returns the names of the media that meet the supplied job context of size, type, and (now) color. Thus Alan's API allows an application to zero in on a single media, by making successive calls, as the user chooses from amongst the remaining unconstrained job media attributes. So all of the existing IPP attributes work with Alan's proposal papiPrinterQuery function call without needing any extensions for grouping or inter-attribute constraints. Hooray! See ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.pdf or ftp://ftp.pwg.org/pub/pwg/fsg/spool/IPP-Object-Attributes.doc for the listing of all of the media attributes so far. (Of course we need to add the media member attributes for imageable area and imagable margins that people have been talking about that PDL generator applications need). Tom From hastings at cp10.es.xerox.com Tue Aug 20 13:49:26 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90807024E@x-crt-es-ms1.cp10.es.xerox.com> Michael wrote: "Thankfully, extending IPP is not a problem, and the PWG could certainly publish an extension spec that could be used by all... (and, FWIW, I'd be happy to author the spec based on what we work out here...)" I'm sure the PWG would be very happy to have Michael author an IPP extension spec from the work developed here and publish it as a PWG IEEE-ISTO spec (and give feedback on it as well during the process). Tom From mike at easysw.com Tue Aug 20 14:11:57 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-cap] Re: [printing-spool] PAPI V0.4 [and querying m edia capabilities] References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90807024D@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3D62B09D.7090009@easysw.com> Hastings, Tom N wrote: > I wanted to correct a small detail in what Michael wrote about IPP > and show how Alan's papiPrinterQuery works nicely with existing IPP > media attributes: > ... > "media-type", etc for each media instance. Instead, the IPP > "media-col-supported" attribute is a '1setOf keyword' and so returns > the keyword names of the "media-col" member attributes supported by > the Printer, i.e., 'media-color', 'media-size', > 'media-weight-metric', 'media-type', etc. The client can then (or > initially) query for the "media-color-supported", > "media-size-supported", "media-weight-metric", > "media-type-supported", etc, attributes. But such querying doesn't > give the actual supported combinations, so a user could choose a > combination that isn't actually supported. So IPP is still looking > for a solution to the media capabilities problem that allows the > application to determine which combinations of media attributes are > supported. Hmm, well it's definitely not obvious from the spec, and if the media-col-supported attribute is not a sub-attribute of the media-col attribute, then the spec headings are also not accurate. Also, the spec does *not* document media-color-supported, etc. as printer object attributes that can be queried directly; from your description, and from what I can get from the spec, you'd have to get the media-col-supported values and then randomly put them in to the sub-attributes looking for valid values? > ... > The IPP WG felt that when it is needed to be able to query for all > combinations, we should add an IPP Media object to IPP with its own > proper query functions: Get-Media-Attributes and Get-Media > operations. These operations, like Get-Job-Attributes and Get-Jobs, > would have a specific filter appropriate to media, so that you could > ask for all media of a certain size or a certain type, etc. I don't remember any discussions along these lines; as I recall, we ended up talking about a generic resource object mechanism that would apply to fonts, media, etc. > ... > ("media-name-supported") and the colors ("media-color-supported") as > separate independent lists. The user chooses, say, a color, and the > ... OK, I think I've found the cause of the confusion. The PWG 5100.3 spec does not document the printer attributes, only the job template attributes. There are tiny little one-sentence references to the printer attributes embedded in the descriptions of some of the job template attributes, which makes it impossible to decipher the whole thing... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Wed Aug 21 11:08:35 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] RE: [printing-cap] PAPI V0.4 [and querying media capabilities] - Resource objects Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD5F@mailsrvnt02.enet.sharplabs.com> Hi, A comment about Media and generic Resource objects in IPP below. Cheers, - Ira McDonald, co-editor of IPP Resource Objects drafts High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Tuesday, August 20, 2002 5:12 PM To: printing-cap@freestandards.org Cc: printing-spool@freestandards.org Subject: Re: [printing-cap] Re: [printing-spool] PAPI V0.4 [and querying m edia capabilities] Hastings, Tom N wrote: > I wanted to correct a small detail in what Michael wrote about IPP > and show how Alan's papiPrinterQuery works nicely with existing IPP > media attributes: > ... <...snip...> > ... > The IPP WG felt that when it is needed to be able to query for all > combinations, we should add an IPP Media object to IPP with its own > proper query functions: Get-Media-Attributes and Get-Media > operations. These operations, like Get-Job-Attributes and Get-Jobs, > would have a specific filter appropriate to media, so that you could > ask for all media of a certain size or a certain type, etc. I don't remember any discussions along these lines; as I recall, we ended up talking about a generic resource object mechanism that would apply to fonts, media, etc. We made good headway on a generic Resource object mechanism for IPP. It was abandoned largely at the urging of IETF IPP working group chair Carl-Uno Manros, because he objected to the overloading of the generic XxxResource operations for client authorization. Other existing IPP operations do NOT require the decoding of any attributes inside the operation envelope before deciding to do role-based authorization - job-owner, end-user, operator, or administrator. Harry Lewis (IBM) has recently suggested that we resurrect Resource objects in IPP for holding both standardized and vendor-specific "job tickets". And we obviously need a Media object solution. On reflection I think Carl-Uno's client authorization argument against generic Resource objects is not that strong - the ONLY enclosed attribute that must be examined is the 'resource-type' attribute (used to morph across defined and published supported Resource types). Shall Tom Hastings and I renew our efforts on a PWG IEEE/ISTO spec for IPP Resource objects and their canonical operations? > ... > ("media-name-supported") and the colors ("media-color-supported") as > separate independent lists. The user chooses, say, a color, and the > ... OK, I think I've found the cause of the confusion. The PWG 5100.3 spec does not document the printer attributes, only the job template attributes. There are tiny little one-sentence references to the printer attributes embedded in the descriptions of some of the job template attributes, which makes it impossible to decipher the whole thing... I agree with you Michael. Fortunately, the soon-to-be forthcoming IANA IPP Registrations file (plaintext with pointers to source IETF and/or PWG standards specs) will be maintained by IANA and SHOULD help improve such problems. A similar sort of problem exists in the base IPP/1.1 spec (RFC 2911) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-cap mailing list printing-cap@freestandards.org http://freestandards.org/mailman/listinfo/printing-cap From mike at easysw.com Wed Aug 21 11:40:06 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: [printing-cap] PAPI V0.4 [and querying media capabilities] - Resource objects References: <116DB56CD7DED511BC7800508B2CA53735CD5F@mailsrvnt02.enet.sharplabs.com> Message-ID: <3D63DE86.7040603@easysw.com> McDonald, Ira wrote: > ... > I don't remember any discussions along these lines; as I recall, > we ended up talking about a generic resource object mechanism > that would apply to fonts, media, etc. > > We made good headway on a generic Resource object mechanism for > IPP. It was abandoned largely at the urging of IETF IPP working group > chair Carl-Uno Manros, because he objected to the overloading of > the generic XxxResource operations for client authorization. Other > existing IPP operations do NOT require the decoding of any attributes > inside the operation envelope before deciding to do role-based > authorization - job-owner, end-user, operator, or administrator. > > Harry Lewis (IBM) has recently suggested that we resurrect Resource > objects in IPP for holding both standardized and vendor-specific > "job tickets". And we obviously need a Media object solution. > > On reflection I think Carl-Uno's client authorization argument > against generic Resource objects is not that strong - the ONLY > enclosed attribute that must be examined is the 'resource-type' > attribute (used to morph across defined and published supported > Resource types). > > Shall Tom Hastings and I renew our efforts on a PWG IEEE/ISTO > spec for IPP Resource objects and their canonical operations? > > ... Yes, I think that would be beneficial. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From pzaan at us.ibm.com Wed Aug 21 11:57:47 2002 From: pzaan at us.ibm.com (Pete Zannucci) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] RE: [printing-cap] (no subject) [Capability Query addition to PAP I] [additions to IPP] Message-ID: Hastings, Tom N wrote: > Agreed. So it needs to be four numbers in order to handle margins that are > different on all four sides, right? The Enhanced UPnPv1 template has four > margin values in order: top, right, bottom, and left as in CSS2. They used > decimal fractions. But IPP has been using 100th of mm size as in PWG 5100.3 > so that it can be presented as an integer. There are three ways that I can > see to represent these four integers as member attributes of the "media-col" > (collection) attribute in an IPP extension: So we are saying that we can provide back a group of margins (based on a form size) that will correlate to a collection of attributes that represent the document or job? Michael Sweet wrote: >> Finally, relying on the media-col attribute to enumerate all of >> the possible combos of allowable options is not efficient - >> think of a large-format printer and the hundreds of supported >> media sizes, sources, types, etc. There can be literally >> thousands of combinations returned in the media-col-supported >> attribute, which may make them unsuitable for production >> environments... (who wants their print dialog to use 10MB of RAM?) Seen that... Usability gets just as ugly as the number and presentation of all those options together. You'll never find what option group you are looking for on a large printer because there will be so many. > - Tom Hastings > See my previous mail on this subject. Fortunately, IPP doesn't have a > "media-col-supported" with a 1setOf collection syntax, or the size problem > that Michael indicates would occur....... > So the application can make successive calls on the API to narrow down the > media attributes, just like any other job attributes. > Don't we think that there should be the ability to provide a setting for a collection of attributes so that we can get a grouping of margins returned? You don't want to continue to connect to that server in Washington DC to find out enough to do another successive call from your system in Portland Oregon. We could cut down on the amount of information we are dealing with if we have only the available options that can be set presented to the user. They should be constrained as much as possible to limit choices. Once the choice of selections is made, use that collection of attributes to get the real physical information about the page. Michael Sweet wrote: >> I would argue that printer vendors are already doing this with PPD >> files, and have been doing it for many years now. I would also >> argue that if applications use PAPI to get this information, then >> the FSG has little incentive to push a particular file format, >> since PAPI implementations can hide this information quite >> effectively and transparently! > - Tom Hastings from here on out > > I agree that the PAPI interface nicely hides how the implementation gets the > capability information, whether from a PPD file, a GPD file, a UPDF file, > some new FSG capabilities file, a CIP4 JDF/1.1 capabilities file, a CIP4 > JDF/1.1 schema with annotations, or actual queries to the printer perhaps > using some network protocol, such as IPP, PWG PSI or CIP4 JDF JMF (Job > Message Format). > Now, I'm really confused by the long dialog that Peter and Michael have been > having! Because Peter seemed to be talking about describing capabilities in > a static file with grouping, etc., such as a PPD file (with extensions) or > one of the above format files. So I have several questions of the FSG > Capabilities Task Group: On this point, I was talking about a savings of the current printer configuration that will allow only valid selections to be made. During the install of the queue or printer, the valid options (stapler, duplexer, collater,etc) could be written to a file (in some format such as UPDF) and the user will only be presented with valid options based on the REAL hardware configuration. There are drivers that display a rendition of what the printer has installed on it as a bitmap and as you add components, the printer bitmap changes. Along with that bitmap change, underlying changes in groupings of attributes also occurs. Before you configured the duplex option, it was not selectable by the user. The .ppd file might have stacker in it but we would need a way of storing the attibutes to know that just because the .ppd file has stacker in it, the printer really doesn't have one attached to it so the option is not selectable. I am just looking for a management/storage mechanism for device configuration options so as to limit the user choices to only the ones that the printer is configured for. LATER we will need to work on how to limit those choices for a user. They can't use upper tray and their job priority is lower than the CEO's > 1. So is the FSG Capabilities Task Group going to come up with a file > format, as well as a function call API? Maybe... > 2. For the capabilities file format, will it be one of: > PPD file with extensions > a GPD file > a UPDF file > some new FSG capabilities file > a CIP4 JDF/1.1 capabilities file > a CIP4 JDF/1.1 schema with annotations > something else > b. The representation of each attribute value (instruction) in some Job > Ticket format, so that the application that generates the Job Ticket can be > data driven from the API. That could be handled by adding some sort of an > "xxx-job-ticket" attribute. I believe Mark Hamzy discussed the conventions for using standard names for transactions so the application could know what it was dealing with and set it programatically. Norbert (PWG) was to be looking at this for UPDF (would be good if UPDF is used for the base construct of capabilities). > c. The representation of each attribute value (instruction) in some PDL > format, so that the application that generates the PDL data can be data > driven from the API. That could be handled by adding some sort of an > "xxx-pdl" attribute. It would be nice to not generate PDL at a client if at all possible. The late binding concept would be nicer and just use the attributes that are provided by the job ticket to drive the backend processing of the job and the creation of a PDL if other than postscript. Otherwise it sounds like we should be really looking at a UPDF driver. Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com From hlava at us.ibm.com Wed Aug 21 12:20:39 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd Message-ID: On Monday, 08/19/2002 at 05:07 EST, Norm Jacobs wrote: > The papiAttributeAdd() call currently takes a void ** as the last > argument. > We may want to change this to papi_attribute_value_t *. It seems to > make more sense that way. It currently takes a void* and I think I prefer it that way. I don't really want to build a papi_attribute_value_t when I can just pass a pointer to the actual value. What is the advantage of passing the value union instead of a simple pointer to the value? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020821/a4b4b48c/attachment.htm From mike at easysw.com Wed Aug 21 12:33:07 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] Re: [printing-cap] (no subject) [Capability Query addition to PAP I] [additions to IPP] References: Message-ID: <3D63EAF3.1010000@easysw.com> Pete Zannucci wrote: > ... > So we are saying that we can provide back a group of margins (based > on a form size) that will correlate to a collection of attributes > that represent the document or job? Yes. > ... > user. The .ppd file might have stacker in it but we would need a > way of storing the attibutes to know that just because the .ppd file > has stacker in it, the printer really doesn't have one attached to it > so the option is not selectable. > ... Actually, this isn't a good example, since PPD files regularly *do* contain this information, in the form of an InstallableOptions group and the corresponding constraints between installable options and printing options. For example, the PPD file for a LaserJet 4100 has installable options for duplexer, envelope feeder, lower tray, and large capacity tray, and there are UIConstraint attributes defined for the various options and sizes limiting what you can choose based on the installed options (plus the usual constraints between printing options) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From Norm.Jacobs at Sun.COM Wed Aug 21 12:33:41 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd Message-ID: <3D63EB15.8F32198D@Sun.COM> If you don't want to have to build the papi_attribute_value_t structure to pass to papiAttributeAdd(), then it would need to use varargs. The number of values supplied is dependent on the attribute type. Ex: papiAttributeAdd(list, flags, name, PAPI_STRING, string); PAPI_STRING requires a char* papiAttributeAdd(list, flags, name, PAPI_INTEGER, integer); PAPI_INTEGER requires an int papiAttributeAdd(list, flags, name, PAPI_BOOLEAN, boolean); PAPI_BOOLEAN requires an int papiAttributeAdd(list, flags, name, PAPI_DATETIME, now); PAPI_DATETIME requires a time_t papiAttributeAdd(list, flags, name, PAPI_RANGE, min, max); PAPI_RANGE requires 2 ints papiAttributeAdd(list, flags, name, PAPI_RESOLUTION, x, y, units); PAPI_RESOLUTION requires 2 ints and a papi_resolution_unit_t (The above were effectively my implementations of the type specific AttributeAdd routines.) Personally, I would prefer the varargs approach to the papi_attribute_value_t approach. I had the varargs approach implemented and was using it until a couple days ago (when I noticed that I wasn't implementing to spec). I have since switched to the papi_attribute_value_t approach to implemented to what I though would be in 0.5. I would be happy to go back to the varargs approach, but because the number of values needed is type specific, I don't think that void * is really an option. -Norm ----- Original Message ----- >From: Alan Hlava >To: printing-spool@freestandards.org >Sent: Wednesday, August 21, 2002 2:20 PM >Subject: Re: [printing-spool] PAPI v0.4: papiAttributeAdd >On Monday, 08/19/2002 at 05:07 EST, Norm Jacobs wrote: >> The papiAttributeAdd() call currently takes a void ** as the last >> argument. >> We may want to change this to papi_attribute_value_t *. It seems to >> make more sense that way. >It currently takes a void* and I think I prefer it that way. I don't really want to >build a papi_attribute_value_t when I can just pass a pointer to the actual value. What is >the advantage of passing the value union instead of a simple pointer to the value? From hlava at us.ibm.com Wed Aug 21 13:11:22 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd Message-ID: On Wednesday, 08/21/2002 at 02:33 EST, Norm Jacobs wrote: > If you don't want to have to build the papi_attribute_value_t structure > to > pass to papiAttributeAdd(), then it would need to use varargs. The > number > of values supplied is dependent on the attribute type. Ex: > > papiAttributeAdd(list, flags, name, PAPI_STRING, string); > PAPI_STRING requires a char* > > papiAttributeAdd(list, flags, name, PAPI_INTEGER, integer); > PAPI_INTEGER requires an int > > papiAttributeAdd(list, flags, name, PAPI_BOOLEAN, boolean); > PAPI_BOOLEAN requires an int > > papiAttributeAdd(list, flags, name, PAPI_DATETIME, now); > PAPI_DATETIME requires a time_t > > papiAttributeAdd(list, flags, name, PAPI_RANGE, min, max); > PAPI_RANGE requires 2 ints > > papiAttributeAdd(list, flags, name, PAPI_RESOLUTION, x, y, units); > PAPI_RESOLUTION requires 2 ints and a papi_resolution_unit_t > Ah, now I see the disconnect. I was assuming (but neglected to document) that the papiAttributeAdd function could not be used for the value types that take more than one sub-value. Since we have the type-specific add functions to add them, this is not a big restriction and it allows a simple void* interface to the general add function. What do you think about going with this approach and just updating the spec to reflect the restriction? (The same question/answer applies to the new papiAttributeListGetValue function's last argument.) Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020821/f66ee3b6/attachment.htm From Norm.Jacobs at Sun.COM Wed Aug 21 13:21:55 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd References: Message-ID: <3D63F663.F6864803@Sun.COM> I would say that we should either use papi_attribute_value_t or a varargs approach. We should not restrict papiAttributeAdd() to only "special" (only one value required in setting) attribute types. That is almost guaranteed to cause problems. I know that it will add complexity to the implementation. So far the only objection to using varargs that I recall seeing is that it negates some compile time checking that might catch a coding error up front when a developer wasn't careful in using the interface. The papi_attribute_value_t approach provides that additional compile time checking. A void * approach would not. I prefer the varargs method of doing these things because it doesn't require the developer to do extra work on add/get. attributes/values. They simply use the native type. I think that the type specific Add/Get routines along with general Add/Get routines that use the papi_attribute_value_t provide a reasonable compromise. They allow stronger compile time checking (all papiAttribute{Add|Get}*() calls) and also a method of adding values without requiring the application developer to fill in a structure to pass in or pull data out of a structure returned (the type specific papiAttribute{Add|Get}.() calls). -Norm Alan Hlava wrote: > > On Wednesday, 08/21/2002 at 02:33 EST, Norm Jacobs > wrote: > > If you don't want to have to build the papi_attribute_value_t > structure > > to > > pass to papiAttributeAdd(), then it would need to use varargs. The > > number > > of values supplied is dependent on the attribute type. Ex: > > > > papiAttributeAdd(list, flags, name, PAPI_STRING, string); > > PAPI_STRING requires a char* > > > > papiAttributeAdd(list, flags, name, PAPI_INTEGER, integer); > > PAPI_INTEGER requires an int > > > > papiAttributeAdd(list, flags, name, PAPI_BOOLEAN, boolean); > > PAPI_BOOLEAN requires an int > > > > papiAttributeAdd(list, flags, name, PAPI_DATETIME, now); > > PAPI_DATETIME requires a time_t > > > > papiAttributeAdd(list, flags, name, PAPI_RANGE, min, max); > > PAPI_RANGE requires 2 ints > > > > papiAttributeAdd(list, flags, name, PAPI_RESOLUTION, x, y, > units); > > PAPI_RESOLUTION requires 2 ints and a > papi_resolution_unit_t > > > Ah, now I see the disconnect. I was assuming (but neglected to > document) that the papiAttributeAdd function could not be used for the > value types that take more than one sub-value. Since we have the > type-specific add functions to add them, this is not a big restriction > and it allows a simple void* interface to the general add function. > What do you think about going with this approach and just updating > the spec to reflect the restriction? (The same question/answer > applies to the new papiAttributeListGetValue function's last > argument.) > > Regards, > > Alan Hlava > IBM Printing Systems Division > hlava@us.ibm.com From hlava at us.ibm.com Thu Aug 22 05:55:13 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] PAPI v0.4: papiAttributeAdd Message-ID: On Wednesday, 08/21/2002 at 03:21 EST, Norm Jacobs wrote: > I would say that we should either use papi_attribute_value_t > or a varargs approach. We should not restrict papiAttributeAdd() > to only "special" (only one value required in setting) attribute > types. After thinking about this some more, I think we should change this to use papi_attribute_value_t. The reason I think this is preferable to void* and varargs is that, as we add more complex value syntaxes in the future, the void* usage becomes more restricted and the use of varargs becomes increasingly complex and error-prone. But the papi_attribute_value_t. structure will simply be updated, leaving the API unchanged. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020822/ed86bad4/attachment.htm From hastings at cp10.es.xerox.com Thu Aug 22 13:52:17 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:47 2007 Subject: [printing-spool] First Draft IPP Document Object spec down-loaded Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F9080702FC@x-crt-es-ms1.cp10.es.xerox.com> Peter Zehler posted the next draft (0.07) of the PWG Semantic Model on August 16 at: ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Model-07-020816.pdf The PWG Semantic Model document is intended to be short and to refer to other documents for the details (mostly IPP documents). The PWG Semantic Model is also intended to be used by other groups that are developing print semantics in order to make any API, protocol, and job ticket semantics as similar as possible, such as those being developed by other PWG sub-groups and other groups, such as the sub-groups in the Free Standards Group OpenPrinting WG. The PWG Semantic Model adds a new Document object to the model. It re-uses most of the existing Job attributes for the Document object. However, the detailed specification for the Document object, operations, attributes, and values is needed for the Semantic Model to reference. This mail note announces a first draft of such a 36-page document. Its available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.pdf 200Kb ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.doc 1000Kb ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.zip 140Kb - just the .doc The .doc file is 1Mbyte, probably because of the two Visio state diagrams, or maybe the tables. This IPP Document Object specification is intended to give a common semantic model for the Document object for use by IPP (ipp@pwg.org), the PWG Semantic Model (sm@pwg.org), the PWG Print Services Interface (PSI) (ps@pwg.org), and the Free Software Group (FSG) PAPI (printing-spool@freestandards.org) and Job Ticket APIs (printing-jobticket@freestandards.org). For more info on the 3 PWG sub-groups, visit http://www.pwg.org For more info on the 2 FSG sub-groups, visit http://www.freestandards.org/openprinting The PWG is meeting next week in Santa Fe: Monday Aug 26: Internet FAX Tuesday Aug 27: PWG Plenary/XHTML-print Wednesday, Aug 28: Print Services Interface (PSI) (Thursday UPnP). There are 9 issues (included below) in the document that would be good to handle at some point in the agenda. And any other issues raised by reading the spec would be good too. Since there are 5 groups working on this (see To list), I suggest that any comments be sent to all lists as a reply all. Here is the Abstract: This document is an IPP extension proposal to extend the IPP/PWG semantics to include a Document object. The Job object is said to contain one or more Document objects which are passive objects operated on by the Job. The Document object is created by the existing Send-Document and Send-URI operations. However, a client can supply additional Document Template attributes with each document and new Document Description attributes are defined. Also there are seven new operations defined for Documents once they have been created. The purpose for specifying the Document object, is so that we can have a common specification for use in IPP, the PWG Semantic Model, the PWG PSI project, and the Free Standards Group Job Ticket API which all have a Document object. Here are the 9 issues: ISSUE 01: Should we publish this document as an IETF standards track document or as an IEEE-ISTO standard? If the former, since the IETF IPP WG is in the process of being closed down when all the current specifications are published, Peter and Tom will propose the specification as individual authors standards track contribution (after PWG review). If the latter, it will be published as one more IEEE-ISTO standard in the 5100.n series. --------------------------- According to [coll], the "document-overrides" (collection) attribute MAY be supplied by the client in a Send-Document or Send-URI request as an Operation attribute to apply document overrides to this and/or subsequent documents in the job. See the "document-overrides" Job Template attribute in Table 3 for the listing of the member attributes. However, with the introduction of the Document object, the "document-overrides" (collection) attribute SHOULD NOT be used (either as a Job Template attribute or an Operation attribute). Instead, the client simply supplies the Document Template attributes (see Table 3) for each Document Creation request (in a new Document Template attribute group) without needing a collection. ISSUE 02: What do we want to do with the "document-overrides" collection attributes when supporting the Document object, which is no longer needed as either a Job Template, Document Template, or operation attribute in Job and Document Creation requests? --------------------------- Similarly, according to [coll], the "page-overrides" (collection) attribute MAY be supplied by the client in a Send-Document or Send-URI request as an Operation attribute to apply page overrides to this and/or subsequent documents in the job. See the "page-overrides" Job Template attribute in Table 3 for the listing of the member attributes. However, with the introduction of the Document object, the "page-overrides" (collection) attribute SHOULD be more simply supplied as one of the Document Template attributes for this document only. ISSUE 03: What do we want to do with the "page-overrides" collection attributes when supporting the Document object, which is still needed as a Job Template and Document Template attribute for overriding attributes in specified page ranges, but is not needed as an operation attribute on Document Creation requests? --------------------------- ISSUE 04: Is the following query behavior for Job and Document objects OK? Job Template and Document Template attributes are OPTIONAL for a Printer to support and for a client to supply in a Job Creation or Document Creation request or a Document Overrides or Page Overrides. If a Printer supports a Job Template or Document Template attribute, then it MUST copy the supplied attribute to the Job or Document object, respectively so that a client MAY query the attributes in subsequent Get-Job-Attributes/Get-Jobs and Get-Document-Attributes/Get-Documents operations, respectively. The effect of Job Template Attributes supplied in Job Creation requests are inherited by the Document objects, unless the Document Creation operation supplies the attribute with a different value. However, the Printer MUST NOT propagate Job Template attributes supplied in Job Creation operations to the Document object. Similarly, the Printer MUST NOT promote Document Template attributes up to the Job object when no corresponding Job Template attribute was supplied in the Job Creation operation. Thus the Printer returns in queries only Job Template and Document Template attributes that were actually supplied by a client. --------------------------- [job-] indicates an attribute that shouldn't have had a "job-" prefix in its name in [RFC2911], so that the same attribute could also apply to the Document object as a Document Description attribute. Note: For the PWG Semantic Model, the "job-" prefix is proposed to be dropped. ISSUE 05: Should we sort the attributes ignoring the [job-]? Current the "job-" is used in the sort for attributes. ISSUE 06: How will we register these attributes with IANA, since they will be registered for IPP use, with the "job-" prefix. Do we add the ones without "job-" as aliases to the IANA registry as is done for charset registrations? --------------------------- [job-] indicates a state reason keyword value that shouldn't have had a "job-" prefix in its name in [RFC2911], so that the same value could also apply at the Document level as a "document-state-reasons" attribute value. Note: For the PWG Semantic Model, the "job-" prefix will be dropped. For purposes of sorting in Table 6, the "[job-]" prefix is ignored, since the PWG Semantic Model name is proposed without the prefix. ISSUE 07: Should we sort the attributes values including the [job-]? Currently the "job-" is ignored in the sort for attribute values. ISSUE 08: How will we register these attribute values with IANA, since they will be registered for IPP use, with the "job-" prefix. Do we add the ones without "job-" as aliases to the IANA registry as is done for charset registrations? --------------------------- TBD - one to list the Document Template keyword attribute names supported. ISSUE 09: What other Printer Description attributes are needed, if any? Send comments to the mailing lists. Thanks, Tom From hastings at cp10.es.xerox.com Mon Aug 26 01:46:48 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Errata for PWG IEEE-ISTO 5100.3 Internet Printing Protocol (IPP): Production Printing Attributes - Set1, February 12, 2001 Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908070357@x-crt-es-ms1.cp10.es.xerox.com> Harry, I've down loaded errata to PWG IEEE-ISTO 5100.3 Internet Printing Protocol (IPP): Production Printing Attributes - Set1, February 12, 2001 at: ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg5100.3-with-errata-020825.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg5100.3-with-errata-020825.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg5100.3-with-errata-020825.rtf I put it in /pub/pwg/ipp/new_PPE/, instead of /pub/pwg/standards/ until we agree how to post and name a PWG document with errata. Please consider these questions at the PWG Plenary meeting: 1. I believe that we agreed that Errata would be handled by putting the updated document in the same directory with the approved PWG standards, right? 2. Should it have the same file name as the original, i.e., /pwg5100.3.pdf, or do we want to put the date in the file name too, i.e., pwg5100.3-2002-08-05.pdf? 3. Certainly we want the web page to point to the new version. 4. Do we want that new version to have the revision marks? 5. Or do we want to just have the one with revision marks in /pub/pwg/ipp/new_PPE/ and the clean version in /pub/pwg/standards/? 6. Also I should update to use the IEEE-ISTO template that Ron used for 5101.1 Media Names Standard, right? I've included the FSG OpenPrinting WG Capabilities WG, since the errata has to do with making it clearer the 23 "xxx-supported" and 1 "xxx-default" Printer attributes that describe the supported values for member attributes of collection Job Template attributes. Also the FSG OpenPrinting WG Spooling WG that is doing the PAPI. The following errata have been included with revision marks: 1. Several people have missed the 23 "xxx-supported" and 1 "xxx-default" Printer attributes that are defined in running text without any heading to set the attribute off or to put it into the Table of Contents. These are Printer attributes that have corresponding "xxx" member attributes of Job Template collection attributes. These attributes are neither Job Template attributes nor Printer Description attributes; they are just plain Printer attributes (according to [ipp-coll[). So I added headings for the description of each xxx-supported attribute that didn't have a heading. You can see the 24 attribute headings added in the Table Of Contents with revision marks. 2. Section 3.13.5.1 Added a parenthesis that didn't have matching parenthesis. 3. Section 3.14 media-input-tray-check - add the 'none' keyword so that the client can override the default. 4. Section 3.14 media-input-tray-check - corrected a cross reference. 5. Section 3.15.1 and Section 4.1 - Removed the "order" in the reference to "page-order-delivery" attribute name, since the correct name of the attribute as defined in section 3.15 is "page-delivery". (A related attribute is named: "page-order-received", which explains why "-order-" was incorrectly inserted in some occurrences of the attribute name). 6. Section 8.1 IANA Considerations - added all the 24 Printer attributes that weren't in the Table of Contents to be registered with IANA. Tom From papowell at astart.com Wed Aug 28 06:34:42 2002 From: papowell at astart.com (Patrick Powell) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.4 In-Reply-To: <3D592E83.6060809@easysw.com> Message-ID: <200208281334.g7SDYgO93712@h110.private> Michael Sweet wrote: I agree with Mr. Sweet on the need for independence. Comment: I think that based on the current discussions we will probably end up with three 'payload' formats: PostScript PDF PCL (text is a subset of PCL) > Adding printer open and close calls to an interface that is > inherently based on communications with a server (whether that > "server" handles multiple printers or not) isn't going to provide > anything other than overhead. It might be useful to provide > functions to enumerate the available servers/services which the > application can choose from, however I really don't think we > want explicit per-printer connections for the purpose of > communicating with the printer driver, since that boxes us into > a single printing system/printer driver architecture. Ummm... I can see one place where this would be necessary, which is in the case of requiring a 'secure' connection to the underlying facilities or when you need to maintain 'state'. I hesitate to say this, but the lack of 'state' was one of the curses of the NFS and HTTP protocols, and the addition of SSL did nothing to simplify the problems of HTTP (talk to anybody about SSL + HTTP load balancing and get ready for a real rant and froth session :-). > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > Patrick Powell Astart Technologies papowell@astart.com 6741 Convoy Court Network and System San Diego, CA 92111 Consulting 858-874-6543 FAX 858-751-2435 LPRng - Print Spooler (http://www.lprng.com) From mike at easysw.com Wed Aug 28 08:18:42 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.4 References: <200208281334.g7SDYgO93712@h110.private> Message-ID: <3D6CE9D2.3040301@easysw.com> Patrick Powell wrote: > Michael Sweet wrote: > > > I agree with Mr. Sweet on the need for independence. > > Comment: I think that based on the current discussions > we will probably end up with three 'payload' formats: > PostScript > PDF > PCL (text is a subset of PCL) > > >>Adding printer open and close calls to an interface that is >>inherently based on communications with a server (whether that >>"server" handles multiple printers or not) isn't going to provide >>anything other than overhead. It might be useful to provide >>functions to enumerate the available servers/services which the >>application can choose from, however I really don't think we >>want explicit per-printer connections for the purpose of >>communicating with the printer driver, since that boxes us into >>a single printing system/printer driver architecture. > > > Ummm... I can see one place where this would be necessary, > which is in the case of requiring a 'secure' connection > to the underlying facilities or when you need to maintain > 'state'. I hesitate to say this, but the lack of 'state' > ... But there the service object can be used to provide the persistant state info... Certainly that is how a CUPS-based PAPI implementation will do it, since CUPS/IPP runs over HTTP with TLS or SSL. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Fri Aug 30 04:38:06 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Message-ID: I have been incorporating comments on PAPI 0.4 into a new PAPI 0.5 version. I have many changes and new functions included, but I also have a fairly long list of items that have been discussed here that have had no obvious consensus emerge. I'm afraid we might be running up against a variation of the the "80/20 rule" here: getting consensus on the last 20% of the issues will take 80% of the time. I think there would be real value in putting a stake in the ground so that implementations of PAPI can be made available, people can start actually using it, and we can get some real-world feedback on it. Otherwise, we risk continuing to iterate on the spec and have no real implementations made available. Further, if we continue to add function in the first PAPI spec which no current print server (or only one or two propriety servers) supports, then when it finally does come out and almost all implementations return "unsupported function" in a variety of places we will risk alienating the potential users of it. Therefore, I am proposing that I send out PAPI 0.5 as it exists now, and designate September 20, 2002 as the cut-off for "functional enhancement requests". After September 20, I will incorporate enhancements on which a consensus has been reached and then issue PAPI 0.6, which will be a draft of a "functionally frozen" 1.0 spec. That is, we will continue to accept corrections, wording enhancements, etc. until October 18, 2002 but would NOT incorporate any suggestions for new function. After October 18 we will incorporate the comments and publish it as the 1.0 spec and quickly make implementation(s) available. Then we begin work on a new PAPI 2.0 draft that would include the currently unresolved "functional enhancements" being discussed, and the results of developer feedback that we get on 1.0. The drawback of this is that we have to worry about backward compatibility as we add function in 2.0, but I feel this is outweighed by the benefit of getting something finalized and implementations out there for real developers to use. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020830/cdb1fb3d/attachment.htm From imcdonald at sharplabs.com Fri Aug 30 10:04:31 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD75@mailsrvnt02.enet.sharplabs.com> Hi Alan, I support your idea of freezing at the current concensus and releasing an initial version as PAPI 1.0. As long as backward compatibility only arises for new functions and _not_ broken previous API functions/parameters, I see nothing wrong with a future PAPI 2.0. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, August 30, 2002 7:38 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI 1.0 "Function Freeze" I have been incorporating comments on PAPI 0.4 into a new PAPI 0.5 version. I have many changes and new functions included, but I also have a fairly long list of items that have been discussed here that have had no obvious consensus emerge. I'm afraid we might be running up against a variation of the the "80/20 rule" here: getting consensus on the last 20% of the issues will take 80% of the time. I think there would be real value in putting a stake in the ground so that implementations of PAPI can be made available, people can start actually using it, and we can get some real-world feedback on it. Otherwise, we risk continuing to iterate on the spec and have no real implementations made available. Further, if we continue to add function in the first PAPI spec which no current print server (or only one or two propriety servers) supports, then when it finally does come out and almost all implementations return "unsupported function" in a variety of places we will risk alienating the potential users of it. Therefore, I am proposing that I send out PAPI 0.5 as it exists now, and designate September 20, 2002 as the cut-off for "functional enhancement requests". After September 20, I will incorporate enhancements on which a consensus has been reached and then issue PAPI 0.6, which will be a draft of a "functionally frozen" 1.0 spec. That is, we will continue to accept corrections, wording enhancements, etc. until October 18, 2002 but would NOT incorporate any suggestions for new function. After October 18 we will incorporate the comments and publish it as the 1.0 spec and quickly make implementation(s) available. Then we begin work on a new PAPI 2.0 draft that would include the currently unresolved "functional enhancements" being discussed, and the results of developer feedback that we get on 1.0. The drawback of this is that we have to worry about backward compatibility as we add function in 2.0, but I feel this is outweighed by the benefit of getting something finalized and implementations out there for real developers to use. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hlava at us.ibm.com Fri Aug 30 12:17:50 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.5.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy to Shawn for inclusion on the web page. As I said in my earlier note, I would like to open this version for functional enhancement requests only until September 20, 2002. After that, we'll issue another draft for final corrections before coming out with 1.0. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020830/590cd4c8/attachment.htm From kugler at us.ibm.com Fri Aug 30 15:32:32 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 Message-ID: What character set are you assuming for your "char*" variables and fields? How will you deal with multi-byte characters in things like job-name (for example, if a Japanese user prints a document named something like "???????.txt" (assume there are Japanese characters in that string)? -Carl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020830/445967a0/attachment.htm From mike at easysw.com Fri Aug 30 16:28:28 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 References: Message-ID: <3D6FFF9C.9080400@easysw.com> Carl Kugler wrote: > > What character set are you assuming for your "char*" variables and > fields? How will you deal with multi-byte characters in things like > job-name (for example, if a Japanese user prints a document named > something like "???????.txt" (assume there are Japanese > characters in that string)? All strings are UTF-8 (or at least that's the way it is in CUPS...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From kugler at us.ibm.com Fri Aug 30 17:18:51 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 Message-ID: Maybe that should go in the spec. -Carl Mike Sweet Sent by: printing-spool-admin@freestandards.org 08/30/2002 05:28 PM Please respond to printing-spool To: printing-spool@freestandards.org cc: Subject: Re: [printing-spool] PAPI V0.5 Carl Kugler wrote: > > What character set are you assuming for your "char*" variables and > fields? How will you deal with multi-byte characters in things like > job-name (for example, if a Japanese user prints a document named > something like "???????.txt" (assume there are Japanese > characters in that string)? All strings are UTF-8 (or at least that's the way it is in CUPS...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020830/47916853/attachment.htm From imcdonald at sharplabs.com Sun Sep 1 12:06:37 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 Message-ID: <116DB56CD7DED511BC7800508B2CA53735CD77@mailsrvnt02.enet.sharplabs.com> Hi, I agree with Carl Kugler that the PAPI spec should explicitly require the use of UTF-8. In the (related) FSG Job Ticket API, we have required that all implementations of the JTAPI MUST support UTF-8 and MAY support other charsets, with an explicit parameter. Also Job Tickets themselves (in files or wherever), MUST support UTF-8 (or the strict US-ASCII subset) and MAY support other charsets. If they are XML-encoded they MUST use the charset internal parameter to clearly label any non-UTF-8 content. Cheers, - Ira McDonald PS - The datatype 'char *' _can_ cause problems with UTF-8 (because 'char' may be signed or unsigned), since UTF-8 is inherently unsigned. API functions need to (in C) 'cast' the 'char *' to 'unsigned char *' internally, for correct behavior. -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Friday, August 30, 2002 7:28 PM To: printing-spool@freestandards.org Subject: Re: [printing-spool] PAPI V0.5 Carl Kugler wrote: > > What character set are you assuming for your "char*" variables and > fields? How will you deal with multi-byte characters in things like > job-name (for example, if a Japanese user prints a document named > something like "???????.txt" (assume there are Japanese > characters in that string)? All strings are UTF-8 (or at least that's the way it is in CUPS...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From shawn_pratt at hp.com Tue Sep 3 06:49:53 2002 From: shawn_pratt at hp.com (PRATT,SHAWN (HP-Boise,ex1)) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] RE: printing-spool digest, Vol 1 #45 - 1 msg Message-ID: Alan: This is an excellent example of the roadmap we need to create for the OpenPrinting roadmaps. I can interpret this into: PAPI: Draft 0.5 review : 9/1/02 - 9/20/02 Draft 0.6 release (Proposed PAPI 1.0) : 9/22/02 Draft 0.6 review (Proposed PAPI 1.0) : 9/22/02 - 10/18/02 Version 1.0 - Finalized : 10/20/02 Reference model of PAPI, Ver 1.0) : ?? Draft 2.0 release : ?? Draft 2.0 review : ?? A couple of things that still needs to be noted before Version 1.0 is finalized: 1. Has this been reviewed by the other task groups to ensure it meets their needs? We do not want to risk putting out a final spec that none of the rest of the print system is willing to support. 2. To get a spec finalized it needs to be presented to the OpenPrinting steering committee. We have not had one yet - the weekly meetings are the America/European Regional meetings. I can get one organized once you believe you are ready to present the information. By doing this, you will get feedback and commitment from the complete group working in the OpenPrinting efforts. This includes the different print vendors, distros and open source community members as well as the FSG standards group. - Shawn Pratt -----Original Message----- Message: 1 To: printing-spool@freestandards.org From: "Alan Hlava" Date: Fri, 30 Aug 2002 05:38:06 -0600 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Reply-To: printing-spool@freestandards.org This is a multipart message in MIME format. --=_alternative 003FE8AB87256C25_= Content-Type: text/plain; charset="us-ascii" I have been incorporating comments on PAPI 0.4 into a new PAPI 0.5 version. I have many changes and new functions included, but I also have a fairly long list of items that have been discussed here that have had no obvious consensus emerge. I'm afraid we might be running up against a variation of the the "80/20 rule" here: getting consensus on the last 20% of the issues will take 80% of the time. I think there would be real value in putting a stake in the ground so that implementations of PAPI can be made available, people can start actually using it, and we can get some real-world feedback on it. Otherwise, we risk continuing to iterate on the spec and have no real implementations made available. Further, if we continue to add function in the first PAPI spec which no current print server (or only one or two propriety servers) supports, then when it finally does come out and almost all implementations return "unsupported function" in a variety of places we will risk alienating the potential users of it. Therefore, I am proposing that I send out PAPI 0.5 as it exists now, and designate September 20, 2002 as the cut-off for "functional enhancement requests". After September 20, I will incorporate enhancements on which a consensus has been reached and then issue PAPI 0.6, which will be a draft of a "functionally frozen" 1.0 spec. That is, we will continue to accept corrections, wording enhancements, etc. until October 18, 2002 but would NOT incorporate any suggestions for new function. After October 18 we will incorporate the comments and publish it as the 1.0 spec and quickly make implementation(s) available. Then we begin work on a new PAPI 2.0 draft that would include the currently unresolved "functional enhancements" being discussed, and the results of developer feedback that we get on 1.0. The drawback of this is that we have to worry about backward compatibility as we add function in 2.0, but I feel this is outweighed by the benefit of getting something finalized and implementations out there for real developers to use. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hlava at us.ibm.com Tue Sep 3 13:01:55 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] RE: printing-spool digest, Vol 1 #45 - 1 msg Message-ID: On Tuesday, 09/03/2002 at 09:49 AST, "PRATT,SHAWN (HP-Boise,ex1)" wrote: > 1. Has this been reviewed by the other task groups to ensure it meets their > needs? We do not want to risk putting out a final spec that none of the > rest of the print system is willing to support. I guess I've been assuming that the other task groups subscribe to the printing-spool mailing list if they feel their work is related. Is this not correct? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020903/aed9e40f/attachment.htm From hastings at cp10.es.xerox.com Tue Sep 3 13:59:48 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664575@x-crt-es-ms1.cp10.es.xerox.com> Alan, Next time it would be good to create the document with Acrobat Distiller, instead of PDF Writer, so that the TOC and cross-references are hot. If you don't have Acrobat Distiller, I'd be glad to help. Thanks for including a Change History. Here it is: Version 0.5 (August 30, 2002) 3876 * Added job_attrs argument to papiPrinterQuery to support more accurate query of printer capabilities. * Added management functions papiAttributeDelete, papiJobModify, and papiPrinterModify. * Added functions papiAttributeListGetValue, papiAttributeListGetString, papiAttributeListGetInteger, etc. * Renamed papiAttributeAdd* functions to papiAttributeListAdd* to be consistent with the naming convention (first word after "papi" is the object being operated upon). * Changed last argument of papiAttributeListAdd to papi_attribute_value_t*. * Made description of authentication more implementation-independent. * Added reference to IPP attributes summary document. * Added result argument to papiPrinterPurgeJobs. * Added "collection attribute" support (PAPI_COLLECTION type). * Changed boolean values to consistently use char. Added PAPI_FALSE and PAPI_TRUE enum values. 3893 Tom -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, August 30, 2002 04:38 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI 1.0 "Function Freeze" I have been incorporating comments on PAPI 0.4 into a new PAPI 0.5 version. I have many changes and new functions included, but I also have a fairly long list of items that have been discussed here that have had no obvious consensus emerge. I'm afraid we might be running up against a variation of the the "80/20 rule" here: getting consensus on the last 20% of the issues will take 80% of the time. I think there would be real value in putting a stake in the ground so that implementations of PAPI can be made available, people can start actually using it, and we can get some real-world feedback on it. Otherwise, we risk continuing to iterate on the spec and have no real implementations made available. Further, if we continue to add function in the first PAPI spec which no current print server (or only one or two propriety servers) supports, then when it finally does come out and almost all implementations return "unsupported function" in a variety of places we will risk alienating the potential users of it. Therefore, I am proposing that I send out PAPI 0.5 as it exists now, and designate September 20, 2002 as the cut-off for "functional enhancement requests". After September 20, I will incorporate enhancements on which a consensus has been reached and then issue PAPI 0.6, which will be a draft of a "functionally frozen" 1.0 spec. That is, we will continue to accept corrections, wording enhancements, etc. until October 18, 2002 but would NOT incorporate any suggestions for new function. After October 18 we will incorporate the comments and publish it as the 1.0 spec and quickly make implementation(s) available. Then we begin work on a new PAPI 2.0 draft that would include the currently unresolved "functional enhancements" being discussed, and the results of developer feedback that we get on 1.0. The drawback of this is that we have to worry about backward compatibility as we add function in 2.0, but I feel this is outweighed by the benefit of getting something finalized and implementations out there for real developers to use. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020903/fcd62089/attachment.htm From hlava at us.ibm.com Wed Sep 4 04:48:33 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Message-ID: On Tuesday, 09/03/2002 at 01:59 MST, "Hastings, Tom N" wrote: > Next time it would be good to create the document with Acrobat Distiller, > instead of PDF Writer, so that the TOC and cross-references are hot. If you > don't have Acrobat Distiller, I'd be glad to help. I am using Acrobat Distiller to generate the PDF. Can you explain what you mean by "so that the TOC and cross-references are hot"? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020904/201ff648/attachment.htm From mike at easysw.com Wed Sep 4 07:47:38 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" References: Message-ID: <3D761D0A.6040909@easysw.com> Alan Hlava wrote: > > On Tuesday, 09/03/2002 at 01:59 MST, "Hastings, Tom N" > wrote: > > Next time it would be good to create the document with Acrobat > Distiller, > > instead of PDF Writer, so that the TOC and cross-references are > hot. If you > > don't have Acrobat Distiller, I'd be glad to help. > I am using Acrobat Distiller to generate the PDF. Can you explain what > you mean by > "so that the TOC and cross-references are hot"? So that you can click on a TOC entry to go to the specific section... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From shawn_pratt at hp.com Wed Sep 4 07:49:47 2002 From: shawn_pratt at hp.com (PRATT,SHAWN (HP-Boise,ex1)) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] RE: printing-spool digest, Vol 1 #48 - 4 msgs Message-ID: I would agree that is it is very important that each of the task groups are subscribing and paying attention to discussions going on in dependent/related task work. I would also hope that as you make changes that these are being reflected elsewhere. To me the steering committee decision is mainly a rubber stamp as long as the above communication is occuring. However, it is a needed step to ensure correct movement forward on a standard definition. In essense, when version 1.0 of the PAPI comes out, we are stating this is the OpenPrinting standard around the print API for applications to use. Since this could affect a greater audience, the FSG requires some formal processes for validating and stamping these decisions. I can help you with the process when it is ready to go for formalization. - Shawn Pratt -----Original Message----- --__--__-- Message: 2 To: printing-spool@freestandards.org Subject: Re: [printing-spool] RE: printing-spool digest, Vol 1 #45 - 1 msg From: "Alan Hlava" Date: Tue, 3 Sep 2002 14:01:55 -0600 Reply-To: printing-spool@freestandards.org This is a multipart message in MIME format. --=_alternative 006E06DB87256C29_= Content-Type: text/plain; charset="us-ascii" On Tuesday, 09/03/2002 at 09:49 AST, "PRATT,SHAWN (HP-Boise,ex1)" wrote: > 1. Has this been reviewed by the other task groups to ensure it meets their > needs? We do not want to risk putting out a final spec that none of > the rest of the print system is willing to support. I guess I've been assuming that the other task groups subscribe to the printing-spool mailing list if they feel their work is related. Is this not correct? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hlava at us.ibm.com Wed Sep 4 08:11:11 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" Message-ID: On Wednesday, 09/04/2002 at 10:47 AST, Michael Sweet wrote: > So that you can click on a TOC entry to go to the specific section... What Acrobat Distiller setting/option do I need to set to make this happen? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020904/2208a85a/attachment.htm From mike at easysw.com Wed Sep 4 08:20:55 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 1.0 "Function Freeze" References: Message-ID: <3D7624D7.3080704@easysw.com> Alan Hlava wrote: > > On Wednesday, 09/04/2002 at 10:47 AST, Michael Sweet > wrote: > > So that you can click on a TOC entry to go to the specific section... > What Acrobat Distiller setting/option do I need to set to make this happen? It depends on how you are generating the document. If you generate from SGML, make sure that the output PostScript is including the appropriate distiller commands to embed the links. If you generate from Word, it might just be a matter of choosing an option in the print dialog (I dunno about either, since I don't use them anymore) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Thu Sep 12 09:47:43 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Agenda for Spool PAPI OpenPrinting meeting, Fri, 9/13 Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F9086648F3@x-crt-es-ms1.cp10.es.xerox.com> We're going to hold a final telecon on the PAPI spec in order to meet the functional enhancement request date of September 20 suggested by Alan. The call-in number is the same as other FSG calls: Phone/Passcode: * Dial-in : 816.650.0688 * passcode : 9 6 4 6 2 8 Time: 8-9 am PDT, 9-10 am MDT, 11-12 pm EDT. Agenda: 1. Discuss the PAPI handling of multiple documents and how it relates to the JT API. 2. Any changes or comments on the PAPI V0.5 spec to reach feature freeze? We came up with an issue at General meeting Thursday, about the relationship between the PAPI and the JT API about multiple files versus multiple documents. Background: The papi_attributes parameter currently contains an array of attributes for the job level as a whole. IPP does have a Job Template attribute to specify attributes for particular documents (and document ranges), called "document-overrides". Its a collection attribute which includes ranges of document numbers to which the other attributes in the collection are to override the attribute supplied at the job level. See the IPP Collection specification. However, there is a new effort in the PWG to formally add a Document object to IPP. The PWG Semantic Model already has a Document object and the "document-overrides" attribute is deprecated in favor of passing Document attributes with the Document object, instead of at the Job level. In IPP and PWG, there is a separate action to create Documents from the JobCreate action;, namely SendDocument and SendURI (for print-by-reference). However, in the PAPI, the papiJobSubmit has a single call to submit the entire Job with all of the attributes in one array and a second parameter which is the array of file names, which could be considered as separate documents or could be considered as being concatenated together as a single Output Document. Long term Alan H suggested that the PAPI could add another function call to add a Document. However, we need to think how that extension would interact with what we currently have in PAPI v0.5. Will we regret something we have now? For example, an implementor who wants to per-document attributes will have to use the "document-overrides" attribute with V0.5. In the future, when we add the Document Object call, we'd want to deprecate the "document-overrides" attribute, right? The PWG Semantic Model 0.9 is available at: ftp://ftp.pwg.org/pub/pwg/Semantic-Model/PWG-Semantic-Model.pdf The IPP Document Object spec, version 0.3: is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.pdf On the other hand, the JT API object modeling work does have a document object and a job object. So that in the JT API a single Job Ticket can supply attributes that apply to the Job as a whole and can have separate attributes that are supplied for each Document (with the same or different values). So the JT API has all of the Job and Document Semantics that will eventually be available also in the Attributes part of the interface. For JT API, we need to see how the Document Object in the JT API relates to the array of files in the PAPI interface. The V0.5 papiSubmitJob interface is: Syntax: papi_status_t papiJobSubmit( papi_service_t handle, const char* printer_name, const papi_attribute_t** job_attributes, const papi_job_ticket_t* job_ticket, const char** file_names, papi_job_t* job ); Inputs: handle Handle to the print service to use. printer_name Pointer to the name of the printer to which the job is to be submitted. job_attributes (optional) The list of attributes describing the job and how it is to be printed. If options are specified here and also in the job ticket data, the value specified here takes precedence. If this is NULL then only default attributes and (optionally) a job ticket is submitted with the job. job_ticket (optional) Pointer to structure specifying the job ticket. If this argument is NULL, then no job ticket is used with the job. file_names NULL terminated list of pointers to names of files to print. Outputs: job The resulting job object representing the submitted job. -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, August 30, 2002 12:18 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI V0.5 At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.5.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy to Shawn for inclusion on the web page. As I said in my earlier note, I would like to open this version for functional enhancement requests only until September 20, 2002. After that, we'll issue another draft for final corrections before coming out with 1.0. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020912/227e7434/attachment.htm From hastings at cp10.es.xerox.com Tue Sep 17 13:22:20 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [my initial editorial comments] Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664AA2@x-crt-es-ms1.cp10.es.xerox.com> Alan, Mike, and Norm, Here are my initial editorial comments on Draft V0.5. The spec is coming along nicely. I like having examples of each function too. By editorial comments I mean ones that don't change implementation, but make the spec more understandable and more likely that two implementations will have the same behavior as seen from the same application program. Any substantive comments I'll put into separate email message. 1. General. There should be a References section at the end of the document. Then in section 2.2 Model that references RFC 2911 for the first time, refer to the References section for additional IPP specification extensions to the Model. In addition to RFC 2911, the References section should contain the following specifications that have been approved by the IPP WG group either to be IETF standards or PWG standards. You can cut and paste the following list from the end of the IPP-Object-Attributes that I posted and that PAPI Section 9 refers to. The [get-method] spec is trying to close IPP WG Last Call, and will be soon: Appendix A: References A.1 IPP Documents The web page for access to all the IPP documents is: http://www.pwg.org/ipp/index.html The following documents comprise the Semantics of IPP: Three of them have just been assigned RFC numbers as shown as will be published shortly: [RFC3382] formerly: [coll] deBry, R., Hastings, T., Herriot, R., Ocke, K., and P. Zehler, "Internet Printing Protocol (IPP): The 'collection' attribute syntax", RFC 3382, September 2002. [get-method] Herriot, R., and T. Hastings, "Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications", , June 27, 2002. [RFC3381] formerly: [job-prog] Hastings, T., Lewis, H., and R. Bergman, "Internet Printing Protocol (IPP): Job Progress Attributes", RFC 3381, September 2002. [ntfy] Herriot, R., Hastings, T., Shepherd, M., deBry, R., Isaacson, S., Martin, J., and R. Bergman, "Internet Printing Protocol/1.1: Event Notifications and Subscriptions", , November 19, 2001. [ops-set2] Kugler, C, Hastings, T., Lewis, H., "Internet Printing Protocol (IPP): Job and Printer Administrative Operations", , July 17, 2001. [output-bin] Hastings, T., and R. Bergman, "Internet Printing Protocol (IPP): output-bin attribute extension", IEEE-ISTO 5100.2-2001, February 7, 2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.2.pdf. [override] Herriot, R., Ocke, K., "Internet Printing Protocol (IPP): Override Attributes for Documents and Pages", IEEE-ISTO 5100.4-2001, February 7, 2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.4.pdf. [prod-print] Ocke, K., Hastings, T., "Internet Printing Protocol (IPP): Production Printing Attributes - Set1", IEEE-ISTO 5100.3-2001, February 12, 2001, ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf. [RFC3380] formerly: [set-ops] Hastings, T., Herriot, R., Kugler, C., and H. Lewis, "Internet Printing Protocol (IPP): Job and Printer Set Operations", RFC 3380, September 2002. [rfc2911] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000. A.2 Job Definition Format (JDF) documents The web site for JDF is: www.cip4.org . [jdf] Job Definition Format (JDF), version 1.1, April 30, 2002. http://www.cip4.org/documents/jdf_specifications/index.html A.3 The PWG Semantic Model documents and schemas are available at: [PWGSemMod] PWG Semantic Model, ftp://ftp.pwg.org/pub/pwg/Semantic_model/ 3. I think it would be good to point to the relevant specifications for the complete semantics more specifically, rather than the reader having to find which document the semantics are explained. Perhaps a blanket statement that unless specified otherwise, the semantics are specified in RFC 2911. Examples where explicit references should be made to the appropriate document: a. Section 3.3, line 233, that introduce the 'collection' data type, there should be a reference to [RFC3382]. b. Section 5.4, line 1343, papiPrinterModify should have a reference to [RFC3380] which defines the Set-Printer-Attributes operation. SUGGESTION: You might want to consider renaming this function to papiPrinterSetAttributes to follow the pattern that you have for other PAPI operations that have direct IPP counterparts. c. Section 7.4, line 3150, papiJobModify should have a reference to [RFC3380] which defines the Set-Job-Attributes operation. SUGGESTION: You might want to consider renaming this function to papiJobSetAttributes to follow the pattern that you have for other PAPI operations that have direct IPP counterparts. 4. Section 3.3 Attributes and Values, line 236, ISSUE: Are other types needed to support the newer IPP "collection" attrs? Happily, I don't think that there are any additional types needed, since collection is just a recursion to a set of attributes. 5. Section 3.6 Job Ticket, lines 307-310, says: This is the structure used to pass a job ticket when submitting a print job. Currently, Job Definition Format (JDF) is the only supported job ticket format. JDF is an XML-based job ticket syntax. The JDF specification can be found at www.cip4.org . There are many ways that JDF can be used as a Job Ticket, so that we need to have a way to say which subset of JDF is being used. One that is being worked on by myself and Claudia Alimpich in the CIP4 Digital Printing WG is one that uses the DigitalPrinting process as a combined node with a specific list of other JDF processes. We definitely need to support this subset of JDF. There is also a Job Ticket that will come out of the PWG Semantic Model. Its not approved, but I think it would be good to have a reference to it as a work in progress. Currently, it doesn't yet have a place on the PWG Web page, but that should come soon. The URL for where PWG Semantic documents are stored is: ftp://ftp.pwg.org/pub/pwg/Semantic_model/ and the PWG web site is: http://www.pwg.org and the PWG Semantic Model is one of the PWG projects with the web page: http://www.pwg.org/sm/index.html More later... Tom -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, August 30, 2002 12:18 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI V0.5 At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.5.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy to Shawn for inclusion on the web page. As I said in my earlier note, I would like to open this version for functional enhancement requests only until September 20, 2002. After that, we'll issue another draft for final corrections before coming out with 1.0. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020917/bd7b9a6a/attachment.htm From hastings at cp10.es.xerox.com Tue Sep 17 14:08:38 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [ISSUE: how are IPP enums represen ted in PAPI?] Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664ABA@x-crt-es-ms1.cp10.es.xerox.com> Alan, Michael, and Norm, How are the IPP attributes that have the attribute syntax of enum represented in PAPI? We need to clarify this. For the PWG Semantic model which is XML influenced, we've taken each enum symbol that is also defined in the IPP Model and Semantics document and defined them as the keyword values for the attribute, instead of using the integer value. Using this same unification approach for PAPI would give a more consistent PAPI attributes interface, since only the string type is used for keyword attributes and enum attributes. And the PAPI_INTEGER type is used only for numeric values. However, this unification does require an implementation of the PAPI which is going out to an IPP Printer to have a map from enum symbol keywords to the integer values. And if the attribute is extended, such as the "finishings" (1setOf enum), then the mapping may not be complete. Alternatively, you could say that the actual integer enum value is passed using the PAPI_INTEGER value of papi_attribute_value_type_t. That has the advantage of not requiring a PAPI implementation to have an enum symbol keyword to integer value mapping when the implementation supports the IPP protocol. However, passing a value, say, of "finishing" = integer 20 to get 'staple-top-left' is rather opaque and means that the PAPI attributes are more IPP specific. Many of the IPP WG have come to regret the use of enums. Which way should the PAPI spec be clarified? Perhaps in Chapter 9? BTW, here are ALL of the IPP enum attributes, so we are only talking about 7 attributes in RFC 2911 and 2 extension attributes that use the 'enum' attribute syntax: 7 RFC 2911 attributes with enum attribute syntax: 3.1.6.1 status-code (type2 enum) 4.2.6 finishings (1setOf type2 enum) 4.2.10 orientation-requested (type2 enum) 4.2.13 print-quality (type2 enum) 4.3.7 job-state (type1 enum) 4.4.11 printer-state (type1 enum) 4.4.15 operations-supported (1setOf type2 enum) and for all the IPP extensions, we've shied away from using enum type mostly and have only defined 2 more: job-collation-type (type2 enum) notify-status-code (type2 enum) Tom -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, August 30, 2002 12:18 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI V0.5 At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.5.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy to Shawn for inclusion on the web page. As I said in my earlier note, I would like to open this version for functional enhancement requests only until September 20, 2002. After that, we'll issue another draft for final corrections before coming out with 1.0. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020917/fa02003d/attachment.htm From mike at easysw.com Tue Sep 17 15:14:29 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [ISSUE: how are IPP enums represen ted in PAPI?] References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664ABA@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3D87A945.5060705@easysw.com> Hastings, Tom N wrote: > Alan, Michael, and Norm, > > How are the IPP attributes that have the attribute syntax of enum > represented in PAPI? > ... As integers current, same as CUPS, using C enumeration constants that correspond to the IPP enumeration values. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Tue Sep 17 15:39:19 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [ISSUE: how are IPP enums represen ted in PAPI?] Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664AD0@x-crt-es-ms1.cp10.es.xerox.com> Sounds like a fine approach to use C enums for IPP enums. The programmer's gets symbolic values, so its not so cryptic as decimal numbers. It would be worth a clarification in the PAPI spec. Perhaps in Chapter 9 which refers to the list of IPP attributes, we could put the list of IPP attribute syntaxes and show which PAPI data types each uses. How about something like this for Section 9 of PAPI: IPP data types PAPI data types -------------- --------------- text PAPI_STRING name PAPI_STRING keyword PAPI_STRING enum PAPI_INTEGER using c enums uri PAPI_STRING uriScheme PAPI_STRING charset PAPI_STRING naturalLanguage PAPI_STRING mimeMediaType PAPI_STRING octetString ??? How are octet strings represented? boolean PAPI_BOOLEAN integer PAPI_INTEGER rangeOfInteger PAPI_RANGE dateTime PAPI_DATETIME resolution PAPI_RESOLUTION collection PAPI_COLLECTION 1setOf X c array OK? Thanks, Tom -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Tuesday, September 17, 2002 15:14 To: printing-spool@freestandards.org Subject: Re: [printing-spool] PAPI V0.5 [ISSUE: how are IPP enums represen ted in PAPI?] Hastings, Tom N wrote: > Alan, Michael, and Norm, > > How are the IPP attributes that have the attribute syntax of enum > represented in PAPI? > ... As integers current, same as CUPS, using C enumeration constants that correspond to the IPP enumeration values. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From mike at easysw.com Wed Sep 18 07:05:14 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [ISSUE: how are IPP enums represen ted in PAPI?] References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908664AD0@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3D88881A.7020003@easysw.com> Hastings, Tom N wrote: > ... > How about something like this for Section 9 of PAPI: > > IPP data types PAPI data types > -------------- --------------- > > text PAPI_STRING > name PAPI_STRING > keyword PAPI_STRING > enum PAPI_INTEGER using c enums > uri PAPI_STRING > uriScheme PAPI_STRING > charset PAPI_STRING > naturalLanguage PAPI_STRING > mimeMediaType PAPI_STRING > octetString ??? How are octet strings represented? In CUPS we currently treat them the same as the other string data types, although that will change in CUPS 1.2 when we support IPP notifications (which actually uses the octetString type) so that octetStrings with nul characters don't cause problems. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Wed Sep 18 13:08:05 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.5 [my initial editorial comments] Message-ID: On Tuesday, 09/17/2002 at 01:22 MST, "Hastings, Tom N" wrote: > a. Section 3.3, line 233, that introduce the 'collection' data type, there > should be a reference to [RFC3382]. ... > b. Section 5.4, line 1343, papiPrinterModify should have a reference to > [RFC3380] which defines the Set-Printer-Attributes operation. ... > c. Section 7.4, line 3150, papiJobModify should have a reference to [RFC3380] > which defines the Set-Job-Attributes operation. I will add RFC3380 to the (new) references appendix, but I'm inclined to NOT add these references throughout. We are walking a fine line trying to use IPP/PWG semantics, but also trying to make the API usable on top of NON-IPP implementations. I think this would cross the line and imply too close of a tie between PAPI and IPP. Furthermore, someone trying to use the PAPI spec as a reference when coding their application might assume that they have to get and understand RFC3380 in order to use the papi*Modify functions, which I certainly hope will not be necessary. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020918/6d57a746/attachment.htm From Norm.Jacobs at Sun.COM Wed Sep 18 13:26:40 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI 0.5 template code Message-ID: <3D88E180.43B16B18@Sun.COM> I have downloaded the beginnings of an implementation of the PAPI spec to the pwg ftp server. The code can be found in a bzip2 compressed tar file (ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi-0.5.tar.bz2) The implementation is based on Draft 0.5 of the spec. It includes a header file, implementation of the attribute interface, and stubbed out implementations of the service, printer, and job interfaces. There is also some sample code that uses some of the interface and helped me in developing a Solaris/lpsched implementation of it. If you are implementing the PAPI, this should at least save you some typing. Last I checked, it built on Solaris and Linux. It currently uses automake, autoconf, and libtool. To extract: $ bzcat (file) | tar xf - To build: $ cd papi-0.5 $ ./autogen.sh (uses autoconf/automake/libtool) $ make all -Norm From hlava at us.ibm.com Fri Sep 20 06:02:26 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.6 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi_v0.6.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy of the HTML version to Shawn for inclusion on the web page. This version of the spec is the candidate for a "functionally frozen" PAPI version 1. Please only make comments on wording, typos, etc. unless there is a significant functional problem or deficiency that would prevent this from being a viable version 1 (in which case, please point this out ASAP!). If there are no major functional problems, we plan to incorporate the wording corrections/enhancements received and issue the candidate V1.0 spec on October 18, 2002. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20020920/8b2e9af6/attachment.htm From hlava at us.ibm.com Fri Oct 4 05:59:52 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021004/4c6ea2f8/attachment.htm From mike at easysw.com Fri Oct 4 07:23:27 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: Message-ID: <3D9DA45F.7090300@easysw.com> Alan Hlava wrote: > > The following PAPI suggestions/questions came up at yesterday's Open > Print conference call: > > 1) Add a statement to the spec that translated strings should be > returned to the caller in the language in which the caller is running. > I agree with this suggestion, but I made it a "should" rather than a > "must" to allow for connecting to a print server that is running in a > different language than the client, and that does not support a > multilingual interface (i.e. it can't return messages in a language > other than the one it's running in). Here is my proposed wording of > this statement: > > "The PAPI interface should return translated strings in the language in > which the caller is running. "Translated strings" includes interface > messages and attribute values containing messages (attribute names are > not translated)." Use the IPP spec as a guide for this - things like the printer-state-message string *may* be translated, but others that list keyword values *must not* be translated (for obvious reasons...) > 2) Add an argument to papiServiceCreate and a service "set" API call to > specify the language in which translated strings are to be returned, > allowing the caller to request messages in a language other than the one > under which it is running. I'm a bit confused about how such an > argument would relate to the IPP attributes-natural-language request > attribute. Perhaps one of the IPP gurus who are on this list could > comment? My own opinion is that papiServiceCreate should use the current locale setting to determine the correct natural-language and charset values; if the app wants things in a different language, then it should use setlocale()... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From kugler at us.ibm.com Fri Oct 4 08:09:49 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: The concept of internationalization is becoming obsolete, replaced by globalization. Some operating systems (e.g., some variants of Windows) can support multiple users each in multiple locales (see http://www.microsoft.com/globaldev/articles/muiapp.asp). They have the concept of a "thread locale" in addition to the "system locale". In designing this API you might want to allow for that possibility coming to your favoriate platform some day. -Carl Michael Sweet Sent by: printing-spool-admin@freestandards.org 10/04/2002 08:23 AM Please respond to printing-spool To: printing-spool@freestandards.org cc: Subject: Re: [printing-spool] PAPI Internationalization Alan Hlava wrote: > > The following PAPI suggestions/questions came up at yesterday's Open > Print conference call: > > 1) Add a statement to the spec that translated strings should be > returned to the caller in the language in which the caller is running. > I agree with this suggestion, but I made it a "should" rather than a > "must" to allow for connecting to a print server that is running in a > different language than the client, and that does not support a > multilingual interface (i.e. it can't return messages in a language > other than the one it's running in). Here is my proposed wording of > this statement: > > "The PAPI interface should return translated strings in the language in > which the caller is running. "Translated strings" includes interface > messages and attribute values containing messages (attribute names are > not translated)." Use the IPP spec as a guide for this - things like the printer-state-message string *may* be translated, but others that list keyword values *must not* be translated (for obvious reasons...) > 2) Add an argument to papiServiceCreate and a service "set" API call to > specify the language in which translated strings are to be returned, > allowing the caller to request messages in a language other than the one > under which it is running. I'm a bit confused about how such an > argument would relate to the IPP attributes-natural-language request > attribute. Perhaps one of the IPP gurus who are on this list could > comment? My own opinion is that papiServiceCreate should use the current locale setting to determine the correct natural-language and charset values; if the app wants things in a different language, then it should use setlocale()... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021004/8d659619/attachment.htm From mike at easysw.com Fri Oct 4 08:26:19 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: Message-ID: <3D9DB31B.90201@easysw.com> Carl Kugler wrote: > > The concept of internationalization is becoming obsolete, replaced by > globalization. Some operating systems (e.g., some variants of Windows) > can support multiple users each in multiple locales (see > http://www.microsoft.com/globaldev/articles/muiapp.asp). They have the > concept of a "thread locale" in addition to the "system locale". In > designing this API you might want to allow for that possibility coming > to your favoriate platform some day. > ... Keep in mind that setlocale() (for glibc anyways, haven't checked others) is thread-specific, so using it as the source of the correct language and charset is going to be a lot more portable/easier on developers (although we could always use NULL values to mean "get it from the current locale...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Wed Oct 9 10:42:04 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <116DB56CD7DED511BC7800508B2CA53735CDE8@mailsrvnt02.enet.sharplabs.com> Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? The IPP attributes-natural-language operation request attribute is exactly the client requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hastings at cp10.es.xerox.com Thu Oct 10 17:00:38 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F9086652B8@x-crt-es-ms1.cp10.es.xerox.com> Alan and Ira, The only problem I have with Alan's proposed text, is that the PAPI needs to clear about which attributes are localized by the Printer, when they are supported. There is only 3 (read on). I talked with Peter Zehler about the Internationalization question. The PWG Semantic Model is using a simplified approach from that of IPP. Recall that each IPP 'text' or 'name' attribute has a charset and naturalLanguage implicitly or explicitly associated with it in both the client-to-Printer requests and Printer-to-client responses. Those attributes that have the implicit form, inherit the charset or naturalLanguage from the request or the Job level. For the PWG Semantic Model (see section 6 of the PWG Semantic Model), we've come to realize that there are a very few attributes that need to be localized by the Printer in a response. They are the very few that the Printer generates. The corresponding IPP attributes are: "job-state-message", "document-state-message" and "printer-state-message". Even for the "detailed-status-message" (text) operation attribute, RFC 2911 says: "the Printer NEED NOT localize the message, since it is intended for use by the system administrator or other experienced technical persons. Localization might obscure the technical meaning of such messages." I think that the PAPI should just list these 3 attributes as being localized by the Printer, if supported at all. (All 3 are OPTIONAL to support in IPP). The value of storing the naturalLanguage with text and name attributes that a client supplies in a Job Creation request didn't seem to have much value. The only use case I can recall is that a user gets back a job attribute with a value supplied by another user in some language he doesn't understand and he could find out what the language was. But what does he do with that? Shout out, "Who understands Swedish" in order to get help with understanding the attribute that the Swedish user had submitted in his Swedish job? So the PWG Semantic Model doesn't have the concept that every attribute has its own natural language which can potentially differ from the one for the request, the response, the job, or the printer. The PWG Semantic Model has the following attributes about Natural Language: 1. AttributesNaturalLanguage - stored with the job to indicate the natural language submitted. 2. DocumentNaturalLanguage - the natural language of the Document submitted. This week at CIP4, we agreed that the writing direction for a document needs its own explicit attribute, rather than be keyed of this one or off PresentationDirectionNumberUp. 3. GeneratedNaturalLanguageSupported - Printer Description attribute saying which language the administrator has set. 4. MISSING from version 0.13: GeneratedNaturalLanguageSupported - the natural languages that the Printer supports. So when the client submits one of these languages it can expect to get a localized response for "JobStateMessage", "DocumentStateMessage" and "PrinterStateMessage" attributes. Here is the complete section 6 Globalization from the PWG Semantic Model: The two aspects of globalization being addressed are the character sets and natural language of the human readable strings. Determining what character set is being used is left up to the protocol mapping of this semantic model. The natural language being used is represented in the Printer and the Job. The Printer declares the natural language it uses for all its semantic elements of type string. Administrators are free to change the localization and the values in the string elements. Each job creator declares the natural language for the Job and all its contained Documents. Not all string elements are treated the same. Any semantic element that is labeled type1, type2 or type3 keyword in the constraint column is the following tables do not have any globalization issues from the Printer's point of view. They are simply a sequence of octets that have a semantic meaning attached to them. The fact that the sequence of octets can be interpreted as ASCII strings is unimportant. The keywords are intended for consumption by automata. We leave it to Client implementations to determine how the keywords will be presented to end-users. There are also strings with specific formats. These formats are URI, URI Scheme, MIME, IEEE 1284 and DateTime. Any semantic element whose string value must adhere to one of the previous formats is excluded from this discussion. There are a few elements whose value is set by automata. Those values are "JobStateMessage", "DocumentStateMessage" and "PrinterStateMessage". If the semantic model is mapped to a protocol that allows the Client to request a language, the Printer will return these strings in the requested language if possible. All the remaining Printer element strings are assumed to be in the Printer's language. All the remaining Job element strings are assumed to be in the language of the Job. -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, October 09, 2002 10:42 To: 'printing-spool@freestandards.org' Subject: RE: [printing-spool] PAPI Internationalization Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? The IPP attributes-natural-language operation request attribute is exactly the client requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From kugler at us.ibm.com Fri Oct 11 08:10:32 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: It hardly seems worth providing any mechanism for returning localized messages from the Printer, since the "job-state-message", "document-state-message" and "printer-state-message" should not contain any additional information beyond that conveyed by the corresponding -state and -state-reasons attributes. Leave it up to the client to generate a localized message from the -state & -state-reasons enumerations & keywords. -Carl "Hastings, Tom N" Sent by: printing-spool-admin@freestandards.org 10/10/2002 06:00 PM Please respond to printing-spool To: printing-spool@freestandards.org cc: "Zehler, Peter" Subject: RE: [printing-spool] PAPI Internationalization Alan and Ira, The only problem I have with Alan's proposed text, is that the PAPI needs to clear about which attributes are localized by the Printer, when they are supported. There is only 3 (read on). I talked with Peter Zehler about the Internationalization question. The PWG Semantic Model is using a simplified approach from that of IPP. Recall that each IPP 'text' or 'name' attribute has a charset and naturalLanguage implicitly or explicitly associated with it in both the client-to-Printer requests and Printer-to-client responses. Those attributes that have the implicit form, inherit the charset or naturalLanguage from the request or the Job level. For the PWG Semantic Model (see section 6 of the PWG Semantic Model), we've come to realize that there are a very few attributes that need to be localized by the Printer in a response. They are the very few that the Printer generates. The corresponding IPP attributes are: "job-state-message", "document-state-message" and "printer-state-message". Even for the "detailed-status-message" (text) operation attribute, RFC 2911 says: "the Printer NEED NOT localize the message, since it is intended for use by the system administrator or other experienced technical persons. Localization might obscure the technical meaning of such messages." I think that the PAPI should just list these 3 attributes as being localized by the Printer, if supported at all. (All 3 are OPTIONAL to support in IPP). The value of storing the naturalLanguage with text and name attributes that a client supplies in a Job Creation request didn't seem to have much value. The only use case I can recall is that a user gets back a job attribute with a value supplied by another user in some language he doesn't understand and he could find out what the language was. But what does he do with that? Shout out, "Who understands Swedish" in order to get help with understanding the attribute that the Swedish user had submitted in his Swedish job? So the PWG Semantic Model doesn't have the concept that every attribute has its own natural language which can potentially differ from the one for the request, the response, the job, or the printer. The PWG Semantic Model has the following attributes about Natural Language: 1. AttributesNaturalLanguage - stored with the job to indicate the natural language submitted. 2. DocumentNaturalLanguage - the natural language of the Document submitted. This week at CIP4, we agreed that the writing direction for a document needs its own explicit attribute, rather than be keyed of this one or off PresentationDirectionNumberUp. 3. GeneratedNaturalLanguageSupported - Printer Description attribute saying which language the administrator has set. 4. MISSING from version 0.13: GeneratedNaturalLanguageSupported - the natural languages that the Printer supports. So when the client submits one of these languages it can expect to get a localized response for "JobStateMessage", "DocumentStateMessage" and "PrinterStateMessage" attributes. Here is the complete section 6 Globalization from the PWG Semantic Model: The two aspects of globalization being addressed are the character sets and natural language of the human readable strings. Determining what character set is being used is left up to the protocol mapping of this semantic model. The natural language being used is represented in the Printer and the Job. The Printer declares the natural language it uses for all its semantic elements of type string. Administrators are free to change the localization and the values in the string elements. Each job creator declares the natural language for the Job and all its contained Documents. Not all string elements are treated the same. Any semantic element that is labeled type1, type2 or type3 keyword in the constraint column is the following tables do not have any globalization issues from the Printer's point of view. They are simply a sequence of octets that have a semantic meaning attached to them. The fact that the sequence of octets can be interpreted as ASCII strings is unimportant. The keywords are intended for consumption by automata. We leave it to Client implementations to determine how the keywords will be presented to end-users. There are also strings with specific formats. These formats are URI, URI Scheme, MIME, IEEE 1284 and DateTime. Any semantic element whose string value must adhere to one of the previous formats is excluded from this discussion. There are a few elements whose value is set by automata. Those values are "JobStateMessage", "DocumentStateMessage" and "PrinterStateMessage". If the semantic model is mapped to a protocol that allows the Client to request a language, the Printer will return these strings in the requested language if possible. All the remaining Printer element strings are assumed to be in the Printer's language. All the remaining Job element strings are assumed to be in the language of the Job. -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, October 09, 2002 10:42 To: 'printing-spool@freestandards.org' Subject: RE: [printing-spool] PAPI Internationalization Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? The IPP attributes-natural-language operation request attribute is exactly the client requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021011/b9fbcce2/attachment.htm From mike at easysw.com Fri Oct 11 08:44:42 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: Message-ID: <3DA6F1EA.50109@easysw.com> Carl Kugler wrote: > > It hardly seems worth providing any mechanism for returning localized > messages from the Printer, since the "job-state-message", > "document-state-message" and "printer-state-message" should not > contain any additional information beyond that conveyed by the > corresponding -state and -state-reasons attributes. Leave it up to > the client to generate a localized message from the -state & > -state-reasons enumerations & keywords. > ... Well, no, I'd disagree with that statement. For CUPS those attributes often contain more information ("Printing Page 1, 47% complete", etc.) since the keyword-based values provide only general information. However, given the limits of the implementation, those attributes will likely be localized only to the default language (and not to arbitrary languages), so in the end it will probably makes more sense for the client to localize the keyword values and optionally display any of the four text attributes. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From kugler at us.ibm.com Fri Oct 11 09:48:33 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: Well, for job-state-message, the spec (RFC 2911) specifically says "SHOULD NOT". "Otherwise, application programs might attempt to parse the (localized text)." -Carl Michael Sweet Sent by: printing-spool-admin@freestandards.org 10/11/2002 09:44 AM Please respond to printing-spool To: printing-spool@freestandards.org cc: Subject: Re: [printing-spool] PAPI Internationalization Carl Kugler wrote: > > It hardly seems worth providing any mechanism for returning localized > messages from the Printer, since the "job-state-message", > "document-state-message" and "printer-state-message" should not > contain any additional information beyond that conveyed by the > corresponding -state and -state-reasons attributes. Leave it up to > the client to generate a localized message from the -state & > -state-reasons enumerations & keywords. > ... Well, no, I'd disagree with that statement. For CUPS those attributes often contain more information ("Printing Page 1, 47% complete", etc.) since the keyword-based values provide only general information. However, given the limits of the implementation, those attributes will likely be localized only to the default language (and not to arbitrary languages), so in the end it will probably makes more sense for the client to localize the keyword values and optionally display any of the four text attributes. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021011/2b8a97e3/attachment.htm From imcdonald at sharplabs.com Fri Oct 11 11:54:09 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization [writing direction ] Message-ID: <116DB56CD7DED511BC7800508B2CA53735CDEC@mailsrvnt02.enet.sharplabs.com> Hi Tom, > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Thursday, October 10, 2002 8:01 PM > To: printing-spool@freestandards.org > Cc: Zehler, Peter > Subject: RE: [printing-spool] PAPI Internationalization > > Alan and Ira, > > <...snip...> > >The PWG Semantic Model has the following attributes about Natural Language: > 1. AttributesNaturalLanguage - stored with the job to indicate the natural > language submitted. > 2. DocumentNaturalLanguage - the natural language of the Document submitted. > This week at CIP4, we agreed that the writing direction for a document needs > its own explicit attribute, rather than be keyed of this one or off > PresentationDirectionNumberUp. This is a BAD mistake - Unicode-based software determines the writing direction according to the nearest language-tag (RFC 3066), including any inline language-tags in running text (using invisible Plane 14 'language tag' characters). Each Unicode character has an inherent and NORMATIVE directional property (some are neutral - but Arabic, for example, is ALWAYS right-to-left). The direction of writing MAY also be dynamically changed using Unicode explicit markup characters (RLE, LRE, RLO, LRO, PDF, RLM, and LRM). Cheers, - Ira From hastings at cp10.es.xerox.com Mon Oct 14 00:20:55 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Comments on PAPI: need function references to IPP operations Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90866532A@x-crt-es-ms1.cp10.es.xerox.com> Alan, Here are some improved comments on the references to IPP: 1. The functions in Chapter 5 and 7 should have references to the appropriate IPP operation. Otherwise the semantics are of the functions are left up to the imagination of the reader. Here are the sections and the IPP operation semantic descriptions that go with the functions. The blanks indicate no equivalent IPP operation: 5.2 papiPrintersList 5.3 papiPrinterQuery - Get-Printer-Attributes [RFC2911] section 3.2.5 5.4 papiPrinterModify - Set-Printer-Attributes [RFC3380] section 4.1 5.5. papiPrinterPause - Pause-Printer [RFC2911] section 3.2.7 5.6 papiPrinterResume - Resume-Printer [RFC2911] section 3.2.8 5.7 papiPrinterPurgeJobs - Purge-Jobs [RFC2911] section 3.2.9 5.8 papiPrinterListJobs - Get-Jobs [RFC2911] section 3.2.6 5.9 papiPrinterGetAttributeList ... 7.1 papiJobSubmit - Print-Job [RFC2911] section 3.2.1 7.2 papiJobSubmitByReference - Print-URI [RFC2911] section 3.2.2 7.3 papiJobValidate - Validate-Job [RFC2911] section 3.2.3 7.4 papiJobStreamOpen 7.5 papiJobStreamWrite 7.6 papiJobStreamClose 7.7. papiJobQuery - Get-Job-Attributes [RFC2911] section 3.3.4 7.8 papiJobModify - Set-Job-Attributes [RFC3380] section 4.2 7.9 papiJobCancel - Cancel-Job [RFC2911] section 3.3.3 7.10 papiJobHold - Hold-Job [RFC2911] section 3.3.5 7.11 papiJobRelease - Release-Job [RFC2911] section 3.3.6 7.12 papiJobRestart - Restart-Job [RFC2911] section 3.3.7 ... These references could be added to each Header or somewhere in the text description. 2. Section B.1, IPP References should have some way to get the documents, since they are all free. How about putting the URL for the PWG IPP WG and for the IETF RFCs? I suggest adding at the beginning of the section: IETF RFCs can be obtained from: http://www.rfc-editor.org/rfcsearch.html Other IPP documents can be obtained from: http://www.pwg.org/ipp/index.html and ftp://ftp.pwg.org/pub/pwg/ipp/new_XXX/ 3. Section B.1, IPP References should have: [5101.1] Hastings, T., and D. Fullman February 5, 2001 IEEE-ISTO 5100.1-2001 Internet Printing Protocol (IPP): finishings attribute values extension and: [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst November 2001 Internet Printing Protocol/1.1: Implementer's Guide Thanks, Tom From mike at easysw.com Mon Oct 14 04:32:15 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Comments on PAPI: need function references to IPP operations References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90866532A@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3DAAAB3F.2010201@easysw.com> Hastings, Tom N wrote: > Alan, > > Here are some improved comments on the references to IPP: > > 1. The functions in Chapter 5 and 7 should have references to the > appropriate IPP operation. Otherwise the semantics are of the functions are > left up to the imagination of the reader. Here are the sections and the IPP > operation semantic descriptions that go with the functions. The blanks > indicate no equivalent IPP operation: I've included the mappings to the CUPS extension operations, from the CUPS-IPP-1.1 document at http://www.cups.org/ > 5.2 papiPrintersList CUPS-Get-Printers, CUPS-Get-Classes > 5.3 papiPrinterQuery - Get-Printer-Attributes [RFC2911] section 3.2.5 > 5.4 papiPrinterModify - Set-Printer-Attributes [RFC3380] section 4.1 > 5.5. papiPrinterPause - Pause-Printer [RFC2911] section 3.2.7 > 5.6 papiPrinterResume - Resume-Printer [RFC2911] section 3.2.8 > 5.7 papiPrinterPurgeJobs - Purge-Jobs [RFC2911] section 3.2.9 > 5.8 papiPrinterListJobs - Get-Jobs [RFC2911] section 3.2.6 > 5.9 papiPrinterGetAttributeList Probably Get-Printer-Attributes [RFC2911] section 3.2.5 > ... > > 7.1 papiJobSubmit - Print-Job [RFC2911] section 3.2.1 > 7.2 papiJobSubmitByReference - Print-URI [RFC2911] section 3.2.2 > 7.3 papiJobValidate - Validate-Job [RFC2911] section 3.2.3 > 7.4 papiJobStreamOpen > 7.5 papiJobStreamWrite > 7.6 papiJobStreamClose Probably Print-Job [RFC-2911] section 3.2.1 > 7.7. papiJobQuery - Get-Job-Attributes [RFC2911] section 3.3.4 > 7.8 papiJobModify - Set-Job-Attributes [RFC3380] section 4.2 > 7.9 papiJobCancel - Cancel-Job [RFC2911] section 3.3.3 > 7.10 papiJobHold - Hold-Job [RFC2911] section 3.3.5 > 7.11 papiJobRelease - Release-Job [RFC2911] section 3.3.6 > 7.12 papiJobRestart - Restart-Job [RFC2911] section 3.3.7 > ... > > These references could be added to each Header or somewhere in the text > description. > > > 2. Section B.1, IPP References should have some way to get the documents, > since they are all free. How about putting the URL for the PWG IPP WG and > for the IETF RFCs? > > I suggest adding at the beginning of the section: > > IETF RFCs can be obtained from: http://www.rfc-editor.org/rfcsearch.html > > Other IPP documents can be obtained from: http://www.pwg.org/ipp/index.html > and ftp://ftp.pwg.org/pub/pwg/ipp/new_XXX/ > > > 3. Section B.1, IPP References should have: > > [5101.1] Hastings, T., and D. Fullman February 5, 2001 IEEE-ISTO 5100.1-2001 > Internet Printing Protocol (IPP): finishings attribute values extension > > and: > > [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst > November 2001 Internet Printing Protocol/1.1: Implementer's Guide > > Thanks, > Tom > > _______________________________________________ > printing-spool mailing list > printing-spool@freestandards.org > http://freestandards.org/mailman/listinfo/printing-spool > > -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Mon Oct 14 11:39:12 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Globalization Message-ID: OK, I THINK I've understood the comments about my previous proposal on PAPI "Internationalization". Here is my new proposal based on the comments. A new section in the "Print System Model" chapter: Globalization The PAPI interface follows the conventions for globalization and translation of human-readable strings that are outlined in the IPP standard and the PWG Semantic Model. A quick summary: * Attribute names are never translated. * Most text values are not translated. * Supporting translation by PAPI implementations is optional. * If translation is supported, only the values of the following attributes are translated: job-state-message, document-state-message, and printer-state-message. The above is just a summary. For details, see [RFC2911] section 3.1.4 and [PWGSemMod] section 6. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021014/859d9a4a/attachment.htm From imcdonald at sharplabs.com Mon Oct 14 11:53:39 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Globalization Message-ID: <116DB56CD7DED511BC7800508B2CA53735CDF4@mailsrvnt02.enet.sharplabs.com> Hi Alan, Looks fine to me. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Monday, October 14, 2002 2:39 PM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Globalization OK, I THINK I've understood the comments about my previous proposal on PAPI "Internationalization". Here is my new proposal based on the comments. A new section in the "Print System Model" chapter: Globalization The PAPI interface follows the conventions for globalization and translation of human-readable strings that are outlined in the IPP standard and the PWG Semantic Model. A quick summary: * Attribute names are never translated. * Most text values are not translated. * Supporting translation by PAPI implementations is optional. * If translation is supported, only the values of the following attributes are translated: job-state-message, document-state-message, and printer-state-message. The above is just a summary. For details, see [RFC2911] section 3.1.4 and [PWGSemMod] section 6. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hastings at cp10.es.xerox.com Mon Oct 14 13:03:56 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Globalization Message-ID: <0CCC9D5E696C4E4DBFC2EBCEA6A3F908665355@x-crt-es-ms1.cp10.es.xerox.com> Alan, I agree with the wording. Very simple and clear. Tom -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, October 14, 2002 11:54 To: 'printing-spool@freestandards.org' Subject: RE: [printing-spool] PAPI Globalization Hi Alan, Looks fine to me. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Monday, October 14, 2002 2:39 PM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Globalization OK, I THINK I've understood the comments about my previous proposal on PAPI "Internationalization". Here is my new proposal based on the comments. A new section in the "Print System Model" chapter: Globalization The PAPI interface follows the conventions for globalization and translation of human-readable strings that are outlined in the IPP standard and the PWG Semantic Model. A quick summary: * Attribute names are never translated. * Most text values are not translated. * Supporting translation by PAPI implementations is optional. * If translation is supported, only the values of the following attributes are translated: job-state-message, document-state-message, and printer-state-message. The above is just a summary. For details, see [RFC2911] section 3.1.4 and [PWGSemMod] section 6. Comments? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From Norm.Jacobs at Sun.COM Mon Oct 14 13:02:17 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Comments on PAPI: need function referencesto IPP operations References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90866532A@x-crt-es-ms1.cp10.es.xerox.com> <3DAAAB3F.2010201@easysw.com> Message-ID: <3DAB22C9.5C2F87CC@Sun.COM> Mike Sweet wrote: > > Hastings, Tom N wrote: > > Alan, > > > > Here are some improved comments on the references to IPP: > > > > 1. The functions in Chapter 5 and 7 should have references to the > > appropriate IPP operation. Otherwise the semantics are of the functions are > > left up to the imagination of the reader. Here are the sections and the IPP > > operation semantic descriptions that go with the functions. The blanks > > indicate no equivalent IPP operation: > > > > 5.3 papiPrinterQuery - Get-Printer-Attributes [RFC2911] section 3.2.5 > > 5.4 papiPrinterModify - Set-Printer-Attributes [RFC3380] section 4.1 > > 5.5. papiPrinterPause - Pause-Printer [RFC2911] section 3.2.7 > > 5.6 papiPrinterResume - Resume-Printer [RFC2911] section 3.2.8 > > 5.7 papiPrinterPurgeJobs - Purge-Jobs [RFC2911] section 3.2.9 > > 5.8 papiPrinterListJobs - Get-Jobs [RFC2911] section 3.2.6 > > 5.9 papiPrinterGetAttributeList > > Probably Get-Printer-Attributes [RFC2911] section 3.2.5 In some internal feedback that I got, they had confused papiPrinterQuery() and papiPrinterGetAttributeList(). I think that a reference to Get-Printer-Attributes would have confused them more. Since papiPrinterGetAttributeList() doesn't really map to any protocol operation and it is really retreiving an attribute list from the result of a previous operation, I would suggest that we leave out the reference. I would rather see the description expanded to include something like: papiPrinterGetAttributeList(): This function retreives an attribute list from a printer object returned in a previous call. Printer objects are returned as the result of operations performed by papiPrintersList(), papiPrinterQuery(), and papiPrinterModify(). papiJobGetAttributeList(): This function retreices an attribute list from a job object returned in a previous call. Job objects are returned as a result of the operations performed by papiPrinterListJobs(), papiJobQuery(), papiJobModify(), papiJobSubmit(), papiJobSubmitByReference(), and papiJobClose() From mike at easysw.com Tue Oct 15 05:57:46 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] Comments on PAPI: need function referencesto IPP operations References: <0CCC9D5E696C4E4DBFC2EBCEA6A3F90866532A@x-crt-es-ms1.cp10.es.xerox.com> <3DAAAB3F.2010201@easysw.com> <3DAB22C9.5C2F87CC@Sun.COM> Message-ID: <3DAC10CA.60302@easysw.com> Norm Jacobs wrote: > ... > In some internal feedback that I got, they had confused > papiPrinterQuery() and papiPrinterGetAttributeList(). I think that a > reference to Get-Printer-Attributes would have confused them more. > Since papiPrinterGetAttributeList() doesn't really map to any > protocol operation and it is really retreiving an attribute list from > the result of a previous operation, I would suggest that we leave out > the reference. I would rather see the description expanded to > include something like: > ... Sounds good. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Oct 15 05:59:06 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Globalization References: Message-ID: <3DAC111A.6070502@easysw.com> Alan Hlava wrote: > ... > Comments? Nice, short, simple. I approve! :) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Fri Oct 18 12:08:52 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi-v0.7.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy of the HTML version to Shawn and Charles for inclusion on the web page. This version of the spec is the candidate PAPI V1.0 spec. Please only make comments on wording, typos, etc. unless there is a significant functional problem or deficiency that would prevent this from being a viable version 1 (in which case, please point this out ASAP!). If there are no major functional problems, we plan to incorporate the wording corrections/enhancements received and then start the process to issue this as the V1.0 spec on November 15, 2002. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021018/e5d39aae/attachment.htm From kugler at us.ibm.com Wed Oct 9 11:34:55 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: In general, IPP messages SHOULD NOT contain additional information not contained in the values of the corresponding status enumerations. So, the value of a mechanism for returning translated message strings is dubious. Leave it up to the client to display localized messages derived from the status codes. -Carl "McDonald, Ira" Sent by: printing-spool-admin@freestandards.org 10/09/2002 11:42 AM Please respond to printing-spool To: "'printing-spool@freestandards.org'" cc: Subject: RE: [printing-spool] PAPI Internationalization Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? The IPP attributes-natural-language operation request attribute is exactly the client requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021009/b8c404f4/attachment.htm From bob_taylor at am.exch.hp.com Fri Oct 18 15:09:58 2002 From: bob_taylor at am.exch.hp.com (TAYLOR,BOB (HP-Vancouver,ex1)) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <6D805D4C4567D411AF32009027B683510ACF24DC@xvan02.vcd.hp.com> What should be done with vendor extensions? It's likely in many cases that = the client wouldn't have appropriate localized messages (or any human readable string at all) for these. = bt -----Original Message----- From: Carl Kugler [mailto:kugler@us.ibm.com] Sent: Wednesday, October 09, 2002 11:35 AM To: printing-spool@freestandards.org Subject: RE: [printing-spool] PAPI Internationalization In general, IPP messages SHOULD NOT contain additional information not contained in the values of the corresponding status enumerations. So, the value of a mechanism for returning translated message strings is dubious. Leave it up to the client to display localized messages derived from the status codes. = -Carl = "McDonald, Ira" = Sent by: printing-spool-admin@freestandards.org = 10/09/2002 11:42 AM = Please respond to printing-spool = = To: "'printing-spool@freestandards.org'" = cc: = Subject: RE: [printing-spool] PAPI Internationalization Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: = 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: = "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." = 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? = The IPP attributes-natural-language operation request attribute is exactly the client = requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns = results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, = Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments= /20021018/28d96408/attachment.htm From kugler at us.ibm.com Fri Oct 18 16:24:24 2002 From: kugler at us.ibm.com (Carl Kugler) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: For job-state-message the RFC says "For such additional information such as interpreter errors for application program consumption or specific document access errors, new attributes with keyword values, needs to be developed and registered." However, for Operation Response, "The "status-message" is especially useful for a later version of a Printer object to return as supplemental information for the human user to accompany a status code that an earlier version of a client might not understand." So I guess IPP has it both ways. Has anybody ever implemented localized status messages for IPP? I've never seen it done. -Carl P.S. I was the one who advocated "detailed-status-message" and "job-detailed-status-messages" as handy places to return things like "strerror()" strings, exception messages, etc., that couldn't be easily localized. I was envisioning something like an error dialog with a "Details" button that would bring up the detailed technical information for diagnostic purposes (the kind of stuff end users might not understand but would be useful help desk or support people.) In the IPP world you can get errors at all kinds of levels, from IPP, HTTP, TCP, socket, and on down to interpreter, renderer, etc. "TAYLOR,BOB (HP-Vancouver,ex1)" Sent by: printing-spool-admin@freestandards.org 10/18/2002 04:09 PM Please respond to printing-spool To: "'printing-spool@freestandards.org'" cc: Subject: RE: [printing-spool] PAPI Internationalization What should be done with vendor extensions? It's likely in many cases that the client wouldn't have appropriate localized messages (or any human readable string at all) for these. bt -----Original Message----- From: Carl Kugler [mailto:kugler@us.ibm.com] Sent: Wednesday, October 09, 2002 11:35 AM To: printing-spool@freestandards.org Subject: RE: [printing-spool] PAPI Internationalization In general, IPP messages SHOULD NOT contain additional information not contained in the values of the corresponding status enumerations. So, the value of a mechanism for returning translated message strings is dubious. Leave it up to the client to display localized messages derived from the status codes. -Carl "McDonald, Ira" Sent by: printing-spool-admin@freestandards.org 10/09/2002 11:42 AM Please respond to printing-spool To: "'printing-spool@freestandards.org'" cc: Subject: RE: [printing-spool] PAPI Internationalization Hi Alan, Sorry for the slow response on IPP issues - see inline below. Cheers, - Ira McDonald High North Inc -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 04, 2002 9:00 AM To: printing-spool@freestandards.org Subject: [printing-spool] PAPI Internationalization The following PAPI suggestions/questions came up at yesterday's Open Print conference call: 1) Add a statement to the spec that translated strings should be returned to the caller in the language in which the caller is running. I agree with this suggestion, but I made it a "should" rather than a "must" to allow for connecting to a print server that is running in a different language than the client, and that does not support a multilingual interface (i.e. it can't return messages in a language other than the one it's running in). Here is my proposed wording of this statement: "The PAPI interface should return translated strings in the language in which the caller is running. "Translated strings" includes interface messages and attribute values containing messages (attribute names are not translated)." 2) Add an argument to papiServiceCreate and a service "set" API call to specify the language in which translated strings are to be returned, allowing the caller to request messages in a language other than the one under which it is running. I'm a bit confused about how such an argument would relate to the IPP attributes-natural-language request attribute. Perhaps one of the IPP gurus who are on this list could comment? The IPP attributes-natural-language operation request attribute is exactly the client requested language tag that you want in papiServiceCreate. Note that if the IPP client requests a language that is NOT a value of the Printer Description attribute "generated-natural-languages-supported", then the IPP Printer actually returns results in the operation response in the natural language specified by the current value of the Printer Description attribute "natural-language-configured". Oddly, an IPP Printer actually MUST accept description strings in a natural language (e.g., Windows-932, Japanese) that the IPP Printer does not support, because the IPP Printer can simply tag those strings with the alternate natural language. (note that the IPP Printer need not interpret or parse those strings). However, an IPP Printer MUST NOT accept description strings in a charset (encoding) that the IPP Printer does not support, because no data integrity is possible. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021018/726d87af/attachment.htm From mike at easysw.com Sun Oct 20 12:43:21 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: <6D805D4C4567D411AF32009027B683510ACF24DC@xvan02.vcd.hp.com> Message-ID: <3DB30759.4080908@easysw.com> TAYLOR,BOB (HP-Vancouver,ex1) wrote: > What should be done with vendor extensions? It's likely in many > cases that the client wouldn't have appropriate localized messages > (or any human readable string at all) for these. > ... Show the (raw) keyword strings, and leave it up to the implementation/ app to provide a way to extend the localization of keywords. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Sun Oct 20 13:53:20 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: Message-ID: <3DB317C0.8000701@easysw.com> Carl Kugler wrote: > > For job-state-message the RFC says "For such additional information > such as interpreter errors for application program consumption or > specific document access errors, new attributes with keyword values, > needs to be developed and registered." However, for Operation > Response, "The "status-message" is especially useful for a later > version of a Printer object to return as supplemental information for > the human user to accompany a status code that an earlier version of > a client might not understand." So I guess IPP has it both ways. Has > anybody ever implemented localized status messages for IPP? I've > never seen it done. > ... CUPS 1.2 will be implementing it... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From bobt at hp.com Mon Oct 21 08:48:25 2002 From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1)) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <6D805D4C4567D411AF32009027B683510ACF24E5@xvan02.vcd.hp.com> That sounds pretty un-friendly - I don't see how the imp/app could have any reasonable way to extend the localization of things it doesn't understand. I guess I don't understand the objection here - this is something that's been available in Windows GPDs for years. Why not let the device/vendor provide localized strings when it would clearly be better for the user? bt > -----Original Message----- > From: Mike Sweet [mailto:mike@easysw.com] > Sent: Sunday, October 20, 2002 12:43 PM > To: printing-spool@freestandards.org > Subject: Re: [printing-spool] PAPI Internationalization > > > TAYLOR,BOB (HP-Vancouver,ex1) wrote: > > What should be done with vendor extensions? It's likely in many > > cases that the client wouldn't have appropriate localized messages > > (or any human readable string at all) for these. > > ... > > Show the (raw) keyword strings, and leave it up to the implementation/ > app to provide a way to extend the localization of keywords. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > > > _______________________________________________ > printing-spool mailing list > printing-spool@freestandards.org > http://freestandards.org/mailman/listinfo/printing-spool > From mike at easysw.com Mon Oct 21 09:15:41 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: <6D805D4C4567D411AF32009027B683510ACF24E5@xvan02.vcd.hp.com> Message-ID: <3DB4282D.40308@easysw.com> TAYLOR,BOB (HP-Vancouver,ex1) wrote: > That sounds pretty un-friendly - I don't see how the imp/app could > have any reasonable way to extend the localization of things it > doesn't understand. > > I guess I don't understand the objection here - this is something > that's been available in Windows GPDs for years. Why not let the > device/vendor provide localized strings when it would clearly be > better for the user? The existing PPD mechanism in CUPS provide localization of groups, options, and choices. While this works, I don't think that we want to expose the underlying printer description format or printer driver interface in PAPI. Exposing the localization via attributes is probably not the way to do it, either... OK, what if we provided a few functions for localizing attribute names and values, e.g.: const char * papiAttributeLocalizeName( papi_service_t handle, const char *printer_name, const char *attr_name); const char * papiAttributeLocalizeValue( papi_service_t handle, const char *printer_name, const char *attr_name, const char *value); This would allow the service object to cache printer description data (PPD file or whatever) for the named printer, and do lookups for the localized strings associated with each attribute and its corresponding values. Some issues: 1. If no localization is available, do we return the original string (attr_name or value, respectively) or NULL? 2. Do we return the strings directly, or return a pointer by reference and return a papi_status_t enumeration? 3. Localized strings are generally in non-volatile buffers; do we follow this convention (and potentially leak memory) or do we put the burden on the application to cache the data? For #3, what if we add a "localization" object (l10n) that can be created and freed as needed for a printer, e.g.: papi_status_t papiL10nNew( papi_service_t handle, const char *name, papi_l10n_t **l10n); papi_status_t papiL10nDelete( papi_l10n_t *l10n); papi_status_t papiL10nGetName( papi_l10n_t *l10n, const char *name, char **lname); papi_status_t papiL10nGetValue( papi_l10n_t *l10n, const char *name, const char *value, char **lvalue); -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Mon Oct 21 13:39:47 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE03@mailsrvnt02.enet.sharplabs.com> Hi, While I like the PAPI Localization API that Michael Sweet just put out, in the main, I want to support Bob Taylor's point here. I personally have helped two printer vendors (Xerox and Sharp) to enable printer-side localization of all otherwise opaque English keywords (it was done via enterprise MIBs, but the requirement is equally relevant in IPP, in my humble opinion). The printer which contains support for multiple languages anyway in status message catalogs, can simple support message catalogs to translate attribute names and keyword values to a different locale. Also accompanying descriptive text for each keyword value, so that a full dynamic client-side UI is supported. Printers are well-qualified to export the localization for their vendor- and site-specific extensions. Clients _never_ are. Anyone who has worked on a client package release with multiple language support knows how hard it is to get the _right_ one shipped with the physical printer on the CD. Why not extend IPP and PAPI to do this? Cheers, - Ira McDonald High North Inc -----Original Message----- From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt@hp.com] Sent: Monday, October 21, 2002 11:48 AM To: 'printing-spool@freestandards.org' Subject: RE: [printing-spool] PAPI Internationalization That sounds pretty un-friendly - I don't see how the imp/app could have any reasonable way to extend the localization of things it doesn't understand. I guess I don't understand the objection here - this is something that's been available in Windows GPDs for years. Why not let the device/vendor provide localized strings when it would clearly be better for the user? bt > -----Original Message----- > From: Mike Sweet [mailto:mike@easysw.com] > Sent: Sunday, October 20, 2002 12:43 PM > To: printing-spool@freestandards.org > Subject: Re: [printing-spool] PAPI Internationalization > > > TAYLOR,BOB (HP-Vancouver,ex1) wrote: > > What should be done with vendor extensions? It's likely in many > > cases that the client wouldn't have appropriate localized messages > > (or any human readable string at all) for these. > > ... > > Show the (raw) keyword strings, and leave it up to the implementation/ > app to provide a way to extend the localization of keywords. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > > > _______________________________________________ > printing-spool mailing list > printing-spool@freestandards.org > http://freestandards.org/mailman/listinfo/printing-spool > _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From mike at easysw.com Mon Oct 21 14:02:44 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: <116DB56CD7DED511BC7800508B2CA53735CE03@mailsrvnt02.enet.sharplabs.com> Message-ID: <3DB46B74.7080505@easysw.com> McDonald, Ira wrote: > Hi, > > While I like the PAPI Localization API that Michael Sweet just put out, > in the main, I want to support Bob Taylor's point here. > > I personally have helped two printer vendors (Xerox and Sharp) to > enable printer-side localization of all otherwise opaque English > keywords (it was done via enterprise MIBs, but the requirement is > equally relevant in IPP, in my humble opinion). > > The printer which contains support for multiple languages anyway > in status message catalogs, can simple support message catalogs > to translate attribute names and keyword values to a different > locale. Also accompanying descriptive text for each keyword > value, so that a full dynamic client-side UI is supported. > > Printers are well-qualified to export the localization for their > vendor- and site-specific extensions. Clients _never_ are. > Anyone who has worked on a client package release with multiple > language support knows how hard it is to get the _right_ one > shipped with the physical printer on the CD. > > Why not extend IPP and PAPI to do this? > ... I don't think IPP is the right place for it, although we could probably provide a 1setOf collection attribute (language + URL) that points the client at the message catalog files (via HTTP), and then define a common XML format for the data such that the attribute names and the keyword values are translated, perhaps with "help" text as well. I don't remember if UPDF uses one or multiple XML files to provide language coverage, but it seems like it can already provide the necessary information. Then for PAPI we will want to hide this implementation detail from the app, and provide the localization API to access the translation data. In short, standardizing on a localization scheme for IPP is a good job for the PWG, but PAPI's only job is to provide an implementation-neutral interface to whatever the OS/printing system provides. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Mon Oct 21 14:35:03 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE05@mailsrvnt02.enet.sharplabs.com> Hi, Sorry I wasn't more concrete. In previous implementations (below), we quickly realized that you do NOT simply publish the whole message catalog online simultaneously (it's gigantic across many attributes, keywords, and natural languages). What I propose is that we add to IPP an explicit search/query (NOT a simple Get-Printer-Attributes) that returns the localized info for ONE named 'requested-attribute' in ONE named 'requested-language'. And I propose that we anticipate adding this functionality to both IPP and the PWG Semantic Model, and focus near-term (as Michael Sweet says below) on the PAPI functions that expose localization support (from PPD or over-the-wire or whatever source). Cheers, - Ira McDonald High North Inc -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Monday, October 21, 2002 5:03 PM To: printing-spool@freestandards.org Subject: Re: [printing-spool] PAPI Internationalization McDonald, Ira wrote: > Hi, > > While I like the PAPI Localization API that Michael Sweet just put out, > in the main, I want to support Bob Taylor's point here. > > I personally have helped two printer vendors (Xerox and Sharp) to > enable printer-side localization of all otherwise opaque English > keywords (it was done via enterprise MIBs, but the requirement is > equally relevant in IPP, in my humble opinion). > > The printer which contains support for multiple languages anyway > in status message catalogs, can simple support message catalogs > to translate attribute names and keyword values to a different > locale. Also accompanying descriptive text for each keyword > value, so that a full dynamic client-side UI is supported. > > Printers are well-qualified to export the localization for their > vendor- and site-specific extensions. Clients _never_ are. > Anyone who has worked on a client package release with multiple > language support knows how hard it is to get the _right_ one > shipped with the physical printer on the CD. > > Why not extend IPP and PAPI to do this? > ... I don't think IPP is the right place for it, although we could probably provide a 1setOf collection attribute (language + URL) that points the client at the message catalog files (via HTTP), and then define a common XML format for the data such that the attribute names and the keyword values are translated, perhaps with "help" text as well. I don't remember if UPDF uses one or multiple XML files to provide language coverage, but it seems like it can already provide the necessary information. Then for PAPI we will want to hide this implementation detail from the app, and provide the localization API to access the translation data. In short, standardizing on a localization scheme for IPP is a good job for the PWG, but PAPI's only job is to provide an implementation-neutral interface to whatever the OS/printing system provides. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool From mike at easysw.com Mon Oct 21 15:30:47 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: <116DB56CD7DED511BC7800508B2CA53735CE05@mailsrvnt02.enet.sharplabs.com> Message-ID: <3DB48017.4070706@easysw.com> McDonald, Ira wrote: > ... > What I propose is that we add to IPP an explicit search/query (NOT > a simple Get-Printer-Attributes) that returns the localized info for > ONE named 'requested-attribute' in ONE named 'requested-language'. One problem with this approach is performance - doing a round-trip request for every attribute will be very slow compared to a "tell me which file to get for this language" request. FWIW, I'm not expecting vendors to provide a single message catalog for all languages, but at the same time it might make sense for a vendor to ship a single file for regions, e.g. Western European, Eastern European, etc. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From bobt at hp.com Mon Oct 21 17:31:08 2002 From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1)) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: <6D805D4C4567D411AF32009027B683510ACF24F5@xvan02.vcd.hp.com> This is a little more what I was thinking - i.e. "give me all your attributes/values/viewable strings for 'Canadian French'". I'm assuming the typical use for this would be to build UI's, so getting them in a block seems reasonable. bt > -----Original Message----- > From: Mike Sweet [mailto:mike@easysw.com] > Sent: Monday, October 21, 2002 3:31 PM > To: printing-spool@freestandards.org > Subject: Re: [printing-spool] PAPI Internationalization > > > McDonald, Ira wrote: > > ... > > What I propose is that we add to IPP an explicit search/query (NOT > > a simple Get-Printer-Attributes) that returns the localized info for > > ONE named 'requested-attribute' in ONE named 'requested-language'. > > One problem with this approach is performance - doing a round-trip > request for every attribute will be very slow compared to a "tell > me which file to get for this language" request. > > FWIW, I'm not expecting vendors to provide a single message catalog > for all languages, but at the same time it might make sense for a > vendor to ship a single file for regions, e.g. Western European, > Eastern European, etc. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > > > _______________________________________________ > printing-spool mailing list > printing-spool@freestandards.org > http://freestandards.org/mailman/listinfo/printing-spool > From hlava at us.ibm.com Tue Oct 22 04:52:13 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization Message-ID: I would like to clarify whether we think that the absense of the proposed localization functions (or something functionally equivalent) in the current version of PAPI is a "show stopper" for V1.0. Since the current version of the PAPI spec is proposed as functionally frozen, I don't want to add any functions at this point unless we think they are absolutely essential for a viable first release. I lean towards deferring these functions to a later version. Any arguments against this? Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021022/f4c7b37e/attachment.htm From mike at easysw.com Tue Oct 22 06:09:09 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI Internationalization References: Message-ID: <3DB54DF5.3010900@easysw.com> Alan Hlava wrote: > > I would like to clarify whether we think that the absense of the > proposed localization functions (or something functionally > equivalent) in the current version of PAPI is a "show stopper" for > V1.0. Since the current version of the PAPI spec is proposed as > functionally frozen, I don't want to add any functions at this point > unless we think they are absolutely essential for a viable first > release. > > I lean towards deferring these functions to a later version. Any > arguments against this? Since we haven't defined how we're getting the list of vendor options, constraints, etc., I would agree that we shouldn't hold PAPI 1.0 for this stuff. We can add the new functions and attributes to 1.1/2.0 after we have some sample implementations to play with (so everyone can see what works and what doesn't...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Mon Oct 28 08:59:20 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 References: Message-ID: <3DBD6CE8.1060103@easysw.com> Alan Hlava wrote: > > At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi-v0.7.pdf you can > find a new version of the Open Standard Print API (PAPI). See the > Change History section for details on the changes in this version. > I will also be sending a copy of the HTML version to Shawn and > Charles for inclusion on the web page. > > This version of the spec is the candidate PAPI V1.0 spec. Please > only make comments on wording, typos, etc. unless there is a > significant functional problem or deficiency that would prevent this > from being a viable version 1 (in which case, please point this out > ASAP!). OK, some comments with a dose of nitpicking: 1. Add "as well as implementation-defined security policies" to the first sentence of the security section (line 203, page 3) 2. On the same page, a sentence starts with "See field encryption in section ...". This would probably sound better if written as "See the encryption field in section ...". 3. On the same page, the old HTTP_ENCRYPT_NEVER symbol should be replaced by its sybling PAPI_ENCRYPT_NEVER. 4. Ditto #3 on Page 5, line 263. 5. Indentation inconsistency on lines 271-277 of page 5. 6. The papi_filter_t structure on Page 8 is incorrect; the bitmask type filter requires both a value and a mask word, e.g.: union { struct { unsigned int value, mask; } bitmask; ... } filter; The above nested structure uses the union name "bitmask" to match the enumeration wording and "filter" instead of "u" for the union. 7. papiGetUsername, papiSetUsername, papiGetServicename, and papiSetServicename should probably be papiGetUserName, etc. (capital N on Name) to be consistent with the rest of the API naming. 8. The filter example on Page 24 for papiPrinterList is incorrect. The corrected code should look like: papi_filter_t filter; papi_printer_t* printers = NULL; ... filter.type = PAPI_FILTER_BITMASK; filter.filter.bitmask.value = PAPI_PRINTER_BW | PAPI_PRINTER_DUPLEX; filter.filter.bitmask.mask = PAPI_PRINTER_BW | PAPI_PRINTER_DUPLEX; Alternatively we can provide a papiFilterSetBitmask function that does the initialization (although I'm not sure how necessary that would be...) 9. The attributes API starting on page 39 talks about an "add_flags" argument, but the constants for this bitmask are not defined or described anywhere in the document! -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Mon Oct 28 12:46:59 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 Message-ID: I have incorporated all your suggestions except for... On Monday, 10/28/2002 at 11:59 EST, Michael Sweet wrote: > 6. The papi_filter_t structure on Page 8 is incorrect; the > bitmask type filter requires both a value and a mask > word, e.g.: > > union > { > struct > { > unsigned int value, mask; > } bitmask; > ... > } filter; > > The above nested structure uses the union name "bitmask" > to match the enumeration wording and "filter" instead of "u" > for the union. ... > 8. The filter example on Page 24 for papiPrinterList is > incorrect. The corrected code should look like: > > papi_filter_t filter; > papi_printer_t* printers = NULL; > ... > > filter.type = PAPI_FILTER_BITMASK; > filter.filter.bitmask.value = PAPI_PRINTER_BW | > PAPI_PRINTER_DUPLEX; > filter.filter.bitmask.mask = PAPI_PRINTER_BW | > PAPI_PRINTER_DUPLEX; I guess I don't understand how value and mask are used. Can you explain how each is used and maybe update the example to have them set to different values? > > 9. The attributes API starting on page 39 talks about > an "add_flags" argument, but the constants for this > bitmask are not defined or described anywhere in the > document! These are documented on p. 6, line 332. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021028/b983fd18/attachment.htm From mike at easysw.com Mon Oct 28 12:56:23 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 References: Message-ID: <3DBDA477.2000708@easysw.com> Alan Hlava wrote: > > I have incorporated all your suggestions except for... > ... > I guess I don't understand how value and mask are used. > Can you explain how each is used and maybe update the > example to have them set to different values? OK, the comparison is: (printer-type & mask) == (value & mask) The mask determines which bits are important, and the value determines whether the bits are set or cleared. For the example, use: filter.filter.bitmask.value = PAPI_PRINTER_BW | PAPI_PRINTER_DUPLEX; filter.filter.bitmask.mask = PAPI_PRINTER_BW | PAPI_PRINTER_COLOR | PAPI_PRINTER_DUPLEX; This will select only B&W printers that can print double-sided. > > 9. The attributes API starting on page 39 talks about > > an "add_flags" argument, but the constants for this > > bitmask are not defined or described anywhere in the > > document! > These are documented on p. 6, line 332. Oops, maybe they should be broken out, as they didn't stand out from the long list of definitions. Even just adding a short paragraph: The following constants are used by the papiAttributeListAdd* functions to control how values are added to the list or existing attributes: -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Mon Oct 28 13:28:46 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 Message-ID: On Monday, 10/28/2002 at 03:56 EST, Michael Sweet wrote: > OK, the comparison is: > > (printer-type & mask) == (value & mask) > > The mask determines which bits are important, and the value > determines whether the bits are set or cleared. > > For the example, use: > > filter.filter.bitmask.value = PAPI_PRINTER_BW | PAPI_PRINTER_DUPLEX; > filter.filter.bitmask.mask = PAPI_PRINTER_BW | PAPI_PRINTER_COLOR > | PAPI_PRINTER_DUPLEX; > > This will select only B&W printers that can print double-sided. I still don't understand. Why is the color bit selected as "important" in the mask and then deselected by the value? What does this gain vs. having the comparison as: (printer-type & mask) == mask and thus having only one field in the filter? > Oops, maybe they should be broken out, as they didn't stand out > from the long list of definitions. Even just adding a short > paragraph: OK, done. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021028/8f994684/attachment.htm From mike at easysw.com Mon Oct 28 15:00:15 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 References: Message-ID: <3DBDC17F.6030607@easysw.com> Alan Hlava wrote: > ... > I still don't understand. Why is the color bit selected as > "important" in the mask and then deselected by the value? What does > this gain vs. having the comparison as: > > (printer-type & mask) == mask > > and thus having only one field in the filter? Because it makes it impossible to list only those printers that *don't* have those bits set. For example, you may only be interested in devices that can produce a true grayscale output, vs. one that always uses the colors to produce a composite black for some/all shades of gray. At other times, you may only be interested in "local" printers, so it is necessary to select the PAPI_PRINTER_REMOTE bit in the mask, but not in the value. In short, doing value + mask allows you to filter based on the value 1 *or* 0 (why am I having a Blues Brothers flashback - "we have both kinds of bits here, 1's *and* 0's!" :) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From imcdonald at sharplabs.com Mon Nov 4 11:16:03 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] FW: DHCP Option for SNMP Notifications Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE20@mailsrvnt02.enet.sharplabs.com> -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Monday, November 04, 2002 2:04 PM To: 'ps@pwg.org'; 'ipp@pwg.org' Subject: PS> FW: DHCP Option for SNMP Notifications Hi folks, Mark Bakke (Cisco) has been doing some good work to define a new DHCP boot option that tells a device where to send SNMP traps (i.e., addresses of SNMP Notification Receivers, network management stations). Definitely applicable for printer devices. Cheers, - Ira McDonald High North Inc PS - Mark Bakke co-wrote the SLP MIB with me last year. -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Monday, November 04, 2002 10:17 AM To: dhcwg@ietf.org; snmpv3@lists.tislabs.com; mibs@ops.ietf.org Subject: DHCP Option for SNMP Notifications Hi- I've submitted a new DHCP Option for SNMP Notifications draft, after attempting to incorporate the feedback I received on the first one. Until it pops out of the I-D queue, it's available at: ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-01.txt Thanks to everyone who contributed and helped me get the SNMP security stuff figured out. I just realized that I forgot to update some of the acknowledgements; Randy Presuhn and David Perkins also helped with this. I also need to spend more time on the references; I realized that these sections are still not up-to-date. Comments? Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From hastings at cp10.es.xerox.com Thu Nov 14 09:36:31 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.7 [Reminder: comments due tomorrow, Nov 15] Message-ID: This is a reminder to reviewers to get final comments on PAPI V0.7 to the printing-spool@freestandards.org DL by tomorrow, Nov 15 as stated by Alan on October 18. I'm copying the printing-discuss@freestandards.org DL just for information, but please send comments to the printing-spool@freestandards.org only, unless the comments relate to other FSG WGs as well. In the Architecture WG telecon today, we discussed whether the JT API decision to use enums (instead of keywords) for the values of closed end attributes caused a problem for job ticket applications that were also using the PAPI Capabilities call (papiPrinterQuery). The PAPI capabilities call returns keywords for all attributes (open ended and closed ended). I believe that we agreed that if any function calls are needed that provide the mapping from enum to keywords, such a function call would be provided by the JT API in its 1.0 or 1.1, but wouldn't need to be in the PAPI capability calls for PAPI 1.0. In the future, the PAPI capability call might want to also include enum values as well (along with other meta data information about attributes), but that remains to be seen. Right? Thanks, Tom -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, October 18, 2002 12:09 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI V0.7 At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi-v0.7.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version. I will also be sending a copy of the HTML version to Shawn and Charles for inclusion on the web page. This version of the spec is the candidate PAPI V1.0 spec. Please only make comments on wording, typos, etc. unless there is a significant functional problem or deficiency that would prevent this from being a viable version 1 (in which case, please point this out ASAP!). If there are no major functional problems, we plan to incorporate the wording corrections/enhancements received and then start the process to issue this as the V1.0 spec on November 15, 2002. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021114/9b8556b3/attachment.htm From hlava at us.ibm.com Fri Nov 15 11:54:39 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.8 Message-ID: At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi-v0.8.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version (they are minor). I will also be sending a copy of the HTML version to Charles for inclusion on the web page. This version of the spec is the release candidate PAPI V1.0 spec. We will now begin the process of getting this approved as the 1.0 spec. Regards, Alan Hlava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021115/0b853770/attachment.htm From hastings at cp10.es.xerox.com Fri Nov 15 17:06:06 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.8 [comment on the new "media-margins " attribute] Message-ID: Alan and Michael, I like the new simple "media-margins" (1setOf integer) attribute in section 9.1.2 consisting of four or eight integers to represent the unprintable margins on the front and back sides of sheets. Unfortunately, I missed the email message that Michael sent on October 25 on the order of the four integers. I thought that I had suggested that the four values be top, right, bottom, and left, to agree with UPnPv1 MarginSize attribute in the EnhancedPrint Service Template which was explicitly taken from the W3C Cascaded Style Sheets (CSS2) spec. CSS2 is available at: http://www.w3.org/TR/REC-CSS2/ I suspect that UPnPv2 will also do margins the same way and the PWG will be adding the "media-margins" attribute to IPP and the PWG Semantic Model. So it would help a lot if we could fix the order of the integers in the PAPI V0.8 spec to be the same, namely: top, right, bottom, and left. If you go to the CSS2 spec, be careful. Section 8.2 shows a margin with four integers with order: left, right, top, and bottom. However, sections 8.3 through 8.5 has the order as top, right, bottom, and left. I also missed the units of measure. The unit of measure for the "media-size" attribute in the "media-col" attribute in IPP and the PWG Semantic Model is 100th of a millimeter, rather than micrometers. See IEEE-ISTO 5100.3 section 3.13.8.1 at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf . It would help to change to 100th of a mm in PAPI, as well so that the units are consistent. Editorial: Section 9.1.2 on "media-margins" contains the sentence: "Unless otherwise specified, the margin values represent the minimum margins that can be used with all sizes and types of media." What does "Unless otherwise specified" mean? Specified where? I'm guessing that the "Unless otherwise specified," means unless the calling application supplied the "media" or "media-col" job attribute in the job_attrs input parameter, the returned values are for all sizes and types of media. How about replacing the "Unless otherwise specified" so it reads: "Unless the calling program supplies the "media" or "media-col" attribute in the job_attr input parameter to the papiPrinterQuery function, the margin values returned represent the minimum margins that can be used with all sizes and types of media." I'm sorry for such late comments, Tom -----Original Message----- From: Alan Hlava [mailto:hlava@us.ibm.com] Sent: Friday, November 15, 2002 11:55 To: printing-spool@freestandards.org Subject: [printing-spool] PAPI V0.8 At ftp://ftp.pwg.org/pub/pwg/fsg/spool/ in file papi-v0.8.pdf you can find a new version of the Open Standard Print API (PAPI). See the Change History section for details on the changes in this version (they are minor). I will also be sending a copy of the HTML version to Charles for inclusion on the web page. This version of the spec is the release candidate PAPI V1.0 spec. We will now begin the process of getting this approved as the 1.0 spec. Regards, Alan Hlava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021115/0e832a81/attachment.htm From mike at easysw.com Mon Nov 18 10:08:19 2002 From: mike at easysw.com (Michael Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.8 [comment on the new "media-margins " attribute] References: Message-ID: <3DD92C93.1070008@easysw.com> Hastings, Tom N wrote: > ... > I suspect that UPnPv2 will also do margins the same way and the PWG > will be adding the "media-margins" attribute to IPP and the PWG > Semantic Model. So it would help a lot if we could fix the order of > the integers in the PAPI V0.8 spec to be the same, namely: > > top, right, bottom, and left. Sounds fine to me. I used the order normally found in PPD files, but then the origin (0,0) of the page in PostScript is the bottom left corner, not the top left like in HTML... > I also missed the units of measure. The unit of measure for the > "media-size" attribute in the "media-col" attribute in IPP and the > PWG Semantic Model is 100th of a millimeter, rather than micrometers. > See IEEE-ISTO 5100.3 section 3.13.8.1 at: > ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf. It would help to > change to 100th of a mm in PAPI, as well so that the units are > consistent. Works for me; I just wanted to make sure we had enough precision... > Editorial: Section 9.1.2 on "media-margins" contains the sentence: > > "Unless otherwise specified, the margin values represent the minimum > margins that can be used with all sizes and types of media." > > What does "Unless otherwise specified" mean? Specified where? I'm > guessing that the "Unless otherwise specified," means unless the > calling application supplied the "media" or "media-col" job attribute > in the job_attrs input parameter, the returned values are for all > sizes and types of media. Eventually there will be a defined query mechanism in place (PAPI 1.1/2.0) along with the constraints, etc. We haven't defined any of this for 1.0, so currently the media-margins values will be the "safe" values for all combinations of attributes. Perhaps better wording would be: Currently the margin values only represent the minimum margins that can be used with all sizes and types of media. Future versions of the PAPI spec may define an interface for getting the margin values for specific combinations of job template attributes. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hlava at us.ibm.com Mon Nov 18 11:56:42 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI V0.9 Message-ID: I put a V0.9 of the PAPI spec on the ftp site (ftp://ftp.pwg.org/pub/pwg/fsg/spool/papi-v0.9.pdf). The only changes in this version are the media-margins changes discussed by Tom and Michael. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021118/15668bf0/attachment.htm From hastings at cp10.es.xerox.com Wed Dec 4 16:32:55 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] RE: PAPI "supported" functions Message-ID: Norm, This thread has been moved to [printing-spool] where it should be. 1. We liked your two functions for the Miscellaneous section. 2. Ira and I found a function in your list that isn't in the PAPI v0.9 spec: papiServiceSetServiceName Optional API Support 3. We suggest that the papi.h file be included in the same directory as the spec and the IPP-Object-Attributes.pdf file that is referenced from Section 9. 4. The header file should be referenced from the spec, just like the IPP-Object-Attributes.pdf file. 5. Having the header file would also make it clear what some of the type definitions are as well that aren't explained or defined in the spec. 6. Ira and I agree with your optional attributes, even papiJobValidate (even though it is required in IPP). I'll update our two profiles accordingly. 7. However, in doing the review, we realized that there are a bunch of functions in the Services section that are a mistake and should be removed. They are the Set and Get of the individual fields of the Service object: UserName, Password, Encryption, AuthCB, AppData, and ServiceName. Since all of them (except AppData) are passed in the constructor, why not delete all of the Set functions? Then provide a single Get (or Query?) function which returns all 6 of the fields of the Service object as a structure? We think that being able to change such fundamental things in the Service object instance, such as UserName, Password, Authentication, is not sound. Also having a lot of optional functions is not very useful. Application writers won't use them, if they are optional, since they won't always be present. 8. What did you mean by the notation "Printer Support": papiPrinterListJobs Core Printer Support Its the only attribute listed with "Printer Support". Thanks, Tom -----Original Message----- From: Norm Jacobs [mailto:Norm.Jacobs@sun.com] Sent: Tuesday, December 03, 2002 15:42 To: printing-discuss@freestandards.org Subject: [printing-meetingnotes] PAPI "supported" functions In our last conference call, we discussed a desire to be able to enumerate support for the various PAPI functions from a particular PAPI implementation. Since we are not breaking down the PAPI further into constituent components and we are requiring unsupported functions to return PAPI_OPERATION_NOT_SUPPORTED, It's not sufficient to simply be able to link with the library to determine support. Assuming that we add something, the additional calls probably belong in the Misc. section of the spec. Anyway, here a couple of possible calls that we could use to determine if a function is stubbed out or not. -Norm papiLibrarySupportedCalls() Description The papiLibrarySupportedCalls() function can be called to request a list of API functions that are supported in the implementation. Support for a function means that the implementation of that function is not a stub that simply returns PAPI_OPERATION_NOT_SUPPORTED. Syntax extern char **papiLibrarySupportedCalls(); Inputs none Outputs none Returns A NULL terminated list of supported function names. This list should not be free'd by the caller. papiLibrarySupportedCall() Description The papiLibrarySupportedCall() function can be called to determine if a specific API call is supported in the implementation. Support for a function means that the implementation of that function is not a stub that simply returns PAPI_OPERATION_NOT_SUPPORTED. Syntax extern char papiLibrarySupportedCall(char *name); Inputs name The name of the function that is being asked about Outputs none Returns A return of PAPI_TRUE indicates that the named function is supported by the API implementation. A return of PAPI_FALSE indicates that the the named function is not supported by the API implementation. Below is a list of functions in the PAPI papiAttributeListAdd Core API Support papiAttributeListAddString Core API Support papiAttributeListAddInteger Core API Support papiAttributeListAddBoolean Core API Support papiAttributeListAddRange Core API Support papiAttributeListAddResolution Core API Support papiAttributeListAddDatetime Core API Support papiAttributeListAddCollection Core API Support papiAttributeListDelete Core API Support papiAttributeListGet Core API Support papiAttributeListGetString Core API Support papiAttributeListGetInteger Core API Support papiAttributeListGetBoolean Core API Support papiAttributeListGetRange Core API Support papiAttributeListGetResolution Core API Support papiAttributeListGetDatetime Core API Support papiAttributeListGetCollection Core API Support papiAttributeListFree Core API Support papiAttributeListFind Core API Support papiAttributeListGetNext Core API Support papiAttributeListFromString Optional API Support papiAttributeListToString Optional API Support papiServiceCreate Core API Support papiServiceDestroy Core API Support papiServiceSetUserName Optional API Support papiServiceSetPassword Optional API Support papiServiceSetEncryption Optional API Support papiServiceSetAuthCB Optional API Support papiServiceSetAppData Optional API Support papiServiceSetServiceName Optional API Support papiServiceGetUserName Optional API Support papiServiceGetPassword Optional API Support papiServiceGetEncryption Optional API Support papiServiceGetAuthCB Optional API Support papiServiceGetAppData Optional API Support papiServiceGetServiceName Optional API Support papiServiceGetStatusMessage Core API Support papiPrintersList Core API Support papiPrinterQuery Core API Support papiPrinterModify Optional API Support papiPrinterPause Optional API Support papiPrinterResume Optional API Support papiPrinterPurgeJobs Optional API Support papiPrinterListJobs Core Printer Support papiPrinterGetAttributeList Core API Support papiPrinterFree Core API Support papiJobSubmit Core Job Support papiJobSubmitByReference Core Job Support papiJobValidate Optional Job Support papiJobStreamOpen Core Job Support papiJobStreamWrite Core Job Support papiJobStreamClose Core Job Support papiJobQuery Core Job Support papiJobModify Optional Job Support papiJobCancel Core Job Support papiJobHold Optional Job Support papiJobRelease Optional Job Support papiJobRestart Optional Job Support papiJobGetAttributeList Core Job Support papiJobGetPrinterName Core Job Support papiJobGetID Core Job Support papiJobGetJobTicket Optional Job Support papiJobFree Core Job Support papiJobListFree Core Job Support papiStatusString Core API Support papiLibrarySupportedCalls Core API Support papiLibrarySupportedCall Core API Support _______________________________________________ printing-discuss mailing list printing-discuss@freestandards.org http://base.freestandards.org/mailman/listinfo/printing-discuss From imcdonald at sharplabs.com Wed Dec 4 16:35:58 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] FW: PAPI Service set and query operations Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE42@mailsrvnt02.enet.sharplabs.com> Hi, With apologies for posting to the wrong list, as Tom Hastings just observed a moment ago. Cheers, - Ira McDonald (High North) -----Original Message----- From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Wednesday, December 04, 2002 6:11 PM To: printing-meetingnotes@freestandards.org; 'hastings@cp10.es.xerox.com' Subject: [printing-meetingnotes] PAPI Service set and query operations Hi, Wednesday (4 December 2002) Tom Hastings and I have a fundamental comment on the PAPI v0.9 spec, with our sincere apologies for not noticing this problem sooner. The following five Service functions are fine and should be kept: papiServiceCreate Core API Support papiServiceDestroy Core API Support papiServiceSetAppData Optional API Support papiServiceGetAppData Optional API Support papiServiceGetStatusMessage Core API Support All of the following Service functions should be removed from the spec: papiServiceSetUserName Optional API Support papiServiceSetPassword Optional API Support papiServiceSetEncryption Optional API Support papiServiceSetAuthCB Optional API Support papiServiceSetServiceName Optional API Support papiServiceGetUserName Optional API Support papiServiceGetPassword Optional API Support papiServiceGetEncryption Optional API Support papiServiceGetAuthCB Optional API Support papiServiceGetServiceName Optional API Support All of the deleted "papiServiceGet...()" functions should be replaced by a new REQUIRED (Core) function "papiServiceQuery()" or (more explicit, less like Printer/Job) "papiServiceGetAttributes()". Rationale: Authentication and authorization MUST occur when the user originally creates a Service handle and not at some later date. Among all published IETF 'standards-track' protocols, currently only Secure HTTP (RFC 2660, which is NOT 'https:') does Transaction-level authentication rather than Session-level authentication (once per Session). Allowing the client application to CHANGE the value of username or any security parameter AFTER allocating a Service handle (and specifying those values at create time) is dangerous and will corrupt audit trails and accounting, at no particular benefit. If a new username or new security parameters are desired, the client application is free to destroy the first Service handle and allocate a second Service handle. We propose a new "papiServiceGetAttributes()" with the signature: papi_status_t papiServiceGetAttributes( papi_service_t* handle, papi_serviceattributes_t* attributes ); where "papi_serviceattributes_t" returns the input parameters from the original "papiServiceCreate()" call: typedef struct /* PAPI Service Attributes */ { const papi_service_t* handle; const char* service_name; const char* user_name; const char* password; const int (*authCB) (papi_service_t svc); const papi_encryption_t encryption; void* app_data; } papi_serviceattributes_t; Comments? Cheers, - Ira McDonald (High North) and Tom Hastings (Xerox) _______________________________________________ printing-meetingnotes mailing list printing-meetingnotes@freestandards.org http://freestandards.org/mailman/listinfo/printing-meetingnotes From hastings at cp10.es.xerox.com Wed Dec 4 16:45:04 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] What is the precedence of papiJobGetJobTicket versus papiJobQuery ? Message-ID: The PAPI spec clearly states the precedence of attributes supplied in papiJobSubmit versus attributes supplied in the Job Ticket. The former have precedence over the latter. However, no statement has been made about the precedence of attributes returned in the two queries: papiJobQuery and papiJobGetJobTicket and their relationship to the two submissions. Questions: 1. Is it REQUIRED that the attributes returned by papiJobQuery are the same as the ones supplied in papiJobSubmit? 2. Or MAY some of the attributes from the Job Ticket be merged in? 3. Or MAY all of the attributes from papiJobSubmit be merged into a Job Ticket, so that no attributes come back in papiJobQuery? 4. Or MAY all of the attributes in the Job Ticket be merged into what is returned with the papiJobQuery? Thanks, Tom From mike at easysw.com Wed Dec 4 17:01:38 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] FW: PAPI Service set and query operations In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CE42@mailsrvnt02.enet.sharplabs.com> References: <116DB56CD7DED511BC7800508B2CA53735CE42@mailsrvnt02.enet.sharplabs.com> Message-ID: <3DEEA572.500@easysw.com> McDonald, Ira wrote: > ... > All of the following Service functions should be removed from the spec: > ... > Rationale: > > Authentication and authorization MUST occur when the user originally > creates a Service handle and not at some later date. Among all > published IETF 'standards-track' protocols, currently only Secure HTTP > (RFC 2660, which is NOT 'https:') does Transaction-level authentication > rather than Session-level authentication (once per Session). HTTP Upgrade (to upgrade to TLS encryption) is a published RFC. Granted, it isn't on the standards track AFAIK, but CUPS implements it and it does allow the encryption setting separate from the creation of the client connection. Furthermore, some operations may require re-authentication, either because the user was not authorized when the service connection was created or because the resource or operation requires different priviledges. So, it is not practical to remove these methods, however it might be appropriate to document the appropriate error code to return when the underlying implementation is not able to change the service parameter (PAPI_NOT_POSSIBLE?) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Wed Dec 4 17:06:57 2002 From: mike at easysw.com (Mike Sweet) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] What is the precedence of papiJobGetJobTicket versus papiJobQuery ? In-Reply-To: References: Message-ID: <3DEEA6B1.2030300@easysw.com> Hastings, Tom N wrote: > ... > 1. Is it REQUIRED that the attributes returned by papiJobQuery are the same > as the ones supplied in papiJobSubmit? They may, in fact, be different if the job has been modified (for IPP, the Set-Job-Attributes, Hold-Job, Resume-Job, etc. operations can do this) Also, the job-state, job-state-reasons, and job-state-message attributes are necessarily dynamic, and certain attributes are automatically added for things like the job ID, pages in the job, etc. > 2. Or MAY some of the attributes from the Job Ticket be merged in? I don't believe that would be consistent with the IPP model, as the current spec does not, for example, copy the -default values to fill in unspecified job template attributes. > 3. Or MAY all of the attributes from papiJobSubmit be merged into a Job > Ticket, so that no attributes come back in papiJobQuery? See #2. > 4. Or MAY all of the attributes in the Job Ticket be merged into what is > returned with the papiJobQuery? See #2. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From Norm.Jacobs at Sun.COM Wed Dec 4 20:01:27 2002 From: Norm.Jacobs at Sun.COM (Norm Jacobs) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] RE: PAPI "supported" functions References: Message-ID: <3DEECF97.C1F7AEDD@Sun.COM> "Hastings, Tom N" wrote: > > 2. Ira and I found a function in your list that isn't in the PAPI v0.9 spec: > > papiServiceSetServiceName Optional API Support this is a copy/edit error > > 3. We suggest that the papi.h file be included in the same directory as the > spec and the IPP-Object-Attributes.pdf file that is referenced from Section > 9. > > 4. The header file should be referenced from the spec, just like the > IPP-Object-Attributes.pdf file. > > 5. Having the header file would also make it clear what some of the type > definitions are as well that aren't explained or defined in the spec. I don't have a problem with the header file being supplied and referenced, but all of the types in the spec should be fully defined. If one isn't, let's fix the spec. > > 8. What did you mean by the notation "Printer Support": > > papiPrinterListJobs Core Printer Support > > Its the only attribute listed with "Printer Support". > It's a leftover from one of the many passes I made at breaking out the functions into groupings. -Norm From hlava at us.ibm.com Thu Dec 5 05:26:52 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Thu Jul 12 13:10:48 2007 Subject: [printing-spool] PAPI questions Message-ID: It appears that PAPI V0.9 is not a viable candidate for a V1 standard. Between all the 11th-hour questions about IPP vs. PSI, addition of profiles, addition of new APIs, removal of APIs, and query precendence order, we must go back and develop a new version of PAPI that addresses these issues. We'll then have to come up with a new schedule and go through another review cycle before having a new V1 release candidate. Shawn: Please defer plans for a steering committee meeting on the PAPI standard. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From hastings at cp10.es.xerox.com Wed Dec 4 17:19:36 2002 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Thu Jul 12 13:10:49 2007 Subject: [printing-spool] RE: PAPI "supported" functions Message-ID: Here is the updated profile proposal aligning the REQUIRED and OPTIONAL with Norm's list, but dividing them into a Query Profile and a Job Submission Profile. The Job Submission Profile is a superset of the Query Profile. Ira and I have the following comments on PAPI V0.9 which we discovered while doing the profile work: 1. Section 2.2.4 Document and Appendix B. Do you want to add a reference to the IPP Document Object specification work in progress? Its available at ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/ 2. Section 2.4 Globalization. The passive voice is used, so it isn't clear whether the section is talking about the application program that calls the PAPI or the PAPI implementation itself. 3. Section 3.3 Attributes and Values needs a reference for the data type codes to [RFC2911] section 4.1. 4. Section 3.8 (papi_status_t) needs a reference to [RFC2911] section 13 where the corresponding IPP status codes are defined. 5. It would be good to add a blank line in front of each new enum value assignment. 6. The two new status codes defined by PAPI (PAPI_BAD_REQUEST and PAPI_JOB_TICKET_NOT_SUPPORTED) need to be defined starting at a new place, since IPP will assign values beyond the last IPP server error (PAPI_PRINTER_IS_DEACTIVATED). So how about starting the PAPI defined status codes at 0x0600. We'll indicate this usage in the IPP code assignment table as well. 7. Section 4.5, uses the papi_encryption_t data type without a definition. Presumably, it is defined in the papi.h header file. How many other types are used in the spec without definition? Is this a problem? 8. The papi.h file needs to be stored with the spec and referenced from the spec, such like the IPP-Object-Attributes.pdf file is in Section 9. These files are part of the spec. 9. Get rid of all the SetServiceXxxx and GetServceXxxx and use the constructor only to set variables as in the current specification. If an application wants to change a Service attribute, such as user name or password, the application must construct a new service handle. Have a single Get function to return all values as a single structure, so that a service handle can be passed to a subroutine and the subroutine can Get the contents of the Service object. With these changes, all functions in Section 4 are REQUIRED for both Profiles. Tom and Ira -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, December 04, 2002 16:33 To: Norm Jacobs Cc: printing-spool@freestandards.org Subject: [printing-spool] RE: PAPI "supported" functions Norm, This thread has been moved to [printing-spool] where it should be. 1. We liked your two functions for the Miscellaneous section. 2. Ira and I found a function in your list that isn't in the PAPI v0.9 spec: papiServiceSetServiceName Optional API Support 3. We suggest that the papi.h file be included in the same directory as the spec and the IPP-Object-Attributes.pdf file that is referenced from Section 9. 4. The header file should be referenced from the spec, just like the IPP-Object-Attributes.pdf file. 5. Having the header file would also make it clear what some of the type definitions are as well that aren't explained or defined in the spec. 6. Ira and I agree with your optional attributes, even papiJobValidate (even though it is required in IPP). I'll update our two profiles accordingly. 7. However, in doing the review, we realized that there are a bunch of functions in the Services section that are a mistake and should be removed. They are the Set and Get of the individual fields of the Service object: UserName, Password, Encryption, AuthCB, AppData, and ServiceName. Since all of them (except AppData) are passed in the constructor, why not delete all of the Set functions? Then provide a single Get (or Query?) function which returns all 6 of the fields of the Service object as a structure? We think that being able to change such fundamental things in the Service object instance, such as UserName, Password, Authentication, is not sound. Also having a lot of optional functions is not very useful. Application writers won't use them, if they are optional, since they won't always be present. 8. What did you mean by the notation "Printer Support": papiPrinterListJobs Core Printer Support Its the only attribute listed with "Printer Support". Thanks, Tom -----Original Message----- From: Norm Jacobs [mailto:Norm.Jacobs@sun.com] Sent: Tuesday, December 03, 2002 15:42 To: printing-discuss@freestandards.org Subject: [printing-meetingnotes] PAPI "supported" functions In our last conference call, we discussed a desire to be able to enumerate support for the various PAPI functions from a particular PAPI implementation. Since we are not breaking down the PAPI further into constituent components and we are requiring unsupported functions to return PAPI_OPERATION_NOT_SUPPORTED, It's not sufficient to simply be able to link with the library to determine support. Assuming that we add something, the additional calls probably belong in the Misc. section of the spec. Anyway, here a couple of possible calls that we could use to determine if a function is stubbed out or not. -Norm papiLibrarySupportedCalls() Description The papiLibrarySupportedCalls() function can be called to request a list of API functions that are supported in the implementation. Support for a function means that the implementation of that function is not a stub that simply returns PAPI_OPERATION_NOT_SUPPORTED. Syntax extern char **papiLibrarySupportedCalls(); Inputs none Outputs none Returns A NULL terminated list of supported function names. This list should not be free'd by the caller. papiLibrarySupportedCall() Description The papiLibrarySupportedCall() function can be called to determine if a specific API call is supported in the implementation. Support for a function means that the implementation of that function is not a stub that simply returns PAPI_OPERATION_NOT_SUPPORTED. Syntax extern char papiLibrarySupportedCall(char *name); Inputs name The name of the function that is being asked about Outputs none Returns A return of PAPI_TRUE indicates that the named function is supported by the API implementation. A return of PAPI_FALSE indicates that the the named function is not supported by the API implementation. Below is a list of functions in the PAPI papiAttributeListAdd Core API Support papiAttributeListAddString Core API Support papiAttributeListAddInteger Core API Support papiAttributeListAddBoolean Core API Support papiAttributeListAddRange Core API Support papiAttributeListAddResolution Core API Support papiAttributeListAddDatetime Core API Support papiAttributeListAddCollection Core API Support papiAttributeListDelete Core API Support papiAttributeListGet Core API Support papiAttributeListGetString Core API Support papiAttributeListGetInteger Core API Support papiAttributeListGetBoolean Core API Support papiAttributeListGetRange Core API Support papiAttributeListGetResolution Core API Support papiAttributeListGetDatetime Core API Support papiAttributeListGetCollection Core API Support papiAttributeListFree Core API Support papiAttributeListFind Core API Support papiAttributeListGetNext Core API Support papiAttributeListFromString Optional API Support papiAttributeListToString Optional API Support papiServiceCreate Core API Support papiServiceDestroy Core API Support papiServiceSetUserName Optional API Support papiServiceSetPassword Optional API Support papiServiceSetEncryption Optional API Support papiServiceSetAuthCB Optional API Support papiServiceSetAppData Optional API Support papiServiceSetServiceName Optional API Support papiServiceGetUserName Optional API Support papiServiceGetPassword Optional API Support papiServiceGetEncryption Optional API Support papiServiceGetAuthCB Optional API Support papiServiceGetAppData Optional API Support papiServiceGetServiceName Optional API Support papiServiceGetStatusMessage Core API Support papiPrintersList Core API Support papiPrinterQuery Core API Support papiPrinterModify Optional API Support papiPrinterPause Optional API Support papiPrinterResume Optional API Support papiPrinterPurgeJobs Optional API Support papiPrinterListJobs Core Printer Support papiPrinterGetAttributeList Core API Support papiPrinterFree Core API Support papiJobSubmit Core Job Support papiJobSubmitByReference Core Job Support papiJobValidate Optional Job Support papiJobStreamOpen Core Job Support papiJobStreamWrite Core Job Support papiJobStreamClose Core Job Support papiJobQuery Core Job Support papiJobModify Optional Job Support papiJobCancel Core Job Support papiJobHold Optional Job Support papiJobRelease Optional Job Support papiJobRestart Optional Job Support papiJobGetAttributeList Core Job Support papiJobGetPrinterName Core Job Support papiJobGetID Core Job Support papiJobGetJobTicket Optional Job Support papiJobFree Core Job Support papiJobListFree Core Job Support papiStatusString Core API Support papiLibrarySupportedCalls Core API Support papiLibrarySupportedCall Core API Support _______________________________________________ printing-discuss mailing list printing-discuss@freestandards.org http://base.freestandards.org/mailman/listinfo/printing-discuss _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool -------------- next part -------------- A non-text attachment was scrubbed... Name: papi-profiles-and-comments-v2.pdf Type: application/octet-stream Size: 21842 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021204/a471cbf4/papi-profiles-and-comments-v2.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: papi-profiles-and-comments-v2.doc Type: application/msword Size: 69632 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/printing-spool/attachments/20021204/a471cbf4/papi-profiles-and-comments-v2.doc From imcdonald at sharplabs.com Thu Dec 5 09:55:30 2002 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Thu Jul 12 13:10:49 2007 Subject: [printing-spool] FW: PAPI Service set and query operations Message-ID: <116DB56CD7DED511BC7800508B2CA53735CE43@mailsrvnt02.enet.sharplabs.com> Hi Michael, I see your point about HTTP TLS Upgrade, BUT... the TLS spec says that you MUST break the connection at the end of any negotiated TLS connection. That is, it's a one time only upgrade. These functions allow the corruption of the security parameters by any application thread that's received a copy of the Service handle. That's very bad, for accounting and reliability. There isn't enough info in these (current) security parameters to actually have an application participate in a three-way or four-way handshake. That's got to be done "under the covers" by the PAPI API/IPP implementation based on _one-time_ setting of the security parameters at Service handle creation time. Cheers, - Ira McDonald -----Original Message----- From: Mike Sweet [mailto:mike@easysw.com] Sent: Wednesday, December 04, 2002 7:02 PM To: printing-spool@freestandards.org Subject: Re: [printing-spool] FW: PAPI Service set and query operations McDonald, Ira wrote: > ... > All of the following Service functions should be removed from the spec: > ... > Rationale: > > Authentication and authorization MUST occur when the user originally > creates a Service handle and not at some later date. Among all > published IETF 'standards-track' protocols, currently only Secure HTTP > (RFC 2660, which is NOT 'https:') does Transaction-level authentication > rather than Session-level authentication (once per Session). HTTP Upgrade (to upgrade to TLS encryption) is a published RFC. Granted, it isn't on the standards track AFAIK, but CUPS implements it and it does allow the encryption setting separate from the creation of the client connection. Furthermore, some operations may require re-authentication, either because the user was not authorized when the service connection was created or because the resource or operation requires different priviledges. So, it is not practical to remove these methods, however it might be appropriate to document the appropriate error code to return when the underlying implementation is not able to change the service parameter (PAPI_NOT_POSSIBLE?) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com _______________________________________________ printing-spool mailing list printing-spool@freestandards.org http://freestandards.org/mailman/listinfo/printing-spool