From norbertschade at mediaone.net Fri Feb 1 13:21:21 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> what we may do on Monday Message-ID: <002401c1ab4d$3fce4a00$a8948018@ne.mediaone.net> Guys, Jim and I will arrive on Sunday from Boston. We will miss at least the first half of the Superbowl because of the flight. How could anybody have planned for that? So here is the agenda for Monday: If the Patriots will loose we may start a bit slow. You have to wear a black tie. If the Patriots will win we may even start a bit late. You have to wear a Patriots T-shirt. We will spend the first seven hours reconsidering the game. I have added some XML to our UPDF format, which allows to specify each play. No the more serious part: We will discuss a prepared proposal for a possible final design of composite features and user policies including a sample. Please prepare for raster graphic and color. Bring all information to the table, which you want to see listed there. Another major item will be command sequences and how they are implemented in Event handlers - following the discussion we started at the end of the last conference. See you there. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020201/a7d7a5c5/attachment.html From norbertschade at mediaone.net Thu Feb 7 14:19:56 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> meeting notes Message-ID: <001201c1b00c$6e375260$a8948018@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020207/6116fb5d/Latest_Meeting_Minutes.htm From norbertschade at mediaone.net Mon Feb 11 11:57:33 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> latest locale implementations Message-ID: <006101c1b31d$33b66720$a8948018@ne.mediaone.net> The overall structure of locales has proven to be good. Today we implemented some small modifications based on input we gathered over time. The corresponding schema and samples are on the web. Please access from the UPDF site. 1. Section titles As the number of entries grew over time, it turns into an advantage to have section titles when working with a XML editor. This will not effect a simple text editor. As you can see all locale elements referenced from unit descriptions are now gathered under ReferencedLocaleElements. Instead of facing on huge list of elements you can now close a section you are not working on. This is not really a structural change. 2. Popular text strings not referenced by unit descriptions We'd like to ease the acceptance of the text string handling we provide in UPDF. Although a huge number of strings can be referenced from unit descriptions we acknowledge that there are more in use in today's drivers. These are typically hanlded in defines in header files. We offer a chance to specify those, which are very popular between drivers, in a special section. 2.1. Mandatory text strings The current implementation includes a new section MandatoryLocaleElements (alternative title could be RequiredLocaleElements). This is a list of predefined elements with fixed Name_ID attributes. By this method we can help with the validation that each locale provides exactly 100% of those text strings considered mandatory and defined as such by the UPDF standard. A driver could rely on finding corresponding entries. In this case a locale referenced by a an optional unit or user policy must also provide 100% of all entries - even if unchanged. We've added two elements as a sample. Check that the attribute entry is identical to the element name in each case. 2.2. Optional common text strings Another way to implement it would be to predefine a list of Name_ID attribute values in the data types schema, but leave it to the developer, which of them he/she wants to provide for consistency (in a locale referenced by a device description - not an optional unit or user policy description - we'd seriously recommend to create elements for all of them). We would provide standard LocaleElement elements (in this case they don't have to have different names) under a section titled like CommonLocaleElements. In this case we can't help with a validation whether the list is complete. But an optional unit or user policy description would not have to list them again redundantly (in fact I'd rather be reluctant to overwrite them at all). Both ways have its advantage. We collect a list of proposals for common text strings over the next weeks. 3. Proprietary text strings This is another section to help with the acceptance of the format by consistent handling of text strings. We want to further allow storing any text strings used by a driver, as we think the localization within UPDF is highly optimized. So a driver developer could communicate all text strings defines to the UPDF developer, in which case the driver does not need any other defines in header files or anywhere else. This might likely be used when the printer manufacturer, who is supposed to develop the UPDF description, is the driver developer as well. Keep in mind that these proprietary string are not likely to be used, if the UPDF description is rather meant to be anonymous, which means it shall be used by any UPDF capable driver. I would especially use this section, if a printer manufacturer tends to write its own UPDF driver or cooperates with one driver developer for most of the drivers. This could also be the proper place to store error messages, which are not part of UPDF. We recommend some self-chosen discipline like specifying all UI string with a prefix 'UI_String_' and all error messages with a prefix 'Error_Messages_'. 4. Generic locales defaults Since we have an ID per feature, this is no more necessary and has been removed. As standard features like Media size, etc. have a predefined feature ID, but generic features can be given any string as a feature ID, we could split the Default_Feature attribute into two separate ones: Predefined_Default_Feature and Proprietary_Default_Feature. This should sound familiar to you from other functionality. Please check the schema and the samples and respond to this email. Especially send your proposals for common Name_ID attributes. We will revisit locales end of February. So that's the deadline for changes. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/87c3008f/attachment.html From norbertschade at mediaone.net Mon Feb 11 16:20:17 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> user policies Message-ID: <002f01c1b341$e77d9de0$a8948018@ne.mediaone.net> I have uploaded all modified schemas and xml files to our web site. Modifications are as described in the meeting minutes. This design was agreed on at the L.A. conference. As you can see in the device description, there is an optional, single element for one user policy. This may refer to a user policy description, which extends the original device description. It also may refer to one or more locales. Check the samples. We have added a user policy xml file, which adds a new ComponentSet to the CompositeFeature Media (the connection is done by using the same feature ID!!!) and an English locale, which provides the UI string for the new ComponentSet, replaces one string and sets one new default. Interdependencies will likely appear as well. The User Policy schema is a copy of the device description schema, subtracted by all entries except composite features and interdependencies. We do not split these two features into a separate schema module, but buy a little double work in case of editing these features in the two schemas. If you have questions about any detail, please ask now, as I have all that stuff quite active in my mind these days. Later this week I will provide a sample data flow how to get UI strings and how to handle command sequences. Please spend some minutes on them to be sure you completely understand the details. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/e691b85a/attachment.html From norbertschade at mediaone.net Mon Feb 11 16:35:58 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> user policies in networks Message-ID: <005701c1b344$18e392c0$a8948018@ne.mediaone.net> An additional note: UPDF does not care about passwords and similar stuff. So when somebody wants to create user policies for different users/user groups, he is supposed to create different directories to store them in per user/user group. Each directory may show slightly different device configuration files and different user policy descriptions and/or user policy locales. The original device description and all other files have to be identical in all directories! Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/492463a8/attachment.html From norbertschade at mediaone.net Mon Feb 11 17:14:46 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> UI string triggering in UPDF Message-ID: <007801c1b349$84115f00$a8948018@ne.mediaone.net> I want to provide a sample how a driver could read and identify the proper UI strings in a full UPDF description with all features in use. If a driver is not supporting the complete feature set, it has to define its own fallback mechanisms, of course. This sample data flow is just a proposal. But it might help for a better overall understanding. Our imaginary sample has IHV locales for US English and German. It has a composite feature Media with predefined ComponentSet elements for Letter/Auto and Letter/Tray2. It has an optional unit for an additional input tray 3 with locales for US English and German. It has a user policy for user 'Norbert Schade' with a US English locale and an additional ComponentSet Letter/Tray3. The host locale is Italian. Of course, the search process will be simpler for a simpler configuration. I vision that a driver at some point wants to create a complete list of UI strings for one locale. Here is how I may design the driver to work. The answers are based on this example config. Is the host locale provided for certain UI string reference? Check, if host locale specific string is available in optional unit description or IHV description for that locale. If available or not, check the user policy locales, whether the string is available there or overwritten there. General rule: If proper locale is not available anywhere, fall back to US English and start all over again for US English. In case US English is not available, fall back to the first locale listed and start all over again for that first locale. Now you must have triggered the string. Otherwise the UPDF description has a problem somewhere. Feel free to comment. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/5b60a551/attachment.html From jsommer at bellatlantic.net Tue Feb 12 07:48:57 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> latest locale implementations In-Reply-To: <006101c1b31d$33b66720$a8948018@ne.mediaone.net> Message-ID: <4.3.2.7.2.20020212074112.00c51bb0@mailbox.bellatlantic.net> My vote is to go with "optional common text strings" for two reasons. First is that User Policies shouldn't have to have these elements and this takes care of that problem. Second is that implementations are going to vary widely and we don't know exactly what strings are going to be required. Since we can't come up with them all and we don't know if all the ones we define are going to be used, it doesn't make sense to me to make them required. Also, we'll probably find many UPDFs that get written for a specific drivers. It doesn't seem right to require elements that are known to be unused in the target environment. Jim At 2/11/2002 11:57 AM, Norbert Schade wrote: >The overall structure of locales has proven to be good. Today we >implemented some small modifications based on input we gathered over time. >The corresponding schema and samples are on the web. Please access from >the UPDF site. > >1. Section titles >As the number of entries grew over time, it turns into an advantage to >have section titles when working with a XML editor. This will not effect a >simple text editor. >As you can see all locale elements referenced from unit descriptions are >now gathered under ReferencedLocaleElements. >Instead of facing on huge list of elements you can now close a section you >are not working on. This is not really a structural change. > >2. Popular text strings not referenced by unit descriptions >We'd like to ease the acceptance of the text string handling we provide in >UPDF. >Although a huge number of strings can be referenced from unit descriptions >we acknowledge that there are more in use in today's drivers. These are >typically hanlded in defines in header files. >We offer a chance to specify those, which are very popular between >drivers, in a special section. >2.1. Mandatory text strings >The current implementation includes a new section MandatoryLocaleElements >(alternative title could be RequiredLocaleElements). This is a list of >predefined elements with fixed Name_ID attributes. By this method we can >help with the validation that each locale provides exactly 100% of those >text strings considered mandatory and defined as such by the UPDF standard. >A driver could rely on finding corresponding entries. >In this case a locale referenced by a an optional unit or user policy must >also provide 100% of all entries - even if unchanged. >We've added two elements as a sample. Check that the attribute entry is >identical to the element name in each case. >2.2. Optional common text strings >Another way to implement it would be to predefine a list of Name_ID >attribute values in the data types schema, but leave it to the developer, >which of them he/she wants to provide for consistency (in a locale >referenced by a device description - not an optional unit or user policy >description - we'd seriously recommend to create elements for all of >them). We would provide standard LocaleElement elements (in this case they >don't have to have different names) under a section titled like >CommonLocaleElements. In this case we can't help with a validation whether >the list is complete. But an optional unit or user policy description >would not have to list them again redundantly (in fact I'd rather be >reluctant to overwrite them at all). > >Both ways have its advantage. >We collect a list of proposals for common text strings over the next weeks. > >3. Proprietary text strings >This is another section to help with the acceptance of the format by >consistent handling of text strings. >We want to further allow storing any text strings used by a driver, as we >think the localization within UPDF is highly optimized. >So a driver developer could communicate all text strings defines to the >UPDF developer, in which case the driver does not need any other defines >in header files or anywhere else. This might likely be used when the >printer manufacturer, who is supposed to develop the UPDF description, is >the driver developer as well. >Keep in mind that these proprietary string are not likely to be used, if >the UPDF description is rather meant to be anonymous, which means it shall >be used by any UPDF capable driver. >I would especially use this section, if a printer manufacturer tends to >write its own UPDF driver or cooperates with one driver developer for most >of the drivers. > >This could also be the proper place to store error messages, which are not >part of UPDF. We recommend some self-chosen discipline like specifying all >UI string with a prefix 'UI_String_' and all error messages with a prefix >'Error_Messages_'. > >4. Generic locales defaults >Since we have an ID per feature, this is no more necessary and has been >removed. > >As standard features like Media size, etc. have a predefined feature ID, >but generic features can be given any string as a feature ID, we could >split the Default_Feature attribute into two separate ones: >Predefined_Default_Feature and Proprietary_Default_Feature. This should >sound familiar to you from other functionality. > > >Please check the schema and the samples and respond to this email. >Especially send your proposals for common Name_ID attributes. We will >revisit locales end of February. So that's the deadline for changes. > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020212/4eb79c88/attachment.html From norbertschade at mediaone.net Tue Feb 12 16:30:14 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> the philosophy about command sequences Message-ID: <004601c1b40c$764ab7e0$a8948018@ne.mediaone.net> In L.A. we agreed on a redesign of command sequences and parameter handling. While we still are dedicated to the earlier directive to keep the real command sequences and parameters out of the technical device description and gather it in a separate file. But over the time we learnt that we cannot predict the number of parameters needed in every case. Predefine them as ComSeq_Parameter_1, ..._2, etc. was not the optimum solution either. Secondly we are facing features (e.g. Raster grahpic), which require dealing with more than one command sequence. Predefined element names don't look promising here neither. A third argument was brought in that the management of command sequences is inconsistent, as sometimes driven by features, sometimes by events. Ok, that was valuable feedback. And we worked it over. Now the management of command sequences is strictly initiated by events. The events describe the print stream and therefore refer to command sequences at the proper place. If no parameters are needed (like an init: E), the reference can be resolved in the command sequence xml file. The corresponding schema is now split into two sections: CommandSequences and Parameters. Both sections can have a practically indefinte number of elements CommandSequence_ID respectively Parameter_ID. As there must be exactly one leading element per schema, we define one: Commands. This one has the two sections underneath. If parameters are needed, they can be referred to within a command sequence, where you can point to a feature. This feature will have to provide a Command element with an attribute CommandSequence_ID, which will show exactly the same reference as originally in the event and serves as an identfier for the correct command sequence, and another attribute Parameter_ID, which is resolved in the Parameters section. This way we can easily manage more than one Command element, as we can identify them. See the schema and samples flying in tomorrow. I'm working on that right now. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020212/77731a86/attachment.html From norbertschade at mediaone.net Thu Feb 14 11:03:47 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> web site update Message-ID: <003501c1b571$2faec7c0$a8948018@ne.mediaone.net> Find all schema and xml files updated on the web site. Please access from the UPDF site. Let me know about editorial mistakes, which I likely made. I hope it's harder to catch me on the architectural side. To be clear: All latest features like user policies, events, etc. are implemented. This is quite a large update and worth checking. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020214/0a4dd2a0/attachment.html From norbertschade at mediaone.net Thu Feb 14 17:34:45 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> Fw: Booklets Message-ID: <000e01c1b5a7$cdf2eca0$a8948018@ne.mediaone.net> Just forwarding it to the group, as Jim seems to have some problems getting it out today. ----- Original Message ----- From: "Jim Sommer" To: "Norbert Schade" Sent: Thursday, February 14, 2002 4:59 PM Subject: Booklets > Within PrintMediaHandling we have MediaBookletList which has one or more > MediaBooklet elements but we haven't defined what function is to be > expected. I know of two ways that booklets can be implemented: > > 1) Booklets are a special case of 2-Up printing with the pages re-ordered. > If size is set to Letter then letter (8.5x11) paper is selected and > half-letter (5.5x8.5) page images are printed. Pages are ordered so that > when folded in half, a booklet or magazine is created. > > 2) Booklets are a special case of imposition with the pages re-ordered. If > size is set to Letter then ledger (11x17) paper is selected and letter > (8.5x11) page images are printed. Some implementations allow any page image > size with both dimensions smaller than letter to be printed on ledger > paper. Thus, 8x10 page images (assuming the printer supported a paper size > of 8x10) could be printed on ledger paper. Pages are ordered so that when > folded in half, a booklet or magazine is created. > > Implementation #1 has the advantage that booklets can be printed on any > size paper. Implementation #2 has the advantage that the driver (or > interpreter) does not have to do any scaling. > > Implementation #2 may have the advantage of allowing multiple image sizes > per paper size. However, if a driver is to support this function, it > becomes difficult to specify this in a predefined way. If this a device > feature then there isn't an issue. > > If we limit implementation #2 to the case of paper size twice the size of > page image size (ledger/letter, A2/A3, A3/A4, etc), then the function can > be seen as a composite feature of media size and booklet. > > So, I propose that MediaBooklet be a boolean. FALSE specifies normal > printing on the selected paper size. TRUE specifies that the driver do a > 50% reduction of page images, reorder pages for proper booklets (inserting > blanks if required), and printing on the selected paper size. > > Jim > mailto:sommer@granitesystems.com > 978-486-3068 > From norbertschade at mediaone.net Fri Feb 15 12:19:49 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> composite features Message-ID: <002d01c1b644$f931b3e0$a8948018@ne.mediaone.net> We have finished the current design for composite features. Find the schemas and sample xml files on the UPDF site. I suppose everybody has a feeling now what you can accomplish with composite features (c.f. called below). You can basically combine any two or more basic features to a higher level feature. Thinking this over you may better understand why we make some feature pretty basic. I consider it a significant advantage having the chance to save the settings of all basic features, but show something more user friendly in the UI. The sample implementation on the web site shows a 'Media' c.f. with media size, type and source involved. Might be a common sample. We will develop another more elaborate sample in the area of booklets the next days. If you follow that and understand each detail, you should have the essence of c.f. very well. Do you remember that I referred to c.f. as one of the four pillars more than a year ago? Now you may see why I like it so much. Not to mention that I consider it unique to UPDF. Some things you may want to check in detail: 1. See the DominantFeature attribute to the CompositeFeatureList. We don't force a driver to work a certain way, but recommendations may help with a better support. That attribute is single, optional. Means it can refer to one feature. In the sample it's media size. If there is a dominant feature I would recommend to show the defined c.f. in the UI, but automatically remove the composing features from the normal dialogs and make them available in a subdialog collectively. This is an assumption we make in the UPDF standard. If there is not, you may leave them at their usual locations in the standard dialogs. You can always define additional interdependencies to hide the one or the other control. With a dominant feature the special c.f. kind of overwrites the dominant feature. That's why we have an optional Name_ID to the CompositeFeature element. In the sample we want media size to be overwritten by Media and the new Name_ID shall be reported to the OS and then show up in the page setup of the applications. Makes sense? If you want to practice, here's the proposed task: Combine all media types and sources into one merged list of sources like used in a number of today's drivers. And now judge how much code you may need to accomplish that in a monolithic driver - just for this single implementation. 2. If you have a dominant feature, it makes all the other features of a c.f. non-dominant automatically. In our sample that's especially the case with media source. We don't want all the media sources to show up in applications' page setup any more. It would open the door to misselections. We only want the AutoSelect to show up or we could even create a dummy media source with a string "Source is selected by size". That leads us to the Non_Dominant_Representative attribute, assigned to all feature lists. It's mostly mandatory (only optional for media size and c.f.) and defines one record of the corresponding feature as the fall back to be used within c.f., e.g. given above mentioned dummy or the AutoSelect record. Another nice side effect is that you made the entry unchangeable (as it is just one). This attribute handles some useful stuff when it comes to communicating setting to the OS. 3. The UserExtensible attribute to the CompositeFeatureList is a boolean and indicates that the driver shall allow the user to create and manage his/her own records additionally to the predefined ones, if set to true. It's up to the driver how to implement that properly. I hope the other stuff is more or less self-explaining. We have learnt some of our lessons by practicing. During practice there certainly will be the point when you'll say "Wow! Not bad. Now I know." We are working on a sample driver to allow you trying your sample out. As I always say: Now that I have that stuff in my mind at a leading position, you'd get quite some solid answers to any questions. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020215/14742f61/attachment.html From norbertschade at mediaone.net Sat Feb 16 16:05:58 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> proprietary IHV functions Message-ID: <000c01c1b72d$bb566fe0$a8948018@ne.mediaone.net> Level 1 of UPDF will not support any proprietary function call to an IHV library. That does not mean we are not thinking about it. The format does not support the definition of raster compression (however the reference to a predefined list), the complete replacement of raster graphic, any kind of download, raster interleaving or other candidates for a proprietary library. Depending on the interest and the will of contribution we might talk that over. I could imagine something like predefined function calls with a list of predefined parameters, a list of tasks a specific function is supposed to provide and the proper reference place for a call. Any ongoing effort in that area also depends on the acceptance and the implementation of the current UPDF level. I just don't want anybody to get the feeling we don't acknowledge that functionality. Especially in the current process where we start discussing details about raster graphic, color and halftoning we know that there is a huge amount of proprietary information an IHV is not willing to share. We will concentrate on the rather common and public information. That intention should please explain some limitations we set for ourselves in this phase. Our target is to provide a description for correct output, not necessarily for ultimate quality for e.g. raster graphic because of the reasons mentioned above. Any driver developer can feel free to develop a UPDF driver with additional functionality supporting the proprietary features considered IP. As a chair I feel responsible to keep our job on a realistic level and schedule. If more people and companies volunteer to contribute we can talk about extending our targets. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020216/fa66b315/attachment.html From norbertschade at mediaone.net Sat Feb 16 16:59:25 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> halftoning Message-ID: <001d01c1b735$33144280$a8948018@ne.mediaone.net> We will support halftoning on the host by offering a place to specify matrices in predefined sizes of 8x8, 16x16 and 32x32. If a driver is not supporting all of the predefined sizes, it is supposed to provide internal fallbacks. If a UPDF description provides 16x16 or 32x32 matrices, do not expect it to provide 8x8 matrices additionally for fallbacks. We will support the selection of device internal halftoning by sending the proper command sequences at the proper place within a print stream. We think we can do that object specific (text, vector, raster), if required for a device. Be prepared to use a composite feature to accomplish that. We will not support downloading a halftoning matrix for any object. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020216/d12fe9b9/attachment.html From norbertschade at mediaone.net Tue Feb 19 18:33:09 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> zooming element names Message-ID: <000c01c1b99d$ca697f00$a8948018@ne.mediaone.net> Two simple renames: MediaZoomingBySizeList is renamed MediaTargetSizeList. MediaZoomingAutomaticScalingList is renamed MediaScalingList. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020219/f809b944/attachment.html From norbertschade at mediaone.net Tue Feb 19 18:57:26 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> code flow booklet Message-ID: <001701c1b9a1$2ea93980$a8948018@ne.mediaone.net> The latest booklet spec has a Predefined_ID with only 'Unsorted' and 'Sorted'. Not yet on the web site! The code flow for a booklet implementation is supposed to work as follows: If 'Sorted' is selected, the driver has to provide a proper page flow. Implicitely this setting tells the driver that two logical pages per physical page are required as well as a duplex setting of short-edge. If 'Unsorted' is selected, this impies a duplex setting of simplex. A booklet setting overwrites the duplex setting, but we recommend to write a proper interdependency additionally. Booklet pages are supposed to be positioned centered by default. That would do for a simple booklet feature, realized as a check box. If booklet is part of a composite feature (the driver has to check for that), check whether target size is part of the composite feature as well. If so, check whether the target allows for two original sizes (e.g. Letter on Ledger, A4 on A3). If not, the driver is supposed to realize booklet by scaling. If so, by imposition. If MediaScaling is part of that c.f., check the setting. Default is centered! This would take affect in a sample like 'A5 on A3 Booklet', which would not be the standard case. We do not support virtual sizes for booklet printing. That means, if A5 is not part of the media size list, 'A5 on A4 Booklet' can not be realized. Comments??? Somebody like me may design a 'Media' c.f. with booklet as a component. This may result in the following records: Letter/Auto tray Letter/Tray1 Letter/Tray2 Letter/Auto tray Booklet Letter/Auto tray on Ledger Booklet Verify that the application is always thinking in Letter size. When you practice that, you should fully understand the implications. Otherwise ask now, as this is the time. This is my (personal!!!) approach how to implement a media feature. The user has one selection for a media with all media features selected in the background. This is not supported by any other device description than UPDF available today, not even close. By this implementation the driver can prevent the user from a number of errors he/she can do with other drivers. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020219/f73c90f7/attachment.html From norbertschade at attbi.com Tue Mar 5 11:51:38 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> Fw: Edge To Edge Printing Message-ID: <003901c1c466$049eaa60$a8948018@ne.mediaone.net> just a forward for Jim > > > >I brought this up a while ago but I'd like us to consider adding a feature > >for edge to edge (full bleed, zero margins, what ever you want to call > >it). I know this could be done using a generic feature and > >interdependencies but it seems like a common enough function that it > >should have its own specific feature. > > > >This feature would be used by printers that support both "compatible" or > >"standard" margins and no margins (printable area is the media size). When > >this feature is set to FALSE, the margin values specified with each media > >size would be used. When set to TRUE, margin values of zero would be used > >for all media sizes and rotations. > > > >Printers that only support either standard margins or no margins would not > >need to specify this feature. > > > >Jim > > mailto:sommer@granitesystems.com > 978-486-3068 > From norbertschade at attbi.com Tue Mar 5 11:56:26 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> Fw: Margins/Edge To Edge Message-ID: <004301c1c466$b044ed20$a8948018@ne.mediaone.net> and another one from Jim with a slight modification to the first edge-to-edge proposal > > I'd like to modify my request for an edge to edge feature. What I think we > really need is a "Margins" feature. This feature would have three settings: > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE in > my previous email. > 2) Printer Margins - This would be the same as setting Edge To Edge to > FALSE in my previous email. > 3) User Margins - This would allow the user to enter custom margins values > that are larger than the printer margins. > > Comments? > > If you forwarded my email to the group, it never made it. I didn't receive > it and I just looked in the archive and it's not there. I hope you haven't > lost contact too. > > Jim > > mailto:sommer@granitesystems.com > 978-486-3068 > > From jsommer at bellatlantic.net Wed Mar 6 13:45:41 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> Test Message-ID: <4.3.2.7.2.20020306134530.00c6fdc0@mailbox.bellatlantic.net> Please ignore. Jim mailto:sommer@granitesystems.com 978-486-3068 From norbertschade at attbi.com Fri Mar 22 10:20:33 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: Fw: UPD> Fw: Margins/Edge To Edge Message-ID: <005801c1d1b5$1c5c95c0$a8948018@ne.client2.attbi.com> While I'm implementing this into the standard I'd like to contradict to the third option. Isn't that a driver feature independent from any device functionality, which could be always added depending on the driver's philosophy? I still favour a boolean constraint. Norbert Schade ----- Original Message ----- From: "Norbert Schade" To: "UPD group" Sent: Tuesday, March 05, 2002 11:56 AM Subject: UPD> Fw: Margins/Edge To Edge > and another one from Jim with a slight modification to the first > edge-to-edge proposal > > > > I'd like to modify my request for an edge to edge feature. What I think we > > really need is a "Margins" feature. This feature would have three > settings: > > > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE in > > my previous email. > > 2) Printer Margins - This would be the same as setting Edge To Edge to > > FALSE in my previous email. > > 3) User Margins - This would allow the user to enter custom margins values > > that are larger than the printer margins. > > > > Comments? > > > > If you forwarded my email to the group, it never made it. I didn't receive > > it and I just looked in the archive and it's not there. I hope you haven't > > lost contact too. > > > > Jim > > > > mailto:sommer@granitesystems.com > > 978-486-3068 > > > > > From jsommer at bellatlantic.net Fri Mar 22 10:48:10 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> Fw: Margins/Edge To Edge In-Reply-To: <005801c1d1b5$1c5c95c0$a8948018@ne.client2.attbi.com> Message-ID: <4.3.2.7.2.20020322103532.00c431f0@mailbox.bellatlantic.net> Normally I'd agree with you - in fact that was the thought behind my original proposal. However, by creating an edge to edge feature instead of a margins feature, we're ignoring the common third setting (user defined margins) and requiring the driver to merge it's user margin function with the optional edge to edge feature. I think it's easier for a driver that doesn't support user margins to ignore that element than it is for a driver to do the merge (although I admit that either way it's a fairly simple thing to do). The compelling reason for me is the fact an edge to edge feature is just plain incomplete. It really needs to be a margins feature in order to completely specify all possible settings. Jim At 3/22/2002 10:20 AM, Norbert Schade wrote: >While I'm implementing this into the standard I'd like to contradict to the >third option. >Isn't that a driver feature independent from any device functionality, which >could be always added depending on the driver's philosophy? >I still favour a boolean constraint. > >Norbert Schade >----- Original Message ----- >From: "Norbert Schade" >To: "UPD group" >Sent: Tuesday, March 05, 2002 11:56 AM >Subject: UPD> Fw: Margins/Edge To Edge > > > > and another one from Jim with a slight modification to the first > > edge-to-edge proposal > > > > > > I'd like to modify my request for an edge to edge feature. What I think >we > > > really need is a "Margins" feature. This feature would have three > > settings: > > > > > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE >in > > > my previous email. > > > 2) Printer Margins - This would be the same as setting Edge To Edge to > > > FALSE in my previous email. > > > 3) User Margins - This would allow the user to enter custom margins >values > > > that are larger than the printer margins. > > > > > > Comments? > > > > > > If you forwarded my email to the group, it never made it. I didn't >receive > > > it and I just looked in the archive and it's not there. I hope you >haven't > > > lost contact too. > > > > > > Jim > > > > > > mailto:sommer@granitesystems.com > > > 978-486-3068 > > > > > > > > From norbertschade at attbi.com Mon Apr 1 10:51:44 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> mistake in job settings of generic features Message-ID: <000f01c1d995$200c0e20$a8948018@ne.client2.attbi.com> There was an editor's mistake in the JobSetting elements of the generic features. The entry for Job_Keyword and Job_Parameter were switched in all four features. Repaired, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/8026b811/attachment.html From norbertschade at attbi.com Mon Apr 1 10:54:18 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> MediaMinimumMargins Message-ID: <001801c1d995$7d1ea780$a8948018@ne.client2.attbi.com> After the change concerning MediaMimimumMargins a few days ago I now have removed the generic feature EdgeToEdge from the sample and transferred all the entries into the new feature for minimum margins. Finished, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/7b9f409d/attachment.html From norbertschade at attbi.com Mon Apr 1 11:02:28 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> agenda item: halftoning Message-ID: <002101c1d996$9fccb780$a8948018@ne.client2.attbi.com> We have finished the final proposal for halftoning. We do not support any kind of download in UPDF. That is valid for halftoning as well. We do support separate halftonings for text, vector and raster objects. Only for raster objects you can specify a host matrix. Predefined sizes for host matrixes are 8x8, 16x16, 32x32. Command elements can be used for all three object styles. Not yet provided in the sample. Can somebody sent me a simple standard 8x8 matrix? Please check whether you can accomplish all you need with the current design. This will be one major agenda item. Prepare samples. In case we'll decide on making this the official design the TBD_ prefix will be removed right after the conference. Not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/6308b937/attachment.html From norbertschade at attbi.com Mon Apr 1 11:35:48 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> agenda item: driver specific locale xml Message-ID: <002c01c1d99b$47cc1580$a8948018@ne.client2.attbi.com> While we have a nice schema to store all UPDF related text string entries, we do not expect these to be all text strings a driver is using. Just to give a sample we are not yet supporting any button strings nor error messages and I guess there is a whole lot of other string areas commonly used by a driver. However these text strings are typically quite driver specific, meaning two drivers have a different set of them. We are discussing a solution that all driver developers provide all their text strings exceeding the UPDF device description in a standardized way. The simplest idea is to use the UPDF locale schema for this purpose as well. The UPDF specification is not involved in naming these driver specific locale xml files. They are likely different per driver. Nor do we provide a place to store these names, namely not in the device configuration file. Every driver would know about its own files anyhow. This is considered a contribution to an easy translation process of all text strings with one consistent structure. Just to mention it: We are not concerned about hot keys, as the format does not specify where in a user interface a feature control may appear. This heavily affects the Locale elements MandatoryLocaleElements and ProprietaryLocaleElements, which perhaps both would be moved to the driver locale files. This item will be finally decided at the conference. It would ease the process if you provide your comments upfront. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/97e79aaa/attachment.html From norbertschade at attbi.com Mon Apr 1 12:33:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> public keys Message-ID: <004e01c1d9a3$587f02e0$a8948018@ne.client2.attbi.com> During implementation we learnt that a slightly different strategy with the public keys is of advantage. The driver can check the value of any feature attribute any time, at least in theory. The driver knows the interface to the operating system and the applications best as well. So it does not seem right to create public keys for platform settings (like provided in a devmode structure under Windows). An example is DRV_Copies, which had been created as a public key. This entry is removed from the list. Any driver has to check if a driver's feature is overwritten by the application's job setting. This may vary a lot from platform to platform. With the sample of copies the driver knows the setting of copies in the driver's user interface, but has to check, if the application is sending a print job with a different copy setting, which would have a higher priority than the setting in the driver's UI. Comments? Changed, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/7913cdfc/attachment.html From norbertschade at attbi.com Mon Apr 1 12:49:53 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> ID mandatory Message-ID: <005d01c1d9a5$a1658220$a8948018@ne.client2.attbi.com> Some of the latest details on the reflector are initiated by the driver implementation we are working on heavily the last weeks, while most contributions the years before were purely based on the specification of the format. That demonstrates as well that we have been able to ease the implementation work over time. The newest change is to make the ID attribute mandatory in every element where it is not fixed. This allows the code to rely on a unique value per feature. Finished, not yet on the web. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/3911be59/attachment.html From norbertschade at attbi.com Mon Apr 1 12:54:12 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> syntax of margin values Message-ID: <006601c1d9a6$3b54db60$a8948018@ne.client2.attbi.com> To further ease the driver implementation we have changed the syntax for margin values slightly. While you found values like 'margin_left_0.250in' before, which is a very similar syntax to the media size syntax in the predefined media standard, we now have eliminated the first two components and you will find values like '0.250in' in future. this helps avoiding wrong entries (e.g. 'Left = margin_top_0.250in'), while the same routing can now be used to interpret all margin values. Finished, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/e97261d1/attachment.html From norbertschade at attbi.com Mon Apr 1 13:02:22 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> update web site Message-ID: <006f01c1d9a7$5fe08500$a8948018@ne.client2.attbi.com> I have updated the UPDF web site. So you will find all changes announced so far today on the web site in directories 'XML Schemas' and 'XML Samples based on schemas'. You can use the links provided on the UPDF site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/0de2c0a1/attachment.html From norbertschade at attbi.com Thu Apr 18 20:06:45 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> proposed agenda for 4/19/02 Message-ID: <001301c1e736$180c6400$a8948018@ne.client2.attbi.com> 1. Current development status of the UPDF specification and the host implementations This will include some demonstrations to the extent that everybody feels confident with the current level. Review of command sequences. No more job settings. 2. Locales 2.1. Mandatory strings 2.2. Driver strings 2.3. New sections: Error messages, etc.??? Final decision. 3. Halftoning Final decision. 4. Raster graphic and color We have prepared a real proposal. Target is to agree to this proposal, probably in a reviewed version. Further smaller changes are expected during host implementation, especially in the area of color. 5. User interface structure Do we want that as part of level 1? 6. Some ideas Although not planned for level 1, we think about some ideas from time to time, as there are: Interleaving, Hooks, Bidirectional communication. 7. Outlook One more conference considered necessary (Portland?) for technical closure of spec. A second one possible with concentration on documentation. Finishing procedures, last call, etc for UPDF level 1. Business plan for host implementations. Elaborated device descriptions from IHV required. See you tomorrow Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020418/a0edb5b0/attachment.html From harryl at us.ibm.com Thu Apr 18 20:24:49 2002 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:59 2009 Subject: UPD> proposed agenda for 4/19/02 Message-ID: I'd like to suggest we also discuss possible use of UPDF in the context of the new PSI project. This topic came up this week at the first PSI meeting. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Norbert Schade" Sent by: owner-upd@pwg.org 04/18/2002 06:06 PM To: "UPD group" cc: Subject: UPD> proposed agenda for 4/19/02 1. Current development status of the UPDF specification and the host implementations This will include some demonstrations to the extent that everybody feels confident with the current level. Review of command sequences. No more job settings. 2. Locales 2.1. Mandatory strings 2.2. Driver strings 2.3. New sections: Error messages, etc.??? Final decision. 3. Halftoning Final decision. 4. Raster graphic and color We have prepared a real proposal. Target is to agree to this proposal, probably in a reviewed version. Further smaller changes are expected during host implementation, especially in the area of color. 5. User interface structure Do we want that as part of level 1? 6. Some ideas Although not planned for level 1, we think about some ideas from time to time, as there are: Interleaving, Hooks, Bidirectional communication. 7. Outlook One more conference considered necessary (Portland?) for technical closure of spec. A second one possible with concentration on documentation. Finishing procedures, last call, etc for UPDF level 1. Business plan for host implementations. Elaborated device descriptions from IHV required. See you tomorrow Norbert Schade From norbertschade at attbi.com Mon Apr 22 13:36:10 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> ICC profiles Message-ID: <000a01c1ea24$332e9e60$a8948018@ne.client2.attbi.com> We have agreed that we will support device color handling in UPDF. Although we are not really working with ICC profiles within the spec, it was proposed to list references for them, so that a driver/client would know which ones it can expect to find. this is more or less an installer function, but ok. I propose to add a new tag to the device and option configuration files to do that. A protocol managing the transfer from a device or network would then find all necessary file names in the configuration files. More than one profile could be listed (optional, multiple). The spec would not tell the driver when to use which. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/82ff3d51/attachment.html From jsommer at bellatlantic.net Mon Apr 22 14:38:23 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> ICC profiles In-Reply-To: <000a01c1ea24$332e9e60$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020422143743.00bc4320@mailbox.bellatlantic.net> I agree that the device configuration file is the right place to reference the ICC profile. At 4/22/2002 01:36 PM, Norbert Schade wrote: >We have agreed that we will support device color handling in UPDF. >Although we are not really working with ICC profiles within the spec, it >was proposed to list references for them, so that a driver/client would >know which ones it can expect to find. this is more or less an installer >function, but ok. >I propose to add a new tag to the device and option configuration files to >do that. A protocol managing the transfer from a device or network would >then find all necessary file names in the configuration files. >More than one profile could be listed (optional, multiple). The spec would >not tell the driver when to use which. > >Comments??? > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/e0f919d6/attachment.html From norbertschade at attbi.com Mon Apr 22 16:51:27 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> web site update Message-ID: <000a01c1ea43$c4e2f080$a8948018@ne.client2.attbi.com> I've updated the schemas and xml file on the UPDF web site. The latest agreed functionality is already incorporated. ColorHandling, Halftoning and RasterObjects have lost its TBD_ status and are fully activated. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/223578c5/attachment.html From norbertschade at attbi.com Mon Apr 22 19:14:40 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> color handling for experts Message-ID: <003201c1ea53$7b208b00$a8948018@ne.client2.attbi.com> We have activated the latest color handling design after last Friday's meeting in Boston. the group agreed to the design as it was with only few comments. we moved the PlaneImplementation attribute up one level from the Plane element to ColorMode, as this has to be consistent per ColorMode. the attribute is now mandatory to avoid consistency problems of a device description, although the entry is redundant in case of Predefined_ID=monochrome (Predefined_ID is the attribute with the higher priority). Don't create a Plane element for monochrome either. if PlaneImplementation=PerPixel, don't create a Plane element either. A driver should ignore it anyhow in this case. we have added an entry (PerPixel) to the data type plane-implementation-enum. The UPDF spec assumes that the driver will get a RGB (not necessarily sRGB) input and can create color output for R, G, B, C, M, Y, K, W planes. you may comment on the white plane. The spec expects device color handling for the remaining functionality. The spec expects the device to understand 8bpp per plane. By limiting the spec to 8bpp, we want to make it easy for all host implementations, as all drivers must support all implementations. Additionally we think that many devices support 8bpp. We know there are other solutions out there. In case an IHV wants to develop a host implementation for different bits per pixel or would provide a huge number of device descriptions plus detailed information how to manage it, so that we can create a proper schema and drivers can properly handle it with short-term development time, please step up and contact us now. Some MS Windows stuff, which can pop up in a similar way under other platforms as well: the dmColor setting is provided by the color-mono-enum attribute. the dmBitsPerPel setting is supposed to be 24 for all color modes. The dmICMMethod setting needs a minute. Check if you agree with the following description, which would become valid if nobody complains the next days. We assume there is an ICC profile tag in configuration schemas (see previous email today). In this sample we do not assume the driver has its own color correction functionality. A driver may want to show an ICM control in the UI with possible entries of SYSTEM, NONE and/or DEVICE. This is supposed to be a driver feature. UI strings should be provided in the driver's locale xml file. 1. There is no device halftoning nor ICC profiles. The only entry is NONE. 2. There is device halftoning, but no ICC profiles. Entries NONE and DEVICE (default). 3. There is no device halftoning, but ICC profiles. Entries NONE and SYSTEM (default). 4. There are device halftoning and ICC profiles. I'm not sure if I'd do that. But if, my driver would treat the ICC profiles with a higher priority. Under Windows that may result in entries NONE, SYSTEM (default) and DEVICE. same under platforms with the same environment. If the platform does not support ICC profiles, the driver should use the device halftoning. If the platform supports ICC profiles, but no flag to communicate any related driver setting to the OS API, the driver should announce the ICC profiles, but ignore the device halftoning. Please comment if you have any preference for dmICMIntent. Otherwise we leave that to the driver and treat it as a driver feature. Do we want a Predefined_ID for dmDitherType? this could turn out to be quite tricky, as we have three different halftoning elements, in which case we could concentrate on the RasterHalftoning. Some said during the meeting they have to think more about the whole block of raster graphic, color hanlding and halftoning, which I understand. however this is the time to comment. We are quite confident that the current design (perhaps with some adjustments due to dmICMIntent or dmDitherType) can very well work as a generic description of color and graphic related device capabilities. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/0ef7248f/attachment.html From norbertschade at attbi.com Tue Apr 23 13:43:30 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> Latest Meeting Minutes Message-ID: <001101c1eaee$621f0280$a8948018@ne.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/e68fd3c5/Latest_Meeting_Minutes.htm From norbertschade at attbi.com Tue Apr 23 15:29:15 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> User Interface Message-ID: <002901c1eafd$27de7380$a8948018@ne.client2.attbi.com> At the conference last week we could only spend little time on the question whether UPDF, level 1, needs a rough description of the intended user interface dialog structure. During the meeting we saw a number of problems popping up with that intention. 1. Might become a quite complex section. We would have to limit ourselves to a certain common denominator, as we request any UPDF driver to support the full set of functions if it uses a feature. 2. Perhaps several user interface structures for different platform environments (PC desktop, cell phones, cameras, etc.). Please provide your comments the next two weeks. Would it help you or rather be an obstacle to have a UI structure as part of UPDF??? Richard Hart from Compaq will do some investigation about TLC, which apparently could be used as a run-time language for dialog handling. that would be another direction. Other helpful alternatives in sight? We will leave the TBD_UserInterface structure in the schema for a while for demonstration purpose to ease the discussion, although we are not using it in the sample. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/f6b2d127/attachment.html From norbertschade at attbi.com Tue Apr 23 16:31:01 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> greyscale Message-ID: <000e01c1eb05$c8cfa5e0$a8948018@ne.client2.attbi.com> Now that we have raster graphic and color structures, we can discuss a number of models. Let's think about a printer which is kind of PCL like. 1. A clean bitonal black/white monochrome printer. that's a clear case. One ColorMode record with Predefined_ID=monochrome, which means the PlaneImplementation attribute will be ignored (set it to PerPixel anyhow). No Plane element will be defined. I would define the ColorHandling feature hidden (Appearance). 2. A RGB color device. You may define the same ColorMode record as in #1. Additionally you likely have a color record, perhaps with PlaneImplementation=PerScanline (or PerPixel depending on your favorite implementation and the drivers' capabilities). Three Plane elements defined with the proper colors, Appearance active. Nothing fancy. 2.a. The #2 device with an additional greyscale mode. Implementation can vary. It might just be an additional job command sequence. So you would create an additional ColorMode record with the proper entries (only the Command element would be different). Not really complicated with a cautious implementation. 3. Hypothesis: There is a new device, which needs a true greyscale input. Condition 1: the UPDF driver has to support a color to greyscale conversion. Do we expect a UPDF driver to do that? Condition 2: The ColorMode record for greyscale would have one black plane (my personal opinion!), but no other planes. Keep in mind that the Predefined_ID of ColorMode is meant to tell the operating system about the color capabilities. this attribute has nothing to do with what the driver is sending to the device! Does that sound reasonable to you or do we just forget about #3? You may take this as a case study to check the power and flexibility of the spec. Please contribute to the discussion. it educates us all. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/88b6c849/attachment.html From norbertschade at attbi.com Thu Apr 25 15:17:07 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> ICC profiles Message-ID: <000a01c1ec8d$caf237a0$a8948018@ne.client2.attbi.com> we try to solve some relationship to ICC profiles. is it possible to build one profile with more than one media type and/or more than one dither type??? short and quick note appreciated. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020425/5620dec0/attachment.html From norbertschade at attbi.com Fri Apr 26 15:43:49 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> User Interface, 2. Message-ID: <000e01c1ed5a$aff086a0$a8948018@ne.client2.attbi.com> We have spent a bit more time on the design of a user interface structure and think this should be the proposal to discuss. 1. We have moved the user interface section to the Locale schema. that allows a different UI for different locales (think about Arabic, Hebrew, Asian, etc.). 2. The design units are pixel. The developer of a device description is strongly recommended to follow a standard VGA (640x480). This should leave enough room for design. Higher resolution are expected to go with the designed positions. If a driver knows about the screen resolution and it's lower than VGA, it could downsize by recalculating the values. Therefore it needs to rely on a reference resolution. 3. As you can see in the latest design, there is a Logo attribute to the DeviceConfiguration element of the device configuration schema. This is supposed to be a file name reference for one picture and would typically be used for a company logo. When you check the Control element you see that you can use that picture everywhere in the UI, even multiple times. The only supported picture format would be JPEG. 4. A Configure dialog like any other dialog considered part of Device Properties is not part of a device description. It is a generic dialog created by the driver by reading and interpreting the device's configuration files. 5. Composite features can be handled as any other feature in the UI design. As we discussed the driver may offer a subdialog to view and/or edit the components of a c.f. as well as to add a new set of components or remove a user defined one. This functionality is supposed to be supported under Device Properties and cannot be influenced by the UI design. 6. A dialog for managing custom media sizes is as well considered part of Device Properties and not available for UI design. 7. As you can see a PushButton can be specified as a special predefined button (OK, Cancel) or to open a subdialog - again a predefined dialog (About) or any of the UPDF design dialogs (by referencing the dialog ID). One button can only open one dialog. If you think further about this you see that tabs on tabs are not possible. 9. The order of the dialogs is supposed to be: system dialogs, generic driver dialogs, UPDF dialogs in the order they are designed. 10. Labels As you can see the latest design show a Label element under some controls. That means you are absolutely free in designing the position and size of any feature control (like a combo box) and its label. Regards from Murphy! Quintessence: If we'd allow a UI design as part of the UPDF specification, we consciously limit ourselves to a certain set of functionality, as every driver is expected to interpret all tags properly. However the UserInterface structure will certainly be optional. And a driver is allowed to ignore any designed section while working with its own design. We do not think of allowing multiple user interfaces per locale, but just one. While the design screen is supposed to be a graphic desktop of some kind, we think the structure can also be used by a command line type of desktop (which would ignore position attributes, of course). Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/b0823362/attachment.html From norbertschade at attbi.com Fri Apr 26 15:46:18 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> User Interface, help Message-ID: <001701c1ed5b$093723e0$a8948018@ne.client2.attbi.com> An important detail: The UPDF spec will not cover any help file support. However we have added a Help_ID attribute to the Control element of the user interface design - another argument to manage the user interface in the locale schema. This is supposed to enable a context-sensitive kind of help per control. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/db40a8c5/attachment.html From jsommer at bellatlantic.net Fri Apr 26 16:25:46 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> User Interface, 2. In-Reply-To: <000e01c1ed5a$aff086a0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020426161940.00bb7e88@mailbox.bellatlantic.net> This looks good to me. My one comment is on: >9. The order of the dialogs is supposed to be: >system dialogs, generic driver dialogs, UPDF dialogs in the order they are >designed. I would day the order is: system dialogs, UPDF dialogs, generic driver dialogs When a driver UI is presented, I think it should present the most commonly used features on the first dialog. Therefore I think the UPDF dialogs should come first since they are setting the basic features of the printer (media size, media type, source, copies, etc) and the driver dialogs are setting advanced features (watermarks, custom paper sizes, device configuration, composite feature editing). Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/ef450378/attachment.html From jsommer at bellatlantic.net Fri Apr 26 19:14:43 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> Compressions Message-ID: <5.1.0.14.2.20020426171234.00bc4e20@mailbox.bellatlantic.net> I would like to propose the following initial list of compressions for raster objects: PCL5 - the compression methods as defined by the PCL5 spec (uncompressed, RLE, TIFF, delta row, adaptive) PCL6 - the compression methods as defined by the PCL6 level 1.1 spec (uncompressed, RLE) PCL6_JPEG - the JPEG compression method as defined by the PCL6 level 2.0 spec PCL6_DELTAROW - the delta row compression method as defined by the PCL6 level 2.1 spec PS - the compression methods as defined by the PostScript level 2 spec (uncompressed, RLE, JPEG) PS_LZW - the LZW compression method as defined by the PostScript level 2 spec PS_FLATE - the Flate compression method as defined by the PostScript level 3 spec JPEG - standard JPEG compression in JFIF format JBIG2 - standard JBIG2 compression FAX_G3 - CCITT Group 3 fax compression FAX_G4 - CCITT Group 4 fax compression If anyone knows of any other compression methods that are commonly used by printers we can certainly add them. Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Mon Apr 29 08:12:02 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> color handling for experts In-Reply-To: <003201c1ea53$7b208b00$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020429065627.00ba4500@mailbox.bellatlantic.net> I think that we should have Color Correction Method and ICC Intent features but not dmDitherType. The Color Correction Method feature should have the three settings that Norbert outlined (none, device, system). This feature will allow a user to enable and disable color correction. If a device has both an ICC profile and device color correction, then the user can also choose between the two methods. Since we are saying that we support color correction using ICC profiles, then we should support the once basic ICC control which is intent. The ICC Intent feature should have four settings (perceptual, media-relative colorimetric, saturation, ICC-absolute colorimetric). These settings are defined in the ICC profile specification. This feature will allow the user to direct ICC profile-based color correction for their particular print job. I don't think that we should have a feature associated with dmDitherType. It's use in Windows is not clear - does Windows ICM do the dithering or is it just an indication of how the driver or device is supposed to do the dithering? This is a global setting whereas we already have object specific settings so what would the interaction be? I think we should just leave this out unless someone can come up with a clear case for adding support. Jim From jsommer at bellatlantic.net Mon Apr 29 09:05:49 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> greyscale In-Reply-To: <000e01c1eb05$c8cfa5e0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020429085651.00bcfb90@mailbox.bellatlantic.net> >3. Hypothesis: There is a new device, which needs a true greyscale input. >Condition 1: the UPDF driver has to support a color to greyscale >conversion. Do we expect a UPDF driver to do that? >Condition 2: The ColorMode record for greyscale would have one black plane >(my personal opinion!), but no other planes. I think we need to address the case of grayscale printing on a color device. I know of devices that always print in color unless grayscale data is sent. What if we added a DeviceFeature attribute on the ColorMode element to indicate if the driver needs to create the grayscale data or if the command sequence will cause the device to do the grayscaling? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020429/f72cb8fc/attachment.html From norbertschade at attbi.com Mon Apr 29 13:24:38 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> media standardized names: media types Message-ID: <000a01c1efa2$be21a160$a8948018@ne.client2.attbi.com> in the spec mentioned above there is a list of predefined media types. ICC profiles have a special reference to media types as well. this is commonly considered a very Microsoft specific flag. it is reflected in wingdi.h of the DDK. please check values for Standard, Transparency, Glossy and user defined. When thinking about that for a moment it becomes clear that any driver has to announce the same media type values for the driver as are used within the ICC profiles. Otherwise Windows would make wrong assignments, a process which is not influenced by a driver. ICC media type consistency statement that means it is essential that predefined media types have the same predictable value used by drivers and ICC profiles. Request We need a public table with values for predefined media types as listed in the media standardized names spec. Either this has to be added to that spec (my favorite option) or we have to create such a list within UPDF. but this is not a UPDF specific condition. all drivers face the same development condition. Checking the rules for media types in Windows, it seems useful to me to reserve all values up to 255 for Microsoft and their predefined values (currently only 0, 1 and 2 are used). A list for other predefined media types should use the range from 256 to 511, while higher values are open for arbitrary types (would mean proprietary types in the UPDF language). Do you agree with my view of the conditions? Who should create the public list? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020429/aafa68e1/attachment.html From norbertschade at attbi.com Wed May 1 12:38:09 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> User Interface, 2. References: <5.1.0.14.2.20020426161940.00bb7e88@mailbox.bellatlantic.net> Message-ID: <002001c1f12e$94400de0$a8948018@ne.client2.attbi.com> reasonable input. fine with me. I will propose this way from now on. it is left to the driver anyhow, but I appreciate common behavior. Norbert ----- Original Message ----- From: Jim Sommer To: UPDF Sent: Friday, April 26, 2002 4:25 PM Subject: Re: UPD> User Interface, 2. This looks good to me. My one comment is on: 9. The order of the dialogs is supposed to be: system dialogs, generic driver dialogs, UPDF dialogs in the order they are designed. I would day the order is: system dialogs, UPDF dialogs, generic driver dialogs When a driver UI is presented, I think it should present the most commonly used features on the first dialog. Therefore I think the UPDF dialogs should come first since they are setting the basic features of the printer (media size, media type, source, copies, etc) and the driver dialogs are setting advanced features (watermarks, custom paper sizes, device configuration, composite feature editing). Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020501/22f7c07d/attachment.html From norbertschade at attbi.com Tue May 7 19:55:47 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> some small items Message-ID: <003301c1f622$b58fb6a0$a8948018@ne.client2.attbi.com> 1. is there interest to extend our list of DRV_keys to some job and user related variables??? samples could be: a.. job id b.. user name c.. user id d.. workstation e.. domain f.. application sending the document g.. document name may be you have a longer list. 2. we still think about the file formats we might support for pictures, if we support them in a UI. first idea was JPEG. what about gif??? target is to decide on one eventually. 3. I request bytes instead of kilobytes in the band_units_enum. the background I have in mind a quite dirty. may be the driver is not only concerned about a print head height or maximum input buffer, but also to create small enough snippets to allow an application (like a language monitor or what our Linux friends call a client) to hold the job for a moment and communicate to the device. I know this attribute would not be enough but it allows small snippets with a byte number. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020507/a0708735/attachment.html From jsommer at bellatlantic.net Wed May 8 07:28:58 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> some small items In-Reply-To: <003301c1f622$b58fb6a0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020508072634.00bd2e78@mailbox.bellatlantic.net> At 5/7/2002 07:55 PM, Norbert Schade wrote: >1. is there interest to extend our list of DRV_keys to some job and user >related variables??? > >samples could be: > * job id > * user name > * user id > * workstation > * domain > * application sending the document > * document name >may be you have a longer list. > I don't have a problem with this. In fact I would add job name to the list. >2. we still think about the file formats we might support for pictures, if >we support them in a UI. >first idea was JPEG. what about gif??? >target is to decide on one eventually. I believe that GIF has some patent issues with it. > >3. I request bytes instead of kilobytes in the band_units_enum. >the background I have in mind a quite dirty. may be the driver is not only >concerned about a print head height or maximum input buffer, but also to >create small enough snippets to allow an application (like a language >monitor or what our Linux friends call a client) to hold the job for a >moment and communicate to the device. I know this attribute would not be >enough but it allows small snippets with a byte number. > OK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020508/a306d324/attachment.html From norbertschade at attbi.com Thu Jun 20 08:40:56 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> meeting in Portland Message-ID: <001601c21857$bbcb9d20$a8948018@ne.client2.attbi.com> Alan, we talked a bit about the PSI group and its targets at our last meeting in Boston. Harry suggested that we'll exchange information between the UPDF and PSI standards to find out if we can help each other. Jim Sommer and I will be in Portland on Wednesday. So you would have two of the current three leaders of the UPDF group present. We will join your group - at least in the morning sessions. If you like, we could do some presentation, perhaps about an hour. Let me know, if you have some preferences. This may very well line up with the plenary next day and the attempt to find synergies between the various groups. Would do you think? I have subscribed to your list a minute ago, but do not know if it works already. so I'd prefer a direct copy of the answer. Is there any must-read document we have to study to get a feeling what your main objectives are, other than general knowledge what a print server might want to do? Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020620/7d286210/attachment.html From norbertschade at attbi.com Fri Jul 5 11:50:13 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> hw margins Message-ID: <001301c2243b$a6f771e0$a8948018@ne.client2.attbi.com> Change request based on the Portland meeting. hw margins before the change we had two different margin elements. We wanted the user to work with as few elements as possible. now that we have one only, the user may feel more convenient when doing the same procedure all the time. that's why we made the margins element mandatory. MediaSizeHardwareMarginsLandscape removed. MediaSizeHardwareMargins 1-2 elements with new mandatory attribute Orientation with margins-orientation-enum constraint. Device Description changed accordingly. Files not yet copied to the web. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020705/a8508115/attachment.html From norbertschade at attbi.com Mon Jul 8 10:32:20 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> Semantic model: media handling Message-ID: <001a01c2268c$4544aa00$a8948018@ne1.client2.attbi.com> I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020708/ea976b89/attachment.html From hamzy at us.ibm.com Mon Jul 8 18:49:58 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:04:59 2009 Subject: UPD> Re: [Foomatic] request for full PPD specification compliance Message-ID: > UPDF creators being obliged to use a free license would be GREAT, but I > think if the group would agree with that, they will open the liberty of > using MIT, BSD, or LGPL licenses as HP uses for HPIJS and their PPDs or > also IBM for Omni. But that would be no problem. The problem will be > when there are proprietarily licenced UPDFs. I was hoping for a simple, free license that I could easily point at. I do not think that the leader of the UPDF group would be opposed to requiring that the files use the license in order to comply with the UPDF specification. We should also place some education in the UPDF manuals/specs as for the need of a properly free license. Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at attbi.com Sun Jul 14 19:11:54 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> resolution and related features Message-ID: <003e01c22b8b$d868f1c0$a8948018@ne1.client2.attbi.com> We could define a syntax for Predefined_ID/Proprietary_ID in two-dimensional features like 'keyword' + '_' + horizontal value + 'x' + vertical value (leans heavily on the standardized media names spec). This could be used for virtual units: units_7200x7200 raster resolution resolution_600x600 positioning positioning_300x300 As a matter of fact we already use it for nup: nup nup_1x1 (new due to a change discussed in Portland, will be on the web within next days) would that solve everything so we could work with Predefined_ID/Proprietary_ID in all these features? General requirement for that kind of syntax: 1. The entry in the Predefined_ID follows the same syntax as the entry in the Proprietary_ID. 2. For positioning we cannot generally expect that a positioning command specifies both the horizontal and vertical dimension. So we have to tell about omissions. The simplest rule might be that the 'x' must be there, the value not necessarily. That would allow 'positioning_300x300', 'positioning_300x' as well as 'positioning_x300'. Another thought: We might remove the feature device resolution completely from our standard, as we consider it a generic feature. Drivers really don't use it for rendering, only for sending a JCL command to the device. Drivers don't even really save it in any kind of device capabilities structure other than just storing the last UI setting. And we could as well do some calculation in the command sequences, if the device resolution is 1200dpi and the raster resolution is 600dpi so that the positioning parameter has be multiplied by 2, as any value coming from the application/system will be based on the raster resolution. The fact that some raster resolutions only go with certain device resolutions, is a matter of dependencies and simple. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020714/a6a20402/attachment.html From norbertschade at attbi.com Sun Jul 14 21:05:55 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> Portland meeting minutes Message-ID: <00c401c22b9b$c613b220$a8948018@ne1.client2.attbi.com> Although there was no official UPDF meeting scheduled for Portland, Mark Hamzy, Jim Sommer and I joined parts of the PSI meeting and the full-day plenary to represent our interests. However we took the time to meet on Wednesday afternoon (6 hours) and Thursday evening (two hours) to discuss some open issues we could not resolve in emails and phone calls. These were the major issues: 1. ICC profiles We will add an element References under 'PrintCapabilities' like 'Features' and 'Objects. The only element underneath will be 'ICC_Profiles'. That way we can list as many profiles as we want and can select them with dependencies like features and objects. Expect to hear more the next days. 2. Hardware margins We have added an attribute 'Orientation' to 'HardwareMargins' and could now save an extra margins element for landscape. It's easier to implement it this way on the host. 3. Dependencies We shortened the term 'Interdependencies' to 'Dependencies'. The structure was changed as well. We do not support the definitions of 'OR' conditions any more. It is too complex to write a parser, which would understand all possible varieties of conditions. And we want to encourage people to read the xml on-the-fly. Now it is necessary to split previous 'OR' conditions into separate conditions. On the other hand we have a simpler structure. It is still possible to combine as many features as you want in one condition. And the complete action section is more or less unchanged. The attribute 'Relation' is now constrained to 'equal' and 'not-equal', as we did not find any sample where 'less' and 'larger' really was needed. More details to come for the interested expert. 4. Classifying identifyers In general we are intending to consistently work with Predefined_ID/Proprietary_ID attributes wherever possible. You will see a number of related changes. This eases the host implementation as well. 5. Syntax problems We were discussing some global syntax problems for some time, but we could solve all of them. One major change to accomplish that is to allow IHV to add their own namespace to UPDF if needed. The cases where useful of needed will be rare, but it provides for a consistent syntax all over the place when it comes to command sequences and parameters referenced within them. See samples coming up. 6. Common PWG Semantic Model The PWG declared the IPP concept the base for the common Semantic Model and defined a set of schemas to document that. We will check, how close UPDF already is to these structures and discuss open issues with them. That will be one of our main activities the next weeks. 7. UPDF as common base for device capabilities under IBM Linux solutions. There is some discussion going on in a Linux forum, where the PWG and IBM are actively contributing. One option is to take UPDF as their common format to store driver capabilities by using it. This is a very interesting approach and proves that the UPDF standard is on an excellent level. This is another activity we will persue in the near future. 8. Print Services As many may know there is a new group in the PWG community called Print Services. They are checking UPDF and probably may use some of the functionality to accomplish some of their targets. Another field where the hard work we did over the last years will pay out. We are supporting them as much as we can, as we consider that activity very close to a driver. 9. We invite all IHV to start some UPDF implementations, as we have the host implementations under MS Windows and IBM Linux working to quite a good level. Now it's the time to get device descriptions checked. So start writing them and let us know, if you need help. We will send another note through the PWG reflector to get the message around. You see we could cover a lot of bases in two very effective meetings. We do not plan to meet in Santa Fe, but most likely we will meet in New Orleans. In the meantime we will continue with the host implementation and finish the UPDF design for level 1 section by section. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020714/391464ed/attachment.html From harryl at us.ibm.com Wed Jul 17 11:34:40 2002 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:59 2009 Subject: UPD> RE: PS> Semantic model: media handling Message-ID: I like Bob's analysis. I think the Semantic Model will be most useful taking this approach. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "TAYLOR,BOB (HP-Vancouver,ex1)" Sent by: owner-ps@pwg.org 07/16/2002 09:13 PM To: Norbert Schade , Print Services group cc: UPD group Subject: RE: PS> Semantic model: media handling Hi Norbert, all, One of the things we (HP) have been suggesting for the semantic model is the separation of the raw "attribute/element" definitions from the structures/model that pull them together for a particular use. As you not, UPDF has done this structuring in a different way than IPP - which is also somewhat different than UPnP & PSI, etc. I'm not sure we want to try codify any one structure as part of the core semantic model - these will tend to vary by market segment and domain, and I'm not sure we can do this one-size-fits-all. What we would like to see, though, is common definition of the core "attributes/elements" - this seems much more reusable across models & domains. It does make sense, though, to publish some of the "common models" as at least examples of structural models - IPP, UPDF, etc. are likely candidates for this. This exposes some of useful constructs (such as the composite feature you describe below) for reuse. thanks, bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:robertt@vcd.hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -----Original Message----- From: Norbert Schade [mailto:norbertschade@attbi.com] Sent: Monday, July 08, 2002 7:32 AM To: Print Services group Cc: UPD group Subject: PS> Semantic model: media handling I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020717/1623e816/attachment.html From NorbertSchade at oaktech.com Wed Jul 17 16:05:39 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:04:59 2009 Subject: UPD> data type separation Message-ID: Bob, I attach the current version of our current data types schema. If I understand your vision properly, this should exactly demonstrate the separation of attribute structures and the overall implementation - in our case the UPDF device description schemas. Depending on how close we'll come eventually, I could imagine taht we even include a Semantic Model data type schema within the UPDF data type schema and take the duplicates out of our current version. But I don't want to be too optimistic, before I see a clear path of the Semantic Model. And there could be some other significant requirements specific to a UPDF device description. Regards Norbert (See attached file: UPDF Data Types.xsd) "Harry Lewis" m.com> cc: Norbert Schade , Print Services group , UPD group Sent by: owner-upd@pwg Subject: UPD> RE: PS> Semantic model: media handling .org 07/17/2002 11:34 AM I like Bob's analysis. I think the Semantic Model will be most useful taking this approach. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "TAYLOR,BOB (HP-Vancouver,ex1)" To: Norbert Schade Sent by: owner-ps@pwg.org , Print Services group cc: UPD group 07/16/2002 09:13 PM Subject: RE: PS> Semantic model: media handling Hi Norbert, all, One of the things we (HP) have been suggesting for the semantic model is the separation of the raw "attribute/element" definitions from the structures/model that pull them together for a particular use. As you not, UPDF has done this structuring in a different way than IPP - which is also somewhat different than UPnP & PSI, etc. I'm not sure we want to try codify any one structure as part of the core semantic model - these will tend to vary by market segment and domain, and I'm not sure we can do this one-size-fits-all. What we would like to see, though, is common definition of the core "attributes/elements" - this seems much more reusable across models & domains. It does make sense, though, to publish some of the "common models" as at least examples of structural models - IPP, UPDF, etc. are likely candidates for this. This exposes some of useful constructs (such as the composite feature you describe below) for reuse. thanks, bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:robertt@vcd.hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -----Original Message----- From: Norbert Schade [mailto:norbertschade@attbi.com] Sent: Monday, July 08, 2002 7:32 AM To: Print Services group Cc: UPD group Subject: PS> Semantic model: media handling I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Data Types.xsd Type: application/octet-stream Size: 70451 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020717/fe5649f7/UPDFDataTypes.obj From norbertschade at attbi.com Tue Jul 23 21:07:28 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> UPDF web site update Message-ID: <000a01c232ae$7b4960e0$a8948018@ne1.client2.attbi.com> I have updated the UPDF web site. Check out ftp://ftp.pwg.org/pub/pwg/upd/Current_Version and the schema and samples subfolders. These files have every change and extension we talked about before, in and since Portland. I'll send out more detailed reports the next two days. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020723/daf77815/attachment.html From norbertschade at attbi.com Tue Jul 23 21:20:51 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> classifying identifiers with two-dimensional parameters Message-ID: <002301c232b0$59f422c0$a8948018@ne1.client2.attbi.com> We redesigned the classifying identifiers with two-dimensional parameters. 1. Virtual units Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'virtualUnits' + '_' + positiveInteger + 'x' + positiveInteger. 2. Device Resolution Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'deviceResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. 2. Raster Resolution within the raster objects A raster object is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'rasterResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. 2. Positioning Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'deviceResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. We have combined the two attributes for the maximum values to one attribute 'MaximumValue'. The syntax is positiveInteger + 'x' + positiveInteger. The values represent the maximum values for the command sequence. This can be, but is not necessarily identical to dpi values. There are PDL out there, where these values are not arbitrary, but have a rather small limit. that means the driver perhaps has to repeatedly send relative positioning command sequences. This attribute helps identifying that special condition (e.g. think of some Canon bubble jets). With this feature we have some small discussion going on with devices in mind, which cannot position with x and y dimension in one command sequence. These are typically banding devices. We will keep you informed. Attributes 'Reference' and 'Direction' are now mandatory. The driver must rely on finding that information. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020723/57a9901b/attachment.html From norbertschade at attbi.com Sun Jul 28 21:26:25 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:04:59 2009 Subject: UPD> compression modes Message-ID: <000a01c2369e$f4d61a40$a8948018@ne1.client2.attbi.com> We have defined a data type for compressions used within the raster graphic definition. Please check and comment. I guess it may need some more work on the details once we finish different device descriptions. The files are on our web site already. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020728/3dc22038/attachment.html From NorbertSchade at oaktech.com Mon Aug 5 10:27:31 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:04:59 2009 Subject: UPD> specification documentation Message-ID: We are heavily working on the documentation these weeks. Find a new version of the spec on the UPDF web site, access from the UPDF page (detailed file name: UPDF_Functional_Specification.pdf). There is still more to do, we know. but we have been able to add info a number of sections including connectors, composite features and dependencies. Have a look. Norbert From hlava at us.ibm.com Mon Aug 12 16:09:02 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Wed May 6 14:04:59 2009 Subject: UPD> Comments on UPDF specification Message-ID: The following are some comments about the UPDF specification (Universal Printer Description Format, Version 0.83.1) document. I am new to UPDF, but perhaps this is a positive thing in that it will provide the perspective of someone coming to UPDF "cold" and only having what's written down in the spec to go by. * There is no table of contents and no index, making it impossible to use this as a reference document. * Heading levels are not numbered like they were in 0.81.3, making an already difficult-to-follow nesting structure (see the following point) now impossible-to-follow. There are not even page numbers in the current version! * It is very difficult to discern the nesting of the XML elements. You have to either flip back and find the list of sub-elements in the containing element (in 0.81.3 you could count the numbering level in the numeric header, which gets very difficult as the nest level deepens). I would suggest using heading numbers and indenting as well to make the nesting visually obvious. * Many elements merely list the attributes without any explanation. While the purpose of some can be deduced from the names, this is very imprecise in a standards document and opens it up for misunderstandings and incompatibilities between vendors. * "XML-DTD encoding of UPDF" section references a DTD file but the UPDF is actually defined via XML schema (XSD) files. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020812/b77907f4/attachment.html From NorbertSchade at oaktech.com Mon Aug 12 17:17:37 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:04:59 2009 Subject: UPD> Comments on UPDF specification Message-ID: I answered Alan a minute ago with the email below and sent him my current version of the spec, which is slowly showing some sign of professional layout. I detached the doc file from this email, as I'm still working on it and it's not yet in PDF format. But it's good to notice that more people are getting to the heart of UPDF. Makes those who devote parts of their life to it feel better. Expect the next public version of the format this week. Norbert ----- Forwarded by Norbert Schade/oaktech/us on 08/12/2002 05:11 PM ----- Norbert Schade To: "Alan Hlava" 08/12/2002 cc: 05:09 PM Subject: Re: UPD> Comments on UPDF specification(Document link: Norbert Schade) Hi Alan, welcome to the group. There will be the day and time when I take a bit more time to talk to you, but for nowE just a short answer you may be very interested in. Thanks for your feedback. As you can imagine, we know about the lacks. But it simply needs time to do all this stuff. Fortunately (as a matter of fact to a perfect time for you) I attach my latest version of the specification documentation. I leave it to you to play with it. You may enjoy it. this is the result of the evenings of last week. It's not yet converted to PDF, as I'm still working a bit on some sections. I assume you have a WinWord somewhere in access. After that it has to rest again, as we have to get back to the technical side again. Your last two items are known, but unchanged for now. It will be fun to have somebody new to the group with serious interest. we'll talk again. Norbert "Alan Hlava" cc: Sent by: Subject: UPD> Comments on UPDF specification owner-upd@pwg .org 08/12/2002 04:09 PM The following are some comments about the UPDF specification (Universal Printer Description Format, Version 0.83.1) document. I am new to UPDF, but perhaps this is a positive thing in that it will provide the perspective of someone coming to UPDF "cold" and only having what's written down in the spec to go by. * There is no table of contents and no index, making it impossible to use this as a reference document. * Heading levels are not numbered like they were in 0.81.3, making an already difficult-to-follow nesting structure (see the following point) now impossible-to-follow. There are not even page numbers in the current version! * It is very difficult to discern the nesting of the XML elements. You have to either flip back and find the list of sub-elements in the containing element (in 0.81.3 you could count the numbering level in the numeric header, which gets very difficult as the nest level deepens). I would suggest using heading numbers and indenting as well to make the nesting visually obvious. * Many elements merely list the attributes without any explanation. While the purpose of some can be deduced from the names, this is very imprecise in a standards document and opens it up for misunderstandings and incompatibilities between vendors. * "XML-DTD encoding of UPDF" section references a DTD file but the UPDF is actually defined via XML schema (XSD) files. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From NorbertSchade at oaktech.com Tue Aug 20 14:57:41 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:04:59 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: You can find a new version of the UPDF specification on our web site. Just use the reference in the UPDF site. Although the exact version number is 0.84.0, we'll nickname it 'Version 84' for short reference, as we expect to refer to this level regularly. We consider Version 84 as a major milestone of the document, as we have accomplished some targets. 1. All information merged into one document. Before we had documents, which referred to one special schema. We had documents at different places. Not all documents could be accessed from the UPDF web site. Now we have one document for the specification. The link known by all people involved in UPDF refers to that document. It's in PDF format. >From now on this will be the only document, where you'll find official information about the specification. One place to search. One file to edit. 2. The spec shows all tags of all schemas. Version 84 reflects all UPDF schemas. There is one section per schema (except the data type schema, which is really for the experts). All elements and attributes of all schemas are listed. We know that not all tags are documented as well as we'd like to. But now that's simpler to fill in. 3. The spec shows a professional layout. Although we were hoping for some time that we'd get some help from people who do that for living, we finally had to move on. I hope we proved that some dry engineers can get something together, which really looks like a specification. Important details include a table of contents and headings in nine levels for all elements. Attributes are formatted in blue for easier detection, as they are the main target to look out for when seeking information. Headings are numbered for perfect reference. >From now on it is possible that more than one work on the spec, as we have detailed references to avoid overlapping and double-work. General We know it's not final. But this version can be easily extended and is an excellent base for discussion. Once all tags are filled as required we will be able to start a series of last calls. We expect that to start after the New Orleans conference. If you have thought about reading through the spec, but always were confused by the differences to the schemas, now is the time to jump in. One reason for finish the spec on this level was to provide some document for discussions with the Semantic Model group in PWG in the Linux guys from the freestandards.org. It will now be easier to demonstrate how things are suppose to work with this kind of architecture. Now the effort for the spec has to come down a bit again to make room for the technical work. Meet you there! Regards Norbert Schade From jsommer at bellatlantic.net Thu Aug 22 08:01:04 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:59 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: <5.1.1.6.2.20020822080051.00b5b188@incoming.verizon.net> Norbert, The new version of the spec looks great. It's much easier to identify elements and attributes and overall much more readable. A major step forward. Jim At 8/20/2002 02:57 PM, NorbertSchade@oaktech.com wrote: >You can find a new version of the UPDF specification on our web site. Just >use the reference in the UPDF site. Although the exact version number is >0.84.0, we'll nickname it 'Version 84' for short reference, as we expect to >refer to this level regularly. > >We consider Version 84 as a major milestone of the document, as we have >accomplished some targets. > >1. All information merged into one document. >Before we had documents, which referred to one special schema. We had >documents at different places. Not all documents could be accessed from the >UPDF web site. >Now we have one document for the specification. The link known by all >people involved in UPDF refers to that document. It's in PDF format. > From now on this will be the only document, where you'll find official >information about the specification. >One place to search. One file to edit. > >2. The spec shows all tags of all schemas. >Version 84 reflects all UPDF schemas. There is one section per schema >(except the data type schema, which is really for the experts). All >elements and attributes of all schemas are listed. >We know that not all tags are documented as well as we'd like to. But now >that's simpler to fill in. > >3. The spec shows a professional layout. >Although we were hoping for some time that we'd get some help from people >who do that for living, we finally had to move on. I hope we proved that >some dry engineers can get something together, which really looks like a >specification. >Important details include a table of contents and headings in nine levels >for all elements. Attributes are formatted in blue for easier detection, as >they are the main target to look out for when seeking information. Headings >are numbered for perfect reference. > From now on it is possible that more than one work on the spec, as we have >detailed references to avoid overlapping and double-work. > > >General >We know it's not final. >But this version can be easily extended and is an excellent base for >discussion. >Once all tags are filled as required we will be able to start a series of >last calls. We expect that to start after the New Orleans conference. > >If you have thought about reading through the spec, but always were >confused by the differences to the schemas, now is the time to jump in. > >One reason for finish the spec on this level was to provide some document >for discussions with the Semantic Model group in PWG in the Linux guys from >the freestandards.org. It will now be easier to demonstrate how things are >suppose to work with this kind of architecture. > >Now the effort for the spec has to come down a bit again to make room for >the technical work. Meet you there! > >Regards >Norbert Schade From hlava at us.ibm.com Thu Aug 22 08:12:28 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Wed May 6 14:04:59 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: The new headings look great, but the document still seems to be missing page numbers. This makes the table of contents very much less useful. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020822/0cc42cfa/attachment.html From norbertschade at attbi.com Thu Aug 22 08:31:05 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> new UPDF specification document: Version 84 References: Message-ID: <000d01c249d7$c92a8b00$a8948018@ne1.client2.attbi.com> Page numbers should only be a minor change. I'll add footers the next time. Good to see that people acknowledge the effort. Looks, as if the feedback is positive. So we'll stay with the overall layout. Regards Norbert Schade ----- Original Message ----- From: Alan Hlava To: upd@pwg.org Sent: Thursday, August 22, 2002 8:12 AM Subject: Re: UPD> new UPDF specification document: Version 84 The new headings look great, but the document still seems to be missing page numbers. This makes the table of contents very much less useful. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020822/3b7b768d/attachment.html From norbertschade at attbi.com Mon Sep 16 09:45:05 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> update UPDF site Message-ID: <002401c25d87$4385b740$a8948018@ne1.client2.attbi.com> I have updated the schema and XML files on the UPDF site. Nothing major, just some little repairs of some oversights. Currently under review or discussion: - specification documentation - review general section about dtd and schemas - review command sequences - messages in dependencies - especially with regards to composite features - a UPDF namespace and a transparent relationship to the Semantic Model - wildcards - some entry to indicate that all data files based on UPDF are not considered IP. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020916/44e3c383/attachment.html From NorbertSchade at oaktech.com Mon Sep 16 14:20:22 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> min/max custom sizes Message-ID: Now that we have a complete architecture and play around with samples, we see some chances. One of them is the smart handling of custom media sizes, which is a pain in the neck in many drivers. Right now our main schema has some custom media size related attributes in media source. Basically fine, nothing wrong with that. We can say that a specific tray can only feed sizes between this and that. We had some feedback that printers may have similar limitations for duplex and somebody else said it could basically happen anywhere (printer xxx can't staple larger than etc.). Valid input! Calls for a better solution. Proposal to start discussion: We remove the custom media size related attributes from media source and create one general custom media size element (attributes: HorizontalMinimum, HorizontalMaximum, VerticalMinimum, VerticalMaximum) under the media size feature (not the record of the feature). Somebody may enter some default values there. The main point would be that everybody can now define dependencies with these attributes. Sample: If duplex, override the minimum values. No schema change required. You can now define a dependency for every feature, if you like. Comments??? Norbert From NorbertSchade at oaktech.com Mon Sep 16 14:36:34 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> dependencies for composite features Message-ID: There is another discussion going on: How shall a driver behave when it comes to dependencies for composite features. Two weeks ago I was coming from a position that a composite feature is a feature as any other. So it may as well have its own dependencies. The 'old' ones referring to basic features used as components are to be ignored. I'm not that sure any more. Basically most of the old ones would have to be redefined while just replacing the condition. May be even the same warning messages are used. If not, a new localization effort is necessary. In the meantime I'm leaning towards 'use what you have'. It's there. If it can be used, no extra effort is necessary. Once creating messages be a bit careful with the wording as they may pop up with composite features later. So there will not be any new localization. To be clear: If the composite feature needs something special, go ahead and create a new dependency. Sample: If !simplex, don't use media type transparency. Assume we have that dependency for the two basic features and we have a composite feature 'Media' with media size and type as components. If long-edge is selected and the user tries to select a ComponentSet, which involves transparency, the original dependency should pop up. I understand that people can have different opinions on this, but we'd like to recommend an expected behavior for UPDF drivers in the spec. So let's hear some opinions and see, if we can agree. Norbert From norbertschade at attbi.com Wed Sep 18 20:11:20 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Copyright for UPDF device description Message-ID: <000d01c25f71$153c1f00$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.xsd Type: application/octet-stream Size: 73823 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020918/0319620e/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 97881 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020918/0319620e/UPDFDeviceDescription-HPLaserJet9000PCL5e.xml From hamzy at us.ibm.com Fri Sep 20 11:35:02 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:00 2009 Subject: UPD> Copyright for UPDF device description Message-ID: I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From hamzy at us.ibm.com Fri Sep 20 11:53:55 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:00 2009 Subject: UPD> Copyright for UPDF device description Message-ID: Sigh. Let's try this again and hope of the cr/lfs are correct this time. I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From NorbertSchade at oaktech.com Fri Sep 20 12:09:08 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> MIT attributes Message-ID: Just to explain where I came from. Yes, I use an XML editor and thought we want the license to pop up there in a way that you can easily read it in the app on one screen. If we assume the files will rather be opened in a straight text editor, I understand Mark's comment. Of course, we could fill it all into one attribute (I'd have to check for max length). I haven't seen a way to wrap lines in my app, so it would show up a one long line, where you have to scroll. All MIT attributes are of type fixed, which to my knowledge is the only way I can protect the wording. My interpretation of fixed is mandatory, but I noticed that my Turbo XML does not care so much. If I just declare it as 'required', anybody could change the text, which we don't either, do we? Norbert From Rob.McDougall at adobe.com Mon Sep 23 16:06:30 2002 From: Rob.McDougall at adobe.com (Rob McDougall) Date: Wed May 6 14:05:00 2009 Subject: UPD> Copyright for UPDF device description Message-ID: <311000B0752ED211B61700805F0D6B09036CB052@ottmail3.jetform.com> Just FYI, the xml declaration must occur before any XML comments, so you'll have to move the comments after that line. Regards Rob -----Original Message----- From: Mark Hamzy [mailto:hamzy@us.ibm.com] Sent: September 20, 2002 11:54 AM To: UPD group Subject: Re: UPD> Copyright for UPDF device description Sigh. Let's try this again and hope of the cr/lfs are correct this time. I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From NorbertSchade at oaktech.com Wed Sep 25 13:42:52 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> demonstration of composite features and dependencies in New Orleans Message-ID: Although we do not have a detailed agenda yet, it is sure that we will use the opportunity to explain and demonstrate composite features and dependencies at the UPDF meeting in New Orleans on Friday, Nov. 8th. We'll use an implementation provided by Granite Systems. This is not just a set of UPDF xml schemas or files, but a full size printer driver under MS Windows. We will prepare various sample device descriptions to show different concepts and ideas all supported by the same implementation. Depending on feedback we might do it the first two hours (8.30am - 10.30am) of the day. Feel free to send in some questions concerning this functionality. so we can work them into the demo. Regards Norbert Schade From norbertschade at attbi.com Wed Sep 25 21:13:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> new copyright proposal Message-ID: <003101c264f9$ee8dcd20$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.xsd Type: application/octet-stream Size: 72845 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020925/ec976af4/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 97909 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020925/ec976af4/UPDFDeviceDescription-HPLaserJet9000PCL5e.xml From sommer at granitesystems.com Wed Sep 25 22:06:02 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:00 2009 Subject: UPD> Sample UPDF Driver Message-ID: <5.1.1.6.2.20020925213606.020a3968@incoming.verizon.net> I have uploaded a sample Windows 2000/XP UPDF printer driver to the PWG web site. There are two files: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/GraniteSystems/Driver/GraniteSampleDriver.zip ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/GraniteSystems/XML%20Samples/GraniteSampleUPDF.zip GraniteSampleDriver.zip contains the driver files. GraniteSampleUPDF.zip contains the UPDF schemas and XML for my sample. This is based on Norbert's sample. If you wish to install this do the following: 1) Unzip the two files. You can unzip them to the same or different directories. 2) In the directory that you unzipped the driver there is a file named GSPLUPDF.INI. Edit this file and change the Directory= entry to the directory that you unzipped the UPDF sample into. This should be a complete path and it should not be a network drive. 3) Run "Add Printer" and point it to the directory that contains the driver. The driver should now be installed. There are three composite features defined - one with media size as the dominant feature and two without dominant features. The media composite feature appears in the Features list in place of media size. The other two composites appear on the Presets tab. All three composites are user extensible so you may define new records for them using the Composites tab. The new records will appear in the appropriate lists. If you open Word and go to Page Setup you will see the media composite feature listed instead of the standard sizes. There are a bunch of dependencies defined - at least one of each type (filter, message, selection). You can look at the XML to see all of them (some are in the device description and some are in the user policy and they are a bit confused right now) but examples are: Filter - Duplex != Simplex AND Media Type = Lables Message - Bin = Top AND Stapling != None then display message. If OK (which has been renamed "No Stapling" is selected then set stapling to none, gray it out, and put an information icon on it. There are still plenty of bugs but I think this demonstrates composite features and dependencies pretty well. I will continue to work on this but what will be demonstrated at the New Orleans UPDF meeting will be based on this implementation. Please feel free to contact me with questions and comments. Jim mailto:sommer@granitesystems.com 978-486-3068 From sommer at granitesystems.com Thu Sep 26 08:55:21 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:00 2009 Subject: UPD> Dependencies Message-ID: <5.1.1.6.2.20020926072649.00bde960@incoming.verizon.net> I have been working quite a bit with implementing dependencies and have some comments for the group. Introduction To Dependencies: UPDF defines three types of dependencies - filter, message, select. All dependencies consist of one or more conditions. The conditions are AND'd together. Each condition can be either and EQUAL or a NOT EQUAL. Conditions are defined using unique IDs. Therefore, a condition appears as - MediaDuplex_Record.ID NOT EQUAL Simplex AND MediaType_Record.ID EQUAL Type_Transparency. Filter - A filter dependency defines a group of settings (it may be a group of one) that should never be displayed. If N conditions are defined for the filter and N-1 of the conditions are true then all settings that would make the remaining condition true are to be hidden. Using the conditions above, if media type is set to transparency then all settings with duplex not equal to simplex are hidden. Also, if duplex is not set to simplex then all settings with media type equal to transparency are hidden. Filters are not a very user friendly dependency but they do have their uses. Message - A message dependency defines a message that should be displayed when a group of settings (it may be a group of one) is selected. The message must have an OK and/or a Cancel button. If the user clicks the Cancel button then the last action performed by the user is undone. If the user clicks the OK button then a group of settings selections (it may be a group of zero) is automatically made. In addition, any of the features in selections may be grayed out and an information icon may be added to the feature to explain why it is grayed out. Using the conditions above, when duplex is not simplex and media type is transparency the message "You cannot duplex transparencies. Click OK to turn off duplexing. Click Cancel to undo your last change." is displayed. If OK is clicked then duplex is set to simplex, grayed out, and an information icon is added to the duplex feature. When the information icon is clicked, the message "You cannot duplex transparencies." is displayed. All this is defined within the message dependency. Select - The select dependency is really a degenerate form of the message dependency. The select dependency has no message and assumes the OK button is clicked. So, what you have is a group of settings selection (it may be a group of one, zero doesn't make sense) that is automatically made when a group of settings (it may be a group of one) is selected. In addition, any of the features in automatic selections may be grayed out and an information icon may be added to the feature to explain why it is grayed out. Using the conditions above, when duplex is not simplex and media type is transparency then duplex is set to simplex, grayed out, and an information icon is added to the duplex feature. When the information icon is clicked, the message "You cannot duplex transparencies." is displayed. All this is defined within the select dependency. Implementation: This is how I implemented dependencies to provide the results that one would expect from the UPDF definition. When the user interface is brought up, dependencies are run against the saved settings. This should not produce any messages or cause any selections to be made since the saved settings should be valid. Filters may cause settings to be hidden from some features. Each time the user changes a setting by either changing a standard feature (ie destination changed from top bin to left bin) or changing a composite feature setting (ie media changed from "plain letter in tray 1" to "plain legal in tray 2") dependencies are checked. The following steps are then taken - 1) Save the settings before applying the current change. If the current change is a composite feature then set all the component features to their appropriate settings. 2) Make all settings visible (undo any filters), ungray all features, and clear all information icons. 3) Start dependency checking with those dependencies defined in the user policy file. The user policy dependencies may duplicate some of the device description dependencies but are assumed to be more appropriate. For example, the device description may define a select dependency whereas the user policy defines the same condition as a message. 4) Check the conditions of each dependency and act on each as appropriate (filter, message, or select). 5) If a select dependency is true or the user clicks OK on a message dependency then set the automatic selections and restart dependency checking (goto step 2) with the new settings. 6) If the user clicks Cancel on a message dependency then stop checking dependencies and restore the saved settings (from step 1). I made this mistake in another email so I want to note that if a dependency grays out and/or adds an information icon to a feature then you do not have to write another dependency to ungray the feature and/or remove the information icon. I do this in step 2 above. I think we should make this part of the definition of UPDF dependencies - When a dependency is no longer true, features will be displayed normally and information icons will be removed. Dependencies and Composite Features: Dependencies can be defined using standard features or composite features. A condition can be MediaDuplex_Record.ID != Simplex AND MediaType_Record.ID = Type_Transparency or it can be MediaDuplex_Record.ID != Simplex AND Media.CompositeFeature_Record.ID = CF_Media_Transparency. Using the standard feature, all settings which cause media type to be transparency will cause the condition to be true whereas using the composite feature will only cause condition to be true for a specific composite feature setting. One other use of dependencies is for user extensible composite features. A composite feature record should not be defined that causes any dependency based on the components of the composite to be true. For example, if a media composite feature has the components media size, type, and source and there is a dependency that says #10 envelopes can only come from the envelope feeder then the user should not be able to create a composite feature record with a media size of #10 envelope and source not equal to the envelope feeder. I have not implemented this portion of dependencies yet but my plan is that during the definition of a composite feature record I will apply only those dependencies that have all condition features as components of the composite. If you've read this far, I hope I've helped you understand dependencies a little better. Please feel free to respond with questions and comments. Jim mailto:sommer@granitesystems.com 978-486-3068 From NorbertSchade at oaktech.com Thu Sep 26 10:20:56 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> glossary Message-ID: We see some conversation going on on different reflectors accompanied by the announcement of various implementations. It may help you simpify things in your mind with a little glossary how terms are used in the UPDF world. Composite Features: A set of basic features, in this case called components, forming a group. You may find the abbreviation 'c.f.' used from time to time. In theory c.f. can themselves be grouped to a new c.f. on a higher level. Dominant component: A c.f. can (not must) have one. Exactly one component can be picked, e.g. media size as the dominant feature of a c.f. Media. If assigned, it is suppose to replace the corresponding basic feature in the UI and all according API to the system. The same second all other components become hidden in the top level UI as well. All components are supposed to be available in a special area of the UI, where the composite feature can be managed, let's say to create a new record or edit an existing user defined one. Without a dominant component all components stay active in the top level UI. The c.f. feature serves more like a collective default setting for features involved. User extensible: If a c.f. feature is user extensible, the end user will be able to create new records and edit them. Predefined records created by the IHV can never be edited, only viewed to identify the settings used for single components. A nice detail is that a system administrator has the power to switch this attribute in a user policy. So s/he can create new records and then block the extensibility for all subsequent users. Dependencies: The definition of actions, how interference between features should be resolved. Often mixed up with the term of 'constraints'. Constraints typically define a feature by showing up as the set of allowed records. Filters: A dependency action. Hide special records of special features under special conditions. Sample: If record 5 of feature A, don't show record 2 of feature B. Selections: A dependency action. Select special records of special features under special conditions. Sample: If record 5 of feature A, select record 2 of feature B. Messages: A dependency action. In case a special condition with a set of features and their records involved is identified bring up a message box to indicate the condition. Typically offered with an OK and a Cancel button. Cancel brings back the previous settings, OK forces the last setting selected to become active and the driver is supposed to resolve all conflicting settings. Usually the OK case is realized with a Selection action. Sample: If record 5 of feature A, show a message indicating that record 2 of feature B conflicts with record 5 of feature A. Hope makes reading easier. If you'd see my wall at home, you'd find out that I have these little stickers all over my place. Norbert From NorbertSchade at oaktech.com Thu Sep 26 10:49:59 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> UPDF implementation in a Windows based printer driver Message-ID: I am delighted to see the first complex implementation sample available from Granite Systems in form of an MS Windows based printer driver, for now under Windows 2K/XP. It excellently demonstrates the rich architecture of UPDF in a rather technical implementation without wasting to much energy on customizing the user interface. Just playing around with it following Jim's recommendations should bring the concept more to life in your mind. It's always easier to get the idea, if you have something to play with. If somebody wants to change and try own UPDF device descriptions that can be done with this implementation as well. Contact Jim, if you have problems with the procedure. I'm ready to help in any way (email or phone), too, to lead you through the functionality of the demo driver. Regards Norbert From sommer at granitesystems.com Fri Sep 27 09:55:53 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:00 2009 Subject: UPD> Re: Sample UPDF Driver In-Reply-To: Message-ID: <5.1.1.6.2.20020927090958.020c0130@incoming.verizon.net> Alan, Presets are composite features that do not have a dominant feature. In my example, I have two of these - N-Up and Reports. N-Up has two records/settings - American 9-Up and Japanese 9-Up. Reports has one record/setting - Department. Select a preset in the Presets list box. The combo box below will then contain the records/settings for the preset. Choose the setting and select the Apply Preset button. This will set the component features of the preset to their appropriate values. In the case of N-Up, the component features are N-up, N-up order, and N-up borders. Since these composites do not have a dominant feature, all the component features are still separately selectable on the Features tab. The Composites tab is used to manage all composite features. Using this tab you can view the component settings for each record/setting of the composite feature. If a composite feature is user extensible, you can add user defined records to the composite or modify and delete previously defined user records. You cannot modify or delete composite feature records that are defined in the device description or user policy XML. The two blank buttons are a bug, I'll fix that. From within an application, only the View button should be visible. From Document Defaults (2000) or Printing Preferences (XP) from the Printers window, you will see New, Edit, and Delete buttons. The Features tab is where you can view and set individual features. When you apply a preset on the Presets tab, the component settings are reflected on the Features tab. To change a feature, select the feature in the Features list box. The combo box below will then contain the records/settings for the selected feature. Norbert's Media is a composite feature with media size as its dominant feature. In the device description this composite is named Media but the user policy file renames it to Norbert's Media. Since this composite has a dominant feature, the composite is displayed in place of the dominant feature (instead of on the Presets tab) and all components are hidden (they are no longer separately selectable). The Norbert's Media composite feature is user extensible so you can define new records using the Composites tab. These new records will then be displayed for the composite on the Features tab. I hope this explanation along with sample help you to understand the composite feature concept and the difference between the two types (with and without a dominant feature). Let me know if you have any other questions. Jim PS I copied the mailing list on this response in case anyone else has the same or similar questions. At 9/27/2002 09:08 AM, you wrote: >I installed and have started to play with this sample. It definitely >helps to illustrate some of the UPDF capabilities concepts! > >Some questions/comments: > * What are "presets"? (It's not obvious from the print dialog what > this tab is meant to contain) > * On the Composites tab, there are two unlabeled buttons, above and > below the View button. Is this intentional or am I missing something? > * It's not clear how I select a composite. On the Composites tab N-UP > and American 9 Up are displayed, but when I click on the features tab it > shows Norbert's Media and Stationery Letter from Tray 1 as the first > feature. Which one is my current selection and how do I change it? > > * Regards, > > * Alan Hlava > * IBM Printing Systems Division > * hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020927/8fcdb9c3/attachment.html From NorbertSchade at oaktech.com Thu Oct 3 15:27:49 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> preliminary New Orleans agenda Message-ID: We have some ideas what we have to work on, nothing formal yet: Preliminary agenda Friday, Nov. 8th, 8.30am to 3pm 8.30 to 10.30: Driver demo We'll show Granite's implementation of a Windows driver using a full UPDF device description. Highlights will be dependencies, composite features and user policies. This will be the perfect chance to ask questions. The nice thing is that we can change the data on-the-fly and show it right away without any driver compilation. 10.15 MIT license 10.30 Manual duplex other items - prepare last calls on spec - check closer alignment with SM - requirements for release 2 (user interface, use other standard for bidi) I'll be in Europe for the next days, back on Tuesday Oct. 15th. Jim will cover me. regards Norbert Schade From norbertschade at attbi.com Sun Nov 17 17:25:40 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> meeting minutes of New Orleans Message-ID: <002c01c28e88$43f325a0$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021117/18596166/Latest_Meeting_Minutes.htm From norbertschade at attbi.com Mon Nov 18 22:31:26 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> meeting minutes Message-ID: <000a01c28f7c$25114280$a8948018@ne1.client2.attbi.com> I copied the meeting minutes of New Orleans to the UPDF web site, now with a complete and correct list of attendees. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021118/5276781b/attachment.html From norbertschade at attbi.com Tue Nov 19 20:43:15 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> just another one Message-ID: <000e01c29036$320f6a60$a8948018@ne1.client2.attbi.com> I added Mark Hamzy to the list, too. sometimes the crowd is bigger than you think. Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021119/d3b95ee2/attachment.html From norbertschade at attbi.com Tue Nov 19 21:15:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> latest schemas and XML Message-ID: <002001c2903a$b4570560$a8948018@ne1.client2.attbi.com> I just copied the latest schemas and XML files to the UPDF web site. Typical pathes: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML%20Schemas/ ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML%20Samples%20based%20on%20schemas/ or access them directly from our web site. All we discussed the last weeks is implemented except a solution for the manual duplex. I'll send some notes on some details the next days and will refer to this set of files. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021119/ce6e449e/attachment.html From norbertschade at attbi.com Wed Nov 20 08:20:00 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> command sequences in font handling Message-ID: <005101c29097$877d6a40$a8948018@ne1.client2.attbi.com> We are providing the following font related entries in the event_enum: 1. FontObjects when entering or leaving the world of fonts in the printer 2. DeviceFonts when entering or leaving the world of resident (not download) fonts in the printer 3. DeviceFont the command sequence at start or end of a resident font in the printer 4. DeviceFontCharacter 1. and 2. are general events and easy to handle. 3. and 4. require more attention. A driver would check all DeviceFont related events (four in the sample below) when any of the font attributes on the host platform have changed (e.g. from Arial to TNR, from upright to italic or else). A driver would check all DeviceFontCharacter related events (two in the sample below) to find out if the Parameter_ID of Character.Parameter (please help me check, if attribute Character_PrintOut is only a duplicate of this parameter and therefore redundant and can be removed. I haven't been to that detail for quite a while) or of Character.SymbolSet.Parameter has changed. We assume a device description developer would create an event per Parameter element. A sample data flow could look like - command sequence reference EnterFontObjects at start of event FontObjects. no parameter references used. - c.s.r. EnterResidentFont at start of event DeviceFonts. no parameter references used. - c.s.r. StartDeviceFont at start of event DeviceFont. DeviceFont.Parameter.Parameter_ID used. - c.s.r. DeviceFontStyle at start of even DeviceFont. ModifyingAttributes.Style.Parameter.Parameter_ID used. - c.s.r. DeviceFontWeight at start of even DeviceFont. ModifyingAttributes.Weight.Parameter.Parameter_ID used. - c.s.r. DeviceFontColor at start of even DeviceFont. ModifyingAttributes.Color.Parameter.Parameter_ID used. Other modifying attributes possible but not used in this sample. - c.s.r. DeviceFontCharacterSymbolSet at start of event DeviceFontCharacter. Character.SymbolSet.Parameter.Parameter_ID used. - c.s.r. DeviceFontCharacterTransparent at start of event DeviceFontCharacter. Character.Parameter.Parameter_ID used. This is to print transparent characters. The command sequence is supposed to tell the printer 'interpret the next byte as a character instead of an escape'. - c.s.r. LeaveFontObjects at end of event FontObjects. no parameter references used. To make this work I think we need one common agreement: If a specific Parameter_ID attribute is empty or the Parameter element is not assigned, the corresponding command sequence is not sent at all if and only if the command sequence refers to that Parameter_ID attribute. That is the first time we specify command sequence handling to that detail for font handling. I forgot something? Any questions or feedback? regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021120/4b4043d1/attachment.html From norbertschade at mediaone.net Fri Feb 1 13:21:21 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> what we may do on Monday Message-ID: <002401c1ab4d$3fce4a00$a8948018@ne.mediaone.net> Guys, Jim and I will arrive on Sunday from Boston. We will miss at least the first half of the Superbowl because of the flight. How could anybody have planned for that? So here is the agenda for Monday: If the Patriots will loose we may start a bit slow. You have to wear a black tie. If the Patriots will win we may even start a bit late. You have to wear a Patriots T-shirt. We will spend the first seven hours reconsidering the game. I have added some XML to our UPDF format, which allows to specify each play. No the more serious part: We will discuss a prepared proposal for a possible final design of composite features and user policies including a sample. Please prepare for raster graphic and color. Bring all information to the table, which you want to see listed there. Another major item will be command sequences and how they are implemented in Event handlers - following the discussion we started at the end of the last conference. See you there. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020201/a7d7a5c5/attachment-0001.html From norbertschade at mediaone.net Thu Feb 7 14:19:56 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> meeting notes Message-ID: <001201c1b00c$6e375260$a8948018@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020207/6116fb5d/Latest_Meeting_Minutes-0001.htm From norbertschade at mediaone.net Mon Feb 11 11:57:33 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> latest locale implementations Message-ID: <006101c1b31d$33b66720$a8948018@ne.mediaone.net> The overall structure of locales has proven to be good. Today we implemented some small modifications based on input we gathered over time. The corresponding schema and samples are on the web. Please access from the UPDF site. 1. Section titles As the number of entries grew over time, it turns into an advantage to have section titles when working with a XML editor. This will not effect a simple text editor. As you can see all locale elements referenced from unit descriptions are now gathered under ReferencedLocaleElements. Instead of facing on huge list of elements you can now close a section you are not working on. This is not really a structural change. 2. Popular text strings not referenced by unit descriptions We'd like to ease the acceptance of the text string handling we provide in UPDF. Although a huge number of strings can be referenced from unit descriptions we acknowledge that there are more in use in today's drivers. These are typically hanlded in defines in header files. We offer a chance to specify those, which are very popular between drivers, in a special section. 2.1. Mandatory text strings The current implementation includes a new section MandatoryLocaleElements (alternative title could be RequiredLocaleElements). This is a list of predefined elements with fixed Name_ID attributes. By this method we can help with the validation that each locale provides exactly 100% of those text strings considered mandatory and defined as such by the UPDF standard. A driver could rely on finding corresponding entries. In this case a locale referenced by a an optional unit or user policy must also provide 100% of all entries - even if unchanged. We've added two elements as a sample. Check that the attribute entry is identical to the element name in each case. 2.2. Optional common text strings Another way to implement it would be to predefine a list of Name_ID attribute values in the data types schema, but leave it to the developer, which of them he/she wants to provide for consistency (in a locale referenced by a device description - not an optional unit or user policy description - we'd seriously recommend to create elements for all of them). We would provide standard LocaleElement elements (in this case they don't have to have different names) under a section titled like CommonLocaleElements. In this case we can't help with a validation whether the list is complete. But an optional unit or user policy description would not have to list them again redundantly (in fact I'd rather be reluctant to overwrite them at all). Both ways have its advantage. We collect a list of proposals for common text strings over the next weeks. 3. Proprietary text strings This is another section to help with the acceptance of the format by consistent handling of text strings. We want to further allow storing any text strings used by a driver, as we think the localization within UPDF is highly optimized. So a driver developer could communicate all text strings defines to the UPDF developer, in which case the driver does not need any other defines in header files or anywhere else. This might likely be used when the printer manufacturer, who is supposed to develop the UPDF description, is the driver developer as well. Keep in mind that these proprietary string are not likely to be used, if the UPDF description is rather meant to be anonymous, which means it shall be used by any UPDF capable driver. I would especially use this section, if a printer manufacturer tends to write its own UPDF driver or cooperates with one driver developer for most of the drivers. This could also be the proper place to store error messages, which are not part of UPDF. We recommend some self-chosen discipline like specifying all UI string with a prefix 'UI_String_' and all error messages with a prefix 'Error_Messages_'. 4. Generic locales defaults Since we have an ID per feature, this is no more necessary and has been removed. As standard features like Media size, etc. have a predefined feature ID, but generic features can be given any string as a feature ID, we could split the Default_Feature attribute into two separate ones: Predefined_Default_Feature and Proprietary_Default_Feature. This should sound familiar to you from other functionality. Please check the schema and the samples and respond to this email. Especially send your proposals for common Name_ID attributes. We will revisit locales end of February. So that's the deadline for changes. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/87c3008f/attachment-0001.html From norbertschade at mediaone.net Mon Feb 11 16:20:17 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> user policies Message-ID: <002f01c1b341$e77d9de0$a8948018@ne.mediaone.net> I have uploaded all modified schemas and xml files to our web site. Modifications are as described in the meeting minutes. This design was agreed on at the L.A. conference. As you can see in the device description, there is an optional, single element for one user policy. This may refer to a user policy description, which extends the original device description. It also may refer to one or more locales. Check the samples. We have added a user policy xml file, which adds a new ComponentSet to the CompositeFeature Media (the connection is done by using the same feature ID!!!) and an English locale, which provides the UI string for the new ComponentSet, replaces one string and sets one new default. Interdependencies will likely appear as well. The User Policy schema is a copy of the device description schema, subtracted by all entries except composite features and interdependencies. We do not split these two features into a separate schema module, but buy a little double work in case of editing these features in the two schemas. If you have questions about any detail, please ask now, as I have all that stuff quite active in my mind these days. Later this week I will provide a sample data flow how to get UI strings and how to handle command sequences. Please spend some minutes on them to be sure you completely understand the details. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/e691b85a/attachment-0001.html From norbertschade at mediaone.net Mon Feb 11 16:35:58 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> user policies in networks Message-ID: <005701c1b344$18e392c0$a8948018@ne.mediaone.net> An additional note: UPDF does not care about passwords and similar stuff. So when somebody wants to create user policies for different users/user groups, he is supposed to create different directories to store them in per user/user group. Each directory may show slightly different device configuration files and different user policy descriptions and/or user policy locales. The original device description and all other files have to be identical in all directories! Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/492463a8/attachment-0001.html From norbertschade at mediaone.net Mon Feb 11 17:14:46 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> UI string triggering in UPDF Message-ID: <007801c1b349$84115f00$a8948018@ne.mediaone.net> I want to provide a sample how a driver could read and identify the proper UI strings in a full UPDF description with all features in use. If a driver is not supporting the complete feature set, it has to define its own fallback mechanisms, of course. This sample data flow is just a proposal. But it might help for a better overall understanding. Our imaginary sample has IHV locales for US English and German. It has a composite feature Media with predefined ComponentSet elements for Letter/Auto and Letter/Tray2. It has an optional unit for an additional input tray 3 with locales for US English and German. It has a user policy for user 'Norbert Schade' with a US English locale and an additional ComponentSet Letter/Tray3. The host locale is Italian. Of course, the search process will be simpler for a simpler configuration. I vision that a driver at some point wants to create a complete list of UI strings for one locale. Here is how I may design the driver to work. The answers are based on this example config. Is the host locale provided for certain UI string reference? Check, if host locale specific string is available in optional unit description or IHV description for that locale. If available or not, check the user policy locales, whether the string is available there or overwritten there. General rule: If proper locale is not available anywhere, fall back to US English and start all over again for US English. In case US English is not available, fall back to the first locale listed and start all over again for that first locale. Now you must have triggered the string. Otherwise the UPDF description has a problem somewhere. Feel free to comment. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020211/5b60a551/attachment-0001.html From jsommer at bellatlantic.net Tue Feb 12 07:48:57 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> latest locale implementations In-Reply-To: <006101c1b31d$33b66720$a8948018@ne.mediaone.net> Message-ID: <4.3.2.7.2.20020212074112.00c51bb0@mailbox.bellatlantic.net> My vote is to go with "optional common text strings" for two reasons. First is that User Policies shouldn't have to have these elements and this takes care of that problem. Second is that implementations are going to vary widely and we don't know exactly what strings are going to be required. Since we can't come up with them all and we don't know if all the ones we define are going to be used, it doesn't make sense to me to make them required. Also, we'll probably find many UPDFs that get written for a specific drivers. It doesn't seem right to require elements that are known to be unused in the target environment. Jim At 2/11/2002 11:57 AM, Norbert Schade wrote: >The overall structure of locales has proven to be good. Today we >implemented some small modifications based on input we gathered over time. >The corresponding schema and samples are on the web. Please access from >the UPDF site. > >1. Section titles >As the number of entries grew over time, it turns into an advantage to >have section titles when working with a XML editor. This will not effect a >simple text editor. >As you can see all locale elements referenced from unit descriptions are >now gathered under ReferencedLocaleElements. >Instead of facing on huge list of elements you can now close a section you >are not working on. This is not really a structural change. > >2. Popular text strings not referenced by unit descriptions >We'd like to ease the acceptance of the text string handling we provide in >UPDF. >Although a huge number of strings can be referenced from unit descriptions >we acknowledge that there are more in use in today's drivers. These are >typically hanlded in defines in header files. >We offer a chance to specify those, which are very popular between >drivers, in a special section. >2.1. Mandatory text strings >The current implementation includes a new section MandatoryLocaleElements >(alternative title could be RequiredLocaleElements). This is a list of >predefined elements with fixed Name_ID attributes. By this method we can >help with the validation that each locale provides exactly 100% of those >text strings considered mandatory and defined as such by the UPDF standard. >A driver could rely on finding corresponding entries. >In this case a locale referenced by a an optional unit or user policy must >also provide 100% of all entries - even if unchanged. >We've added two elements as a sample. Check that the attribute entry is >identical to the element name in each case. >2.2. Optional common text strings >Another way to implement it would be to predefine a list of Name_ID >attribute values in the data types schema, but leave it to the developer, >which of them he/she wants to provide for consistency (in a locale >referenced by a device description - not an optional unit or user policy >description - we'd seriously recommend to create elements for all of >them). We would provide standard LocaleElement elements (in this case they >don't have to have different names) under a section titled like >CommonLocaleElements. In this case we can't help with a validation whether >the list is complete. But an optional unit or user policy description >would not have to list them again redundantly (in fact I'd rather be >reluctant to overwrite them at all). > >Both ways have its advantage. >We collect a list of proposals for common text strings over the next weeks. > >3. Proprietary text strings >This is another section to help with the acceptance of the format by >consistent handling of text strings. >We want to further allow storing any text strings used by a driver, as we >think the localization within UPDF is highly optimized. >So a driver developer could communicate all text strings defines to the >UPDF developer, in which case the driver does not need any other defines >in header files or anywhere else. This might likely be used when the >printer manufacturer, who is supposed to develop the UPDF description, is >the driver developer as well. >Keep in mind that these proprietary string are not likely to be used, if >the UPDF description is rather meant to be anonymous, which means it shall >be used by any UPDF capable driver. >I would especially use this section, if a printer manufacturer tends to >write its own UPDF driver or cooperates with one driver developer for most >of the drivers. > >This could also be the proper place to store error messages, which are not >part of UPDF. We recommend some self-chosen discipline like specifying all >UI string with a prefix 'UI_String_' and all error messages with a prefix >'Error_Messages_'. > >4. Generic locales defaults >Since we have an ID per feature, this is no more necessary and has been >removed. > >As standard features like Media size, etc. have a predefined feature ID, >but generic features can be given any string as a feature ID, we could >split the Default_Feature attribute into two separate ones: >Predefined_Default_Feature and Proprietary_Default_Feature. This should >sound familiar to you from other functionality. > > >Please check the schema and the samples and respond to this email. >Especially send your proposals for common Name_ID attributes. We will >revisit locales end of February. So that's the deadline for changes. > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020212/4eb79c88/attachment-0001.html From norbertschade at mediaone.net Tue Feb 12 16:30:14 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> the philosophy about command sequences Message-ID: <004601c1b40c$764ab7e0$a8948018@ne.mediaone.net> In L.A. we agreed on a redesign of command sequences and parameter handling. While we still are dedicated to the earlier directive to keep the real command sequences and parameters out of the technical device description and gather it in a separate file. But over the time we learnt that we cannot predict the number of parameters needed in every case. Predefine them as ComSeq_Parameter_1, ..._2, etc. was not the optimum solution either. Secondly we are facing features (e.g. Raster grahpic), which require dealing with more than one command sequence. Predefined element names don't look promising here neither. A third argument was brought in that the management of command sequences is inconsistent, as sometimes driven by features, sometimes by events. Ok, that was valuable feedback. And we worked it over. Now the management of command sequences is strictly initiated by events. The events describe the print stream and therefore refer to command sequences at the proper place. If no parameters are needed (like an init: E), the reference can be resolved in the command sequence xml file. The corresponding schema is now split into two sections: CommandSequences and Parameters. Both sections can have a practically indefinte number of elements CommandSequence_ID respectively Parameter_ID. As there must be exactly one leading element per schema, we define one: Commands. This one has the two sections underneath. If parameters are needed, they can be referred to within a command sequence, where you can point to a feature. This feature will have to provide a Command element with an attribute CommandSequence_ID, which will show exactly the same reference as originally in the event and serves as an identfier for the correct command sequence, and another attribute Parameter_ID, which is resolved in the Parameters section. This way we can easily manage more than one Command element, as we can identify them. See the schema and samples flying in tomorrow. I'm working on that right now. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020212/77731a86/attachment-0001.html From norbertschade at mediaone.net Thu Feb 14 11:03:47 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> web site update Message-ID: <003501c1b571$2faec7c0$a8948018@ne.mediaone.net> Find all schema and xml files updated on the web site. Please access from the UPDF site. Let me know about editorial mistakes, which I likely made. I hope it's harder to catch me on the architectural side. To be clear: All latest features like user policies, events, etc. are implemented. This is quite a large update and worth checking. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020214/0a4dd2a0/attachment-0001.html From norbertschade at mediaone.net Thu Feb 14 17:34:45 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> Fw: Booklets Message-ID: <000e01c1b5a7$cdf2eca0$a8948018@ne.mediaone.net> Just forwarding it to the group, as Jim seems to have some problems getting it out today. ----- Original Message ----- From: "Jim Sommer" To: "Norbert Schade" Sent: Thursday, February 14, 2002 4:59 PM Subject: Booklets > Within PrintMediaHandling we have MediaBookletList which has one or more > MediaBooklet elements but we haven't defined what function is to be > expected. I know of two ways that booklets can be implemented: > > 1) Booklets are a special case of 2-Up printing with the pages re-ordered. > If size is set to Letter then letter (8.5x11) paper is selected and > half-letter (5.5x8.5) page images are printed. Pages are ordered so that > when folded in half, a booklet or magazine is created. > > 2) Booklets are a special case of imposition with the pages re-ordered. If > size is set to Letter then ledger (11x17) paper is selected and letter > (8.5x11) page images are printed. Some implementations allow any page image > size with both dimensions smaller than letter to be printed on ledger > paper. Thus, 8x10 page images (assuming the printer supported a paper size > of 8x10) could be printed on ledger paper. Pages are ordered so that when > folded in half, a booklet or magazine is created. > > Implementation #1 has the advantage that booklets can be printed on any > size paper. Implementation #2 has the advantage that the driver (or > interpreter) does not have to do any scaling. > > Implementation #2 may have the advantage of allowing multiple image sizes > per paper size. However, if a driver is to support this function, it > becomes difficult to specify this in a predefined way. If this a device > feature then there isn't an issue. > > If we limit implementation #2 to the case of paper size twice the size of > page image size (ledger/letter, A2/A3, A3/A4, etc), then the function can > be seen as a composite feature of media size and booklet. > > So, I propose that MediaBooklet be a boolean. FALSE specifies normal > printing on the selected paper size. TRUE specifies that the driver do a > 50% reduction of page images, reorder pages for proper booklets (inserting > blanks if required), and printing on the selected paper size. > > Jim > mailto:sommer@granitesystems.com > 978-486-3068 > From norbertschade at mediaone.net Fri Feb 15 12:19:49 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> composite features Message-ID: <002d01c1b644$f931b3e0$a8948018@ne.mediaone.net> We have finished the current design for composite features. Find the schemas and sample xml files on the UPDF site. I suppose everybody has a feeling now what you can accomplish with composite features (c.f. called below). You can basically combine any two or more basic features to a higher level feature. Thinking this over you may better understand why we make some feature pretty basic. I consider it a significant advantage having the chance to save the settings of all basic features, but show something more user friendly in the UI. The sample implementation on the web site shows a 'Media' c.f. with media size, type and source involved. Might be a common sample. We will develop another more elaborate sample in the area of booklets the next days. If you follow that and understand each detail, you should have the essence of c.f. very well. Do you remember that I referred to c.f. as one of the four pillars more than a year ago? Now you may see why I like it so much. Not to mention that I consider it unique to UPDF. Some things you may want to check in detail: 1. See the DominantFeature attribute to the CompositeFeatureList. We don't force a driver to work a certain way, but recommendations may help with a better support. That attribute is single, optional. Means it can refer to one feature. In the sample it's media size. If there is a dominant feature I would recommend to show the defined c.f. in the UI, but automatically remove the composing features from the normal dialogs and make them available in a subdialog collectively. This is an assumption we make in the UPDF standard. If there is not, you may leave them at their usual locations in the standard dialogs. You can always define additional interdependencies to hide the one or the other control. With a dominant feature the special c.f. kind of overwrites the dominant feature. That's why we have an optional Name_ID to the CompositeFeature element. In the sample we want media size to be overwritten by Media and the new Name_ID shall be reported to the OS and then show up in the page setup of the applications. Makes sense? If you want to practice, here's the proposed task: Combine all media types and sources into one merged list of sources like used in a number of today's drivers. And now judge how much code you may need to accomplish that in a monolithic driver - just for this single implementation. 2. If you have a dominant feature, it makes all the other features of a c.f. non-dominant automatically. In our sample that's especially the case with media source. We don't want all the media sources to show up in applications' page setup any more. It would open the door to misselections. We only want the AutoSelect to show up or we could even create a dummy media source with a string "Source is selected by size". That leads us to the Non_Dominant_Representative attribute, assigned to all feature lists. It's mostly mandatory (only optional for media size and c.f.) and defines one record of the corresponding feature as the fall back to be used within c.f., e.g. given above mentioned dummy or the AutoSelect record. Another nice side effect is that you made the entry unchangeable (as it is just one). This attribute handles some useful stuff when it comes to communicating setting to the OS. 3. The UserExtensible attribute to the CompositeFeatureList is a boolean and indicates that the driver shall allow the user to create and manage his/her own records additionally to the predefined ones, if set to true. It's up to the driver how to implement that properly. I hope the other stuff is more or less self-explaining. We have learnt some of our lessons by practicing. During practice there certainly will be the point when you'll say "Wow! Not bad. Now I know." We are working on a sample driver to allow you trying your sample out. As I always say: Now that I have that stuff in my mind at a leading position, you'd get quite some solid answers to any questions. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020215/14742f61/attachment-0001.html From norbertschade at mediaone.net Sat Feb 16 16:05:58 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> proprietary IHV functions Message-ID: <000c01c1b72d$bb566fe0$a8948018@ne.mediaone.net> Level 1 of UPDF will not support any proprietary function call to an IHV library. That does not mean we are not thinking about it. The format does not support the definition of raster compression (however the reference to a predefined list), the complete replacement of raster graphic, any kind of download, raster interleaving or other candidates for a proprietary library. Depending on the interest and the will of contribution we might talk that over. I could imagine something like predefined function calls with a list of predefined parameters, a list of tasks a specific function is supposed to provide and the proper reference place for a call. Any ongoing effort in that area also depends on the acceptance and the implementation of the current UPDF level. I just don't want anybody to get the feeling we don't acknowledge that functionality. Especially in the current process where we start discussing details about raster graphic, color and halftoning we know that there is a huge amount of proprietary information an IHV is not willing to share. We will concentrate on the rather common and public information. That intention should please explain some limitations we set for ourselves in this phase. Our target is to provide a description for correct output, not necessarily for ultimate quality for e.g. raster graphic because of the reasons mentioned above. Any driver developer can feel free to develop a UPDF driver with additional functionality supporting the proprietary features considered IP. As a chair I feel responsible to keep our job on a realistic level and schedule. If more people and companies volunteer to contribute we can talk about extending our targets. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020216/fa66b315/attachment-0001.html From norbertschade at mediaone.net Sat Feb 16 16:59:25 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> halftoning Message-ID: <001d01c1b735$33144280$a8948018@ne.mediaone.net> We will support halftoning on the host by offering a place to specify matrices in predefined sizes of 8x8, 16x16 and 32x32. If a driver is not supporting all of the predefined sizes, it is supposed to provide internal fallbacks. If a UPDF description provides 16x16 or 32x32 matrices, do not expect it to provide 8x8 matrices additionally for fallbacks. We will support the selection of device internal halftoning by sending the proper command sequences at the proper place within a print stream. We think we can do that object specific (text, vector, raster), if required for a device. Be prepared to use a composite feature to accomplish that. We will not support downloading a halftoning matrix for any object. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020216/d12fe9b9/attachment-0001.html From norbertschade at mediaone.net Tue Feb 19 18:33:09 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> zooming element names Message-ID: <000c01c1b99d$ca697f00$a8948018@ne.mediaone.net> Two simple renames: MediaZoomingBySizeList is renamed MediaTargetSizeList. MediaZoomingAutomaticScalingList is renamed MediaScalingList. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020219/f809b944/attachment-0001.html From norbertschade at mediaone.net Tue Feb 19 18:57:26 2002 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> code flow booklet Message-ID: <001701c1b9a1$2ea93980$a8948018@ne.mediaone.net> The latest booklet spec has a Predefined_ID with only 'Unsorted' and 'Sorted'. Not yet on the web site! The code flow for a booklet implementation is supposed to work as follows: If 'Sorted' is selected, the driver has to provide a proper page flow. Implicitely this setting tells the driver that two logical pages per physical page are required as well as a duplex setting of short-edge. If 'Unsorted' is selected, this impies a duplex setting of simplex. A booklet setting overwrites the duplex setting, but we recommend to write a proper interdependency additionally. Booklet pages are supposed to be positioned centered by default. That would do for a simple booklet feature, realized as a check box. If booklet is part of a composite feature (the driver has to check for that), check whether target size is part of the composite feature as well. If so, check whether the target allows for two original sizes (e.g. Letter on Ledger, A4 on A3). If not, the driver is supposed to realize booklet by scaling. If so, by imposition. If MediaScaling is part of that c.f., check the setting. Default is centered! This would take affect in a sample like 'A5 on A3 Booklet', which would not be the standard case. We do not support virtual sizes for booklet printing. That means, if A5 is not part of the media size list, 'A5 on A4 Booklet' can not be realized. Comments??? Somebody like me may design a 'Media' c.f. with booklet as a component. This may result in the following records: Letter/Auto tray Letter/Tray1 Letter/Tray2 Letter/Auto tray Booklet Letter/Auto tray on Ledger Booklet Verify that the application is always thinking in Letter size. When you practice that, you should fully understand the implications. Otherwise ask now, as this is the time. This is my (personal!!!) approach how to implement a media feature. The user has one selection for a media with all media features selected in the background. This is not supported by any other device description than UPDF available today, not even close. By this implementation the driver can prevent the user from a number of errors he/she can do with other drivers. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@mediaone.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020219/f73c90f7/attachment-0001.html From norbertschade at attbi.com Tue Mar 5 11:51:38 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> Fw: Edge To Edge Printing Message-ID: <003901c1c466$049eaa60$a8948018@ne.mediaone.net> just a forward for Jim > > > >I brought this up a while ago but I'd like us to consider adding a feature > >for edge to edge (full bleed, zero margins, what ever you want to call > >it). I know this could be done using a generic feature and > >interdependencies but it seems like a common enough function that it > >should have its own specific feature. > > > >This feature would be used by printers that support both "compatible" or > >"standard" margins and no margins (printable area is the media size). When > >this feature is set to FALSE, the margin values specified with each media > >size would be used. When set to TRUE, margin values of zero would be used > >for all media sizes and rotations. > > > >Printers that only support either standard margins or no margins would not > >need to specify this feature. > > > >Jim > > mailto:sommer@granitesystems.com > 978-486-3068 > From norbertschade at attbi.com Tue Mar 5 11:56:26 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> Fw: Margins/Edge To Edge Message-ID: <004301c1c466$b044ed20$a8948018@ne.mediaone.net> and another one from Jim with a slight modification to the first edge-to-edge proposal > > I'd like to modify my request for an edge to edge feature. What I think we > really need is a "Margins" feature. This feature would have three settings: > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE in > my previous email. > 2) Printer Margins - This would be the same as setting Edge To Edge to > FALSE in my previous email. > 3) User Margins - This would allow the user to enter custom margins values > that are larger than the printer margins. > > Comments? > > If you forwarded my email to the group, it never made it. I didn't receive > it and I just looked in the archive and it's not there. I hope you haven't > lost contact too. > > Jim > > mailto:sommer@granitesystems.com > 978-486-3068 > > From jsommer at bellatlantic.net Wed Mar 6 13:45:41 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> Test Message-ID: <4.3.2.7.2.20020306134530.00c6fdc0@mailbox.bellatlantic.net> Please ignore. Jim mailto:sommer@granitesystems.com 978-486-3068 From norbertschade at attbi.com Fri Mar 22 10:20:33 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: Fw: UPD> Fw: Margins/Edge To Edge Message-ID: <005801c1d1b5$1c5c95c0$a8948018@ne.client2.attbi.com> While I'm implementing this into the standard I'd like to contradict to the third option. Isn't that a driver feature independent from any device functionality, which could be always added depending on the driver's philosophy? I still favour a boolean constraint. Norbert Schade ----- Original Message ----- From: "Norbert Schade" To: "UPD group" Sent: Tuesday, March 05, 2002 11:56 AM Subject: UPD> Fw: Margins/Edge To Edge > and another one from Jim with a slight modification to the first > edge-to-edge proposal > > > > I'd like to modify my request for an edge to edge feature. What I think we > > really need is a "Margins" feature. This feature would have three > settings: > > > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE in > > my previous email. > > 2) Printer Margins - This would be the same as setting Edge To Edge to > > FALSE in my previous email. > > 3) User Margins - This would allow the user to enter custom margins values > > that are larger than the printer margins. > > > > Comments? > > > > If you forwarded my email to the group, it never made it. I didn't receive > > it and I just looked in the archive and it's not there. I hope you haven't > > lost contact too. > > > > Jim > > > > mailto:sommer@granitesystems.com > > 978-486-3068 > > > > > From jsommer at bellatlantic.net Fri Mar 22 10:48:10 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> Fw: Margins/Edge To Edge In-Reply-To: <005801c1d1b5$1c5c95c0$a8948018@ne.client2.attbi.com> Message-ID: <4.3.2.7.2.20020322103532.00c431f0@mailbox.bellatlantic.net> Normally I'd agree with you - in fact that was the thought behind my original proposal. However, by creating an edge to edge feature instead of a margins feature, we're ignoring the common third setting (user defined margins) and requiring the driver to merge it's user margin function with the optional edge to edge feature. I think it's easier for a driver that doesn't support user margins to ignore that element than it is for a driver to do the merge (although I admit that either way it's a fairly simple thing to do). The compelling reason for me is the fact an edge to edge feature is just plain incomplete. It really needs to be a margins feature in order to completely specify all possible settings. Jim At 3/22/2002 10:20 AM, Norbert Schade wrote: >While I'm implementing this into the standard I'd like to contradict to the >third option. >Isn't that a driver feature independent from any device functionality, which >could be always added depending on the driver's philosophy? >I still favour a boolean constraint. > >Norbert Schade >----- Original Message ----- >From: "Norbert Schade" >To: "UPD group" >Sent: Tuesday, March 05, 2002 11:56 AM >Subject: UPD> Fw: Margins/Edge To Edge > > > > and another one from Jim with a slight modification to the first > > edge-to-edge proposal > > > > > > I'd like to modify my request for an edge to edge feature. What I think >we > > > really need is a "Margins" feature. This feature would have three > > settings: > > > > > > 1) No Margins - This would be the same as setting Edge To Edge to TRUE >in > > > my previous email. > > > 2) Printer Margins - This would be the same as setting Edge To Edge to > > > FALSE in my previous email. > > > 3) User Margins - This would allow the user to enter custom margins >values > > > that are larger than the printer margins. > > > > > > Comments? > > > > > > If you forwarded my email to the group, it never made it. I didn't >receive > > > it and I just looked in the archive and it's not there. I hope you >haven't > > > lost contact too. > > > > > > Jim > > > > > > mailto:sommer@granitesystems.com > > > 978-486-3068 > > > > > > > > From norbertschade at attbi.com Mon Apr 1 10:51:44 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> mistake in job settings of generic features Message-ID: <000f01c1d995$200c0e20$a8948018@ne.client2.attbi.com> There was an editor's mistake in the JobSetting elements of the generic features. The entry for Job_Keyword and Job_Parameter were switched in all four features. Repaired, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/8026b811/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 10:54:18 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> MediaMinimumMargins Message-ID: <001801c1d995$7d1ea780$a8948018@ne.client2.attbi.com> After the change concerning MediaMimimumMargins a few days ago I now have removed the generic feature EdgeToEdge from the sample and transferred all the entries into the new feature for minimum margins. Finished, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/7b9f409d/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 11:02:28 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> agenda item: halftoning Message-ID: <002101c1d996$9fccb780$a8948018@ne.client2.attbi.com> We have finished the final proposal for halftoning. We do not support any kind of download in UPDF. That is valid for halftoning as well. We do support separate halftonings for text, vector and raster objects. Only for raster objects you can specify a host matrix. Predefined sizes for host matrixes are 8x8, 16x16, 32x32. Command elements can be used for all three object styles. Not yet provided in the sample. Can somebody sent me a simple standard 8x8 matrix? Please check whether you can accomplish all you need with the current design. This will be one major agenda item. Prepare samples. In case we'll decide on making this the official design the TBD_ prefix will be removed right after the conference. Not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/6308b937/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 11:35:48 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> agenda item: driver specific locale xml Message-ID: <002c01c1d99b$47cc1580$a8948018@ne.client2.attbi.com> While we have a nice schema to store all UPDF related text string entries, we do not expect these to be all text strings a driver is using. Just to give a sample we are not yet supporting any button strings nor error messages and I guess there is a whole lot of other string areas commonly used by a driver. However these text strings are typically quite driver specific, meaning two drivers have a different set of them. We are discussing a solution that all driver developers provide all their text strings exceeding the UPDF device description in a standardized way. The simplest idea is to use the UPDF locale schema for this purpose as well. The UPDF specification is not involved in naming these driver specific locale xml files. They are likely different per driver. Nor do we provide a place to store these names, namely not in the device configuration file. Every driver would know about its own files anyhow. This is considered a contribution to an easy translation process of all text strings with one consistent structure. Just to mention it: We are not concerned about hot keys, as the format does not specify where in a user interface a feature control may appear. This heavily affects the Locale elements MandatoryLocaleElements and ProprietaryLocaleElements, which perhaps both would be moved to the driver locale files. This item will be finally decided at the conference. It would ease the process if you provide your comments upfront. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/97e79aaa/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 12:33:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> public keys Message-ID: <004e01c1d9a3$587f02e0$a8948018@ne.client2.attbi.com> During implementation we learnt that a slightly different strategy with the public keys is of advantage. The driver can check the value of any feature attribute any time, at least in theory. The driver knows the interface to the operating system and the applications best as well. So it does not seem right to create public keys for platform settings (like provided in a devmode structure under Windows). An example is DRV_Copies, which had been created as a public key. This entry is removed from the list. Any driver has to check if a driver's feature is overwritten by the application's job setting. This may vary a lot from platform to platform. With the sample of copies the driver knows the setting of copies in the driver's user interface, but has to check, if the application is sending a print job with a different copy setting, which would have a higher priority than the setting in the driver's UI. Comments? Changed, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/7913cdfc/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 12:49:53 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> ID mandatory Message-ID: <005d01c1d9a5$a1658220$a8948018@ne.client2.attbi.com> Some of the latest details on the reflector are initiated by the driver implementation we are working on heavily the last weeks, while most contributions the years before were purely based on the specification of the format. That demonstrates as well that we have been able to ease the implementation work over time. The newest change is to make the ID attribute mandatory in every element where it is not fixed. This allows the code to rely on a unique value per feature. Finished, not yet on the web. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/3911be59/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 12:54:12 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> syntax of margin values Message-ID: <006601c1d9a6$3b54db60$a8948018@ne.client2.attbi.com> To further ease the driver implementation we have changed the syntax for margin values slightly. While you found values like 'margin_left_0.250in' before, which is a very similar syntax to the media size syntax in the predefined media standard, we now have eliminated the first two components and you will find values like '0.250in' in future. this helps avoiding wrong entries (e.g. 'Left = margin_top_0.250in'), while the same routing can now be used to interpret all margin values. Finished, not yet on the web site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/e97261d1/attachment-0001.html From norbertschade at attbi.com Mon Apr 1 13:02:22 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> update web site Message-ID: <006f01c1d9a7$5fe08500$a8948018@ne.client2.attbi.com> I have updated the UPDF web site. So you will find all changes announced so far today on the web site in directories 'XML Schemas' and 'XML Samples based on schemas'. You can use the links provided on the UPDF site. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020401/0de2c0a1/attachment-0001.html From norbertschade at attbi.com Thu Apr 18 20:06:45 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> proposed agenda for 4/19/02 Message-ID: <001301c1e736$180c6400$a8948018@ne.client2.attbi.com> 1. Current development status of the UPDF specification and the host implementations This will include some demonstrations to the extent that everybody feels confident with the current level. Review of command sequences. No more job settings. 2. Locales 2.1. Mandatory strings 2.2. Driver strings 2.3. New sections: Error messages, etc.??? Final decision. 3. Halftoning Final decision. 4. Raster graphic and color We have prepared a real proposal. Target is to agree to this proposal, probably in a reviewed version. Further smaller changes are expected during host implementation, especially in the area of color. 5. User interface structure Do we want that as part of level 1? 6. Some ideas Although not planned for level 1, we think about some ideas from time to time, as there are: Interleaving, Hooks, Bidirectional communication. 7. Outlook One more conference considered necessary (Portland?) for technical closure of spec. A second one possible with concentration on documentation. Finishing procedures, last call, etc for UPDF level 1. Business plan for host implementations. Elaborated device descriptions from IHV required. See you tomorrow Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020418/a0edb5b0/attachment-0001.html From harryl at us.ibm.com Thu Apr 18 20:24:49 2002 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:16 2009 Subject: UPD> proposed agenda for 4/19/02 Message-ID: I'd like to suggest we also discuss possible use of UPDF in the context of the new PSI project. This topic came up this week at the first PSI meeting. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Norbert Schade" Sent by: owner-upd@pwg.org 04/18/2002 06:06 PM To: "UPD group" cc: Subject: UPD> proposed agenda for 4/19/02 1. Current development status of the UPDF specification and the host implementations This will include some demonstrations to the extent that everybody feels confident with the current level. Review of command sequences. No more job settings. 2. Locales 2.1. Mandatory strings 2.2. Driver strings 2.3. New sections: Error messages, etc.??? Final decision. 3. Halftoning Final decision. 4. Raster graphic and color We have prepared a real proposal. Target is to agree to this proposal, probably in a reviewed version. Further smaller changes are expected during host implementation, especially in the area of color. 5. User interface structure Do we want that as part of level 1? 6. Some ideas Although not planned for level 1, we think about some ideas from time to time, as there are: Interleaving, Hooks, Bidirectional communication. 7. Outlook One more conference considered necessary (Portland?) for technical closure of spec. A second one possible with concentration on documentation. Finishing procedures, last call, etc for UPDF level 1. Business plan for host implementations. Elaborated device descriptions from IHV required. See you tomorrow Norbert Schade From norbertschade at attbi.com Mon Apr 22 13:36:10 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> ICC profiles Message-ID: <000a01c1ea24$332e9e60$a8948018@ne.client2.attbi.com> We have agreed that we will support device color handling in UPDF. Although we are not really working with ICC profiles within the spec, it was proposed to list references for them, so that a driver/client would know which ones it can expect to find. this is more or less an installer function, but ok. I propose to add a new tag to the device and option configuration files to do that. A protocol managing the transfer from a device or network would then find all necessary file names in the configuration files. More than one profile could be listed (optional, multiple). The spec would not tell the driver when to use which. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/82ff3d51/attachment-0001.html From jsommer at bellatlantic.net Mon Apr 22 14:38:23 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> ICC profiles In-Reply-To: <000a01c1ea24$332e9e60$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020422143743.00bc4320@mailbox.bellatlantic.net> I agree that the device configuration file is the right place to reference the ICC profile. At 4/22/2002 01:36 PM, Norbert Schade wrote: >We have agreed that we will support device color handling in UPDF. >Although we are not really working with ICC profiles within the spec, it >was proposed to list references for them, so that a driver/client would >know which ones it can expect to find. this is more or less an installer >function, but ok. >I propose to add a new tag to the device and option configuration files to >do that. A protocol managing the transfer from a device or network would >then find all necessary file names in the configuration files. >More than one profile could be listed (optional, multiple). The spec would >not tell the driver when to use which. > >Comments??? > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/e0f919d6/attachment-0001.html From norbertschade at attbi.com Mon Apr 22 16:51:27 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> web site update Message-ID: <000a01c1ea43$c4e2f080$a8948018@ne.client2.attbi.com> I've updated the schemas and xml file on the UPDF web site. The latest agreed functionality is already incorporated. ColorHandling, Halftoning and RasterObjects have lost its TBD_ status and are fully activated. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/223578c5/attachment-0001.html From norbertschade at attbi.com Mon Apr 22 19:14:40 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> color handling for experts Message-ID: <003201c1ea53$7b208b00$a8948018@ne.client2.attbi.com> We have activated the latest color handling design after last Friday's meeting in Boston. the group agreed to the design as it was with only few comments. we moved the PlaneImplementation attribute up one level from the Plane element to ColorMode, as this has to be consistent per ColorMode. the attribute is now mandatory to avoid consistency problems of a device description, although the entry is redundant in case of Predefined_ID=monochrome (Predefined_ID is the attribute with the higher priority). Don't create a Plane element for monochrome either. if PlaneImplementation=PerPixel, don't create a Plane element either. A driver should ignore it anyhow in this case. we have added an entry (PerPixel) to the data type plane-implementation-enum. The UPDF spec assumes that the driver will get a RGB (not necessarily sRGB) input and can create color output for R, G, B, C, M, Y, K, W planes. you may comment on the white plane. The spec expects device color handling for the remaining functionality. The spec expects the device to understand 8bpp per plane. By limiting the spec to 8bpp, we want to make it easy for all host implementations, as all drivers must support all implementations. Additionally we think that many devices support 8bpp. We know there are other solutions out there. In case an IHV wants to develop a host implementation for different bits per pixel or would provide a huge number of device descriptions plus detailed information how to manage it, so that we can create a proper schema and drivers can properly handle it with short-term development time, please step up and contact us now. Some MS Windows stuff, which can pop up in a similar way under other platforms as well: the dmColor setting is provided by the color-mono-enum attribute. the dmBitsPerPel setting is supposed to be 24 for all color modes. The dmICMMethod setting needs a minute. Check if you agree with the following description, which would become valid if nobody complains the next days. We assume there is an ICC profile tag in configuration schemas (see previous email today). In this sample we do not assume the driver has its own color correction functionality. A driver may want to show an ICM control in the UI with possible entries of SYSTEM, NONE and/or DEVICE. This is supposed to be a driver feature. UI strings should be provided in the driver's locale xml file. 1. There is no device halftoning nor ICC profiles. The only entry is NONE. 2. There is device halftoning, but no ICC profiles. Entries NONE and DEVICE (default). 3. There is no device halftoning, but ICC profiles. Entries NONE and SYSTEM (default). 4. There are device halftoning and ICC profiles. I'm not sure if I'd do that. But if, my driver would treat the ICC profiles with a higher priority. Under Windows that may result in entries NONE, SYSTEM (default) and DEVICE. same under platforms with the same environment. If the platform does not support ICC profiles, the driver should use the device halftoning. If the platform supports ICC profiles, but no flag to communicate any related driver setting to the OS API, the driver should announce the ICC profiles, but ignore the device halftoning. Please comment if you have any preference for dmICMIntent. Otherwise we leave that to the driver and treat it as a driver feature. Do we want a Predefined_ID for dmDitherType? this could turn out to be quite tricky, as we have three different halftoning elements, in which case we could concentrate on the RasterHalftoning. Some said during the meeting they have to think more about the whole block of raster graphic, color hanlding and halftoning, which I understand. however this is the time to comment. We are quite confident that the current design (perhaps with some adjustments due to dmICMIntent or dmDitherType) can very well work as a generic description of color and graphic related device capabilities. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020422/0ef7248f/attachment-0001.html From norbertschade at attbi.com Tue Apr 23 13:43:30 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> Latest Meeting Minutes Message-ID: <001101c1eaee$621f0280$a8948018@ne.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/e68fd3c5/Latest_Meeting_Minutes-0001.htm From norbertschade at attbi.com Tue Apr 23 15:29:15 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> User Interface Message-ID: <002901c1eafd$27de7380$a8948018@ne.client2.attbi.com> At the conference last week we could only spend little time on the question whether UPDF, level 1, needs a rough description of the intended user interface dialog structure. During the meeting we saw a number of problems popping up with that intention. 1. Might become a quite complex section. We would have to limit ourselves to a certain common denominator, as we request any UPDF driver to support the full set of functions if it uses a feature. 2. Perhaps several user interface structures for different platform environments (PC desktop, cell phones, cameras, etc.). Please provide your comments the next two weeks. Would it help you or rather be an obstacle to have a UI structure as part of UPDF??? Richard Hart from Compaq will do some investigation about TLC, which apparently could be used as a run-time language for dialog handling. that would be another direction. Other helpful alternatives in sight? We will leave the TBD_UserInterface structure in the schema for a while for demonstration purpose to ease the discussion, although we are not using it in the sample. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/f6b2d127/attachment-0001.html From norbertschade at attbi.com Tue Apr 23 16:31:01 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> greyscale Message-ID: <000e01c1eb05$c8cfa5e0$a8948018@ne.client2.attbi.com> Now that we have raster graphic and color structures, we can discuss a number of models. Let's think about a printer which is kind of PCL like. 1. A clean bitonal black/white monochrome printer. that's a clear case. One ColorMode record with Predefined_ID=monochrome, which means the PlaneImplementation attribute will be ignored (set it to PerPixel anyhow). No Plane element will be defined. I would define the ColorHandling feature hidden (Appearance). 2. A RGB color device. You may define the same ColorMode record as in #1. Additionally you likely have a color record, perhaps with PlaneImplementation=PerScanline (or PerPixel depending on your favorite implementation and the drivers' capabilities). Three Plane elements defined with the proper colors, Appearance active. Nothing fancy. 2.a. The #2 device with an additional greyscale mode. Implementation can vary. It might just be an additional job command sequence. So you would create an additional ColorMode record with the proper entries (only the Command element would be different). Not really complicated with a cautious implementation. 3. Hypothesis: There is a new device, which needs a true greyscale input. Condition 1: the UPDF driver has to support a color to greyscale conversion. Do we expect a UPDF driver to do that? Condition 2: The ColorMode record for greyscale would have one black plane (my personal opinion!), but no other planes. Keep in mind that the Predefined_ID of ColorMode is meant to tell the operating system about the color capabilities. this attribute has nothing to do with what the driver is sending to the device! Does that sound reasonable to you or do we just forget about #3? You may take this as a case study to check the power and flexibility of the spec. Please contribute to the discussion. it educates us all. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020423/88b6c849/attachment-0001.html From norbertschade at attbi.com Thu Apr 25 15:17:07 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> ICC profiles Message-ID: <000a01c1ec8d$caf237a0$a8948018@ne.client2.attbi.com> we try to solve some relationship to ICC profiles. is it possible to build one profile with more than one media type and/or more than one dither type??? short and quick note appreciated. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020425/5620dec0/attachment-0001.html From norbertschade at attbi.com Fri Apr 26 15:43:49 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> User Interface, 2. Message-ID: <000e01c1ed5a$aff086a0$a8948018@ne.client2.attbi.com> We have spent a bit more time on the design of a user interface structure and think this should be the proposal to discuss. 1. We have moved the user interface section to the Locale schema. that allows a different UI for different locales (think about Arabic, Hebrew, Asian, etc.). 2. The design units are pixel. The developer of a device description is strongly recommended to follow a standard VGA (640x480). This should leave enough room for design. Higher resolution are expected to go with the designed positions. If a driver knows about the screen resolution and it's lower than VGA, it could downsize by recalculating the values. Therefore it needs to rely on a reference resolution. 3. As you can see in the latest design, there is a Logo attribute to the DeviceConfiguration element of the device configuration schema. This is supposed to be a file name reference for one picture and would typically be used for a company logo. When you check the Control element you see that you can use that picture everywhere in the UI, even multiple times. The only supported picture format would be JPEG. 4. A Configure dialog like any other dialog considered part of Device Properties is not part of a device description. It is a generic dialog created by the driver by reading and interpreting the device's configuration files. 5. Composite features can be handled as any other feature in the UI design. As we discussed the driver may offer a subdialog to view and/or edit the components of a c.f. as well as to add a new set of components or remove a user defined one. This functionality is supposed to be supported under Device Properties and cannot be influenced by the UI design. 6. A dialog for managing custom media sizes is as well considered part of Device Properties and not available for UI design. 7. As you can see a PushButton can be specified as a special predefined button (OK, Cancel) or to open a subdialog - again a predefined dialog (About) or any of the UPDF design dialogs (by referencing the dialog ID). One button can only open one dialog. If you think further about this you see that tabs on tabs are not possible. 9. The order of the dialogs is supposed to be: system dialogs, generic driver dialogs, UPDF dialogs in the order they are designed. 10. Labels As you can see the latest design show a Label element under some controls. That means you are absolutely free in designing the position and size of any feature control (like a combo box) and its label. Regards from Murphy! Quintessence: If we'd allow a UI design as part of the UPDF specification, we consciously limit ourselves to a certain set of functionality, as every driver is expected to interpret all tags properly. However the UserInterface structure will certainly be optional. And a driver is allowed to ignore any designed section while working with its own design. We do not think of allowing multiple user interfaces per locale, but just one. While the design screen is supposed to be a graphic desktop of some kind, we think the structure can also be used by a command line type of desktop (which would ignore position attributes, of course). Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/b0823362/attachment-0001.html From norbertschade at attbi.com Fri Apr 26 15:46:18 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> User Interface, help Message-ID: <001701c1ed5b$093723e0$a8948018@ne.client2.attbi.com> An important detail: The UPDF spec will not cover any help file support. However we have added a Help_ID attribute to the Control element of the user interface design - another argument to manage the user interface in the locale schema. This is supposed to enable a context-sensitive kind of help per control. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/db40a8c5/attachment-0001.html From jsommer at bellatlantic.net Fri Apr 26 16:25:46 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> User Interface, 2. In-Reply-To: <000e01c1ed5a$aff086a0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020426161940.00bb7e88@mailbox.bellatlantic.net> This looks good to me. My one comment is on: >9. The order of the dialogs is supposed to be: >system dialogs, generic driver dialogs, UPDF dialogs in the order they are >designed. I would day the order is: system dialogs, UPDF dialogs, generic driver dialogs When a driver UI is presented, I think it should present the most commonly used features on the first dialog. Therefore I think the UPDF dialogs should come first since they are setting the basic features of the printer (media size, media type, source, copies, etc) and the driver dialogs are setting advanced features (watermarks, custom paper sizes, device configuration, composite feature editing). Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020426/ef450378/attachment-0001.html From jsommer at bellatlantic.net Fri Apr 26 19:14:43 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> Compressions Message-ID: <5.1.0.14.2.20020426171234.00bc4e20@mailbox.bellatlantic.net> I would like to propose the following initial list of compressions for raster objects: PCL5 - the compression methods as defined by the PCL5 spec (uncompressed, RLE, TIFF, delta row, adaptive) PCL6 - the compression methods as defined by the PCL6 level 1.1 spec (uncompressed, RLE) PCL6_JPEG - the JPEG compression method as defined by the PCL6 level 2.0 spec PCL6_DELTAROW - the delta row compression method as defined by the PCL6 level 2.1 spec PS - the compression methods as defined by the PostScript level 2 spec (uncompressed, RLE, JPEG) PS_LZW - the LZW compression method as defined by the PostScript level 2 spec PS_FLATE - the Flate compression method as defined by the PostScript level 3 spec JPEG - standard JPEG compression in JFIF format JBIG2 - standard JBIG2 compression FAX_G3 - CCITT Group 3 fax compression FAX_G4 - CCITT Group 4 fax compression If anyone knows of any other compression methods that are commonly used by printers we can certainly add them. Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Mon Apr 29 08:12:02 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> color handling for experts In-Reply-To: <003201c1ea53$7b208b00$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020429065627.00ba4500@mailbox.bellatlantic.net> I think that we should have Color Correction Method and ICC Intent features but not dmDitherType. The Color Correction Method feature should have the three settings that Norbert outlined (none, device, system). This feature will allow a user to enable and disable color correction. If a device has both an ICC profile and device color correction, then the user can also choose between the two methods. Since we are saying that we support color correction using ICC profiles, then we should support the once basic ICC control which is intent. The ICC Intent feature should have four settings (perceptual, media-relative colorimetric, saturation, ICC-absolute colorimetric). These settings are defined in the ICC profile specification. This feature will allow the user to direct ICC profile-based color correction for their particular print job. I don't think that we should have a feature associated with dmDitherType. It's use in Windows is not clear - does Windows ICM do the dithering or is it just an indication of how the driver or device is supposed to do the dithering? This is a global setting whereas we already have object specific settings so what would the interaction be? I think we should just leave this out unless someone can come up with a clear case for adding support. Jim From jsommer at bellatlantic.net Mon Apr 29 09:05:49 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> greyscale In-Reply-To: <000e01c1eb05$c8cfa5e0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020429085651.00bcfb90@mailbox.bellatlantic.net> >3. Hypothesis: There is a new device, which needs a true greyscale input. >Condition 1: the UPDF driver has to support a color to greyscale >conversion. Do we expect a UPDF driver to do that? >Condition 2: The ColorMode record for greyscale would have one black plane >(my personal opinion!), but no other planes. I think we need to address the case of grayscale printing on a color device. I know of devices that always print in color unless grayscale data is sent. What if we added a DeviceFeature attribute on the ColorMode element to indicate if the driver needs to create the grayscale data or if the command sequence will cause the device to do the grayscaling? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020429/f72cb8fc/attachment-0001.html From norbertschade at attbi.com Mon Apr 29 13:24:38 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> media standardized names: media types Message-ID: <000a01c1efa2$be21a160$a8948018@ne.client2.attbi.com> in the spec mentioned above there is a list of predefined media types. ICC profiles have a special reference to media types as well. this is commonly considered a very Microsoft specific flag. it is reflected in wingdi.h of the DDK. please check values for Standard, Transparency, Glossy and user defined. When thinking about that for a moment it becomes clear that any driver has to announce the same media type values for the driver as are used within the ICC profiles. Otherwise Windows would make wrong assignments, a process which is not influenced by a driver. ICC media type consistency statement that means it is essential that predefined media types have the same predictable value used by drivers and ICC profiles. Request We need a public table with values for predefined media types as listed in the media standardized names spec. Either this has to be added to that spec (my favorite option) or we have to create such a list within UPDF. but this is not a UPDF specific condition. all drivers face the same development condition. Checking the rules for media types in Windows, it seems useful to me to reserve all values up to 255 for Microsoft and their predefined values (currently only 0, 1 and 2 are used). A list for other predefined media types should use the range from 256 to 511, while higher values are open for arbitrary types (would mean proprietary types in the UPDF language). Do you agree with my view of the conditions? Who should create the public list? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020429/aafa68e1/attachment-0001.html From norbertschade at attbi.com Wed May 1 12:38:09 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> User Interface, 2. References: <5.1.0.14.2.20020426161940.00bb7e88@mailbox.bellatlantic.net> Message-ID: <002001c1f12e$94400de0$a8948018@ne.client2.attbi.com> reasonable input. fine with me. I will propose this way from now on. it is left to the driver anyhow, but I appreciate common behavior. Norbert ----- Original Message ----- From: Jim Sommer To: UPDF Sent: Friday, April 26, 2002 4:25 PM Subject: Re: UPD> User Interface, 2. This looks good to me. My one comment is on: 9. The order of the dialogs is supposed to be: system dialogs, generic driver dialogs, UPDF dialogs in the order they are designed. I would day the order is: system dialogs, UPDF dialogs, generic driver dialogs When a driver UI is presented, I think it should present the most commonly used features on the first dialog. Therefore I think the UPDF dialogs should come first since they are setting the basic features of the printer (media size, media type, source, copies, etc) and the driver dialogs are setting advanced features (watermarks, custom paper sizes, device configuration, composite feature editing). Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020501/22f7c07d/attachment-0001.html From norbertschade at attbi.com Tue May 7 19:55:47 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> some small items Message-ID: <003301c1f622$b58fb6a0$a8948018@ne.client2.attbi.com> 1. is there interest to extend our list of DRV_keys to some job and user related variables??? samples could be: a.. job id b.. user name c.. user id d.. workstation e.. domain f.. application sending the document g.. document name may be you have a longer list. 2. we still think about the file formats we might support for pictures, if we support them in a UI. first idea was JPEG. what about gif??? target is to decide on one eventually. 3. I request bytes instead of kilobytes in the band_units_enum. the background I have in mind a quite dirty. may be the driver is not only concerned about a print head height or maximum input buffer, but also to create small enough snippets to allow an application (like a language monitor or what our Linux friends call a client) to hold the job for a moment and communicate to the device. I know this attribute would not be enough but it allows small snippets with a byte number. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020507/a0708735/attachment-0001.html From jsommer at bellatlantic.net Wed May 8 07:28:58 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:16 2009 Subject: UPD> some small items In-Reply-To: <003301c1f622$b58fb6a0$a8948018@ne.client2.attbi.com> Message-ID: <5.1.0.14.2.20020508072634.00bd2e78@mailbox.bellatlantic.net> At 5/7/2002 07:55 PM, Norbert Schade wrote: >1. is there interest to extend our list of DRV_keys to some job and user >related variables??? > >samples could be: > * job id > * user name > * user id > * workstation > * domain > * application sending the document > * document name >may be you have a longer list. > I don't have a problem with this. In fact I would add job name to the list. >2. we still think about the file formats we might support for pictures, if >we support them in a UI. >first idea was JPEG. what about gif??? >target is to decide on one eventually. I believe that GIF has some patent issues with it. > >3. I request bytes instead of kilobytes in the band_units_enum. >the background I have in mind a quite dirty. may be the driver is not only >concerned about a print head height or maximum input buffer, but also to >create small enough snippets to allow an application (like a language >monitor or what our Linux friends call a client) to hold the job for a >moment and communicate to the device. I know this attribute would not be >enough but it allows small snippets with a byte number. > OK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020508/a306d324/attachment-0001.html From norbertschade at attbi.com Thu Jun 20 08:40:56 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> meeting in Portland Message-ID: <001601c21857$bbcb9d20$a8948018@ne.client2.attbi.com> Alan, we talked a bit about the PSI group and its targets at our last meeting in Boston. Harry suggested that we'll exchange information between the UPDF and PSI standards to find out if we can help each other. Jim Sommer and I will be in Portland on Wednesday. So you would have two of the current three leaders of the UPDF group present. We will join your group - at least in the morning sessions. If you like, we could do some presentation, perhaps about an hour. Let me know, if you have some preferences. This may very well line up with the plenary next day and the attempt to find synergies between the various groups. Would do you think? I have subscribed to your list a minute ago, but do not know if it works already. so I'd prefer a direct copy of the answer. Is there any must-read document we have to study to get a feeling what your main objectives are, other than general knowledge what a print server might want to do? Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020620/7d286210/attachment-0001.html From norbertschade at attbi.com Fri Jul 5 11:50:13 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> hw margins Message-ID: <001301c2243b$a6f771e0$a8948018@ne.client2.attbi.com> Change request based on the Portland meeting. hw margins before the change we had two different margin elements. We wanted the user to work with as few elements as possible. now that we have one only, the user may feel more convenient when doing the same procedure all the time. that's why we made the margins element mandatory. MediaSizeHardwareMarginsLandscape removed. MediaSizeHardwareMargins 1-2 elements with new mandatory attribute Orientation with margins-orientation-enum constraint. Device Description changed accordingly. Files not yet copied to the web. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020705/a8508115/attachment-0001.html From norbertschade at attbi.com Mon Jul 8 10:32:20 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> Semantic model: media handling Message-ID: <001a01c2268c$4544aa00$a8948018@ne1.client2.attbi.com> I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020708/ea976b89/attachment-0001.html From hamzy at us.ibm.com Mon Jul 8 18:49:58 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:16 2009 Subject: UPD> Re: [Foomatic] request for full PPD specification compliance Message-ID: > UPDF creators being obliged to use a free license would be GREAT, but I > think if the group would agree with that, they will open the liberty of > using MIT, BSD, or LGPL licenses as HP uses for HPIJS and their PPDs or > also IBM for Omni. But that would be no problem. The problem will be > when there are proprietarily licenced UPDFs. I was hoping for a simple, free license that I could easily point at. I do not think that the leader of the UPDF group would be opposed to requiring that the files use the license in order to comply with the UPDF specification. We should also place some education in the UPDF manuals/specs as for the need of a properly free license. Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at attbi.com Sun Jul 14 19:11:54 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> resolution and related features Message-ID: <003e01c22b8b$d868f1c0$a8948018@ne1.client2.attbi.com> We could define a syntax for Predefined_ID/Proprietary_ID in two-dimensional features like 'keyword' + '_' + horizontal value + 'x' + vertical value (leans heavily on the standardized media names spec). This could be used for virtual units: units_7200x7200 raster resolution resolution_600x600 positioning positioning_300x300 As a matter of fact we already use it for nup: nup nup_1x1 (new due to a change discussed in Portland, will be on the web within next days) would that solve everything so we could work with Predefined_ID/Proprietary_ID in all these features? General requirement for that kind of syntax: 1. The entry in the Predefined_ID follows the same syntax as the entry in the Proprietary_ID. 2. For positioning we cannot generally expect that a positioning command specifies both the horizontal and vertical dimension. So we have to tell about omissions. The simplest rule might be that the 'x' must be there, the value not necessarily. That would allow 'positioning_300x300', 'positioning_300x' as well as 'positioning_x300'. Another thought: We might remove the feature device resolution completely from our standard, as we consider it a generic feature. Drivers really don't use it for rendering, only for sending a JCL command to the device. Drivers don't even really save it in any kind of device capabilities structure other than just storing the last UI setting. And we could as well do some calculation in the command sequences, if the device resolution is 1200dpi and the raster resolution is 600dpi so that the positioning parameter has be multiplied by 2, as any value coming from the application/system will be based on the raster resolution. The fact that some raster resolutions only go with certain device resolutions, is a matter of dependencies and simple. Comments??? Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020714/a6a20402/attachment-0001.html From norbertschade at attbi.com Sun Jul 14 21:05:55 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:16 2009 Subject: UPD> Portland meeting minutes Message-ID: <00c401c22b9b$c613b220$a8948018@ne1.client2.attbi.com> Although there was no official UPDF meeting scheduled for Portland, Mark Hamzy, Jim Sommer and I joined parts of the PSI meeting and the full-day plenary to represent our interests. However we took the time to meet on Wednesday afternoon (6 hours) and Thursday evening (two hours) to discuss some open issues we could not resolve in emails and phone calls. These were the major issues: 1. ICC profiles We will add an element References under 'PrintCapabilities' like 'Features' and 'Objects. The only element underneath will be 'ICC_Profiles'. That way we can list as many profiles as we want and can select them with dependencies like features and objects. Expect to hear more the next days. 2. Hardware margins We have added an attribute 'Orientation' to 'HardwareMargins' and could now save an extra margins element for landscape. It's easier to implement it this way on the host. 3. Dependencies We shortened the term 'Interdependencies' to 'Dependencies'. The structure was changed as well. We do not support the definitions of 'OR' conditions any more. It is too complex to write a parser, which would understand all possible varieties of conditions. And we want to encourage people to read the xml on-the-fly. Now it is necessary to split previous 'OR' conditions into separate conditions. On the other hand we have a simpler structure. It is still possible to combine as many features as you want in one condition. And the complete action section is more or less unchanged. The attribute 'Relation' is now constrained to 'equal' and 'not-equal', as we did not find any sample where 'less' and 'larger' really was needed. More details to come for the interested expert. 4. Classifying identifyers In general we are intending to consistently work with Predefined_ID/Proprietary_ID attributes wherever possible. You will see a number of related changes. This eases the host implementation as well. 5. Syntax problems We were discussing some global syntax problems for some time, but we could solve all of them. One major change to accomplish that is to allow IHV to add their own namespace to UPDF if needed. The cases where useful of needed will be rare, but it provides for a consistent syntax all over the place when it comes to command sequences and parameters referenced within them. See samples coming up. 6. Common PWG Semantic Model The PWG declared the IPP concept the base for the common Semantic Model and defined a set of schemas to document that. We will check, how close UPDF already is to these structures and discuss open issues with them. That will be one of our main activities the next weeks. 7. UPDF as common base for device capabilities under IBM Linux solutions. There is some discussion going on in a Linux forum, where the PWG and IBM are actively contributing. One option is to take UPDF as their common format to store driver capabilities by using it. This is a very interesting approach and proves that the UPDF standard is on an excellent level. This is another activity we will persue in the near future. 8. Print Services As many may know there is a new group in the PWG community called Print Services. They are checking UPDF and probably may use some of the functionality to accomplish some of their targets. Another field where the hard work we did over the last years will pay out. We are supporting them as much as we can, as we consider that activity very close to a driver. 9. We invite all IHV to start some UPDF implementations, as we have the host implementations under MS Windows and IBM Linux working to quite a good level. Now it's the time to get device descriptions checked. So start writing them and let us know, if you need help. We will send another note through the PWG reflector to get the message around. You see we could cover a lot of bases in two very effective meetings. We do not plan to meet in Santa Fe, but most likely we will meet in New Orleans. In the meantime we will continue with the host implementation and finish the UPDF design for level 1 section by section. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020714/391464ed/attachment-0001.html From harryl at us.ibm.com Wed Jul 17 11:34:40 2002 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:16 2009 Subject: UPD> RE: PS> Semantic model: media handling Message-ID: I like Bob's analysis. I think the Semantic Model will be most useful taking this approach. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "TAYLOR,BOB (HP-Vancouver,ex1)" Sent by: owner-ps@pwg.org 07/16/2002 09:13 PM To: Norbert Schade , Print Services group cc: UPD group Subject: RE: PS> Semantic model: media handling Hi Norbert, all, One of the things we (HP) have been suggesting for the semantic model is the separation of the raw "attribute/element" definitions from the structures/model that pull them together for a particular use. As you not, UPDF has done this structuring in a different way than IPP - which is also somewhat different than UPnP & PSI, etc. I'm not sure we want to try codify any one structure as part of the core semantic model - these will tend to vary by market segment and domain, and I'm not sure we can do this one-size-fits-all. What we would like to see, though, is common definition of the core "attributes/elements" - this seems much more reusable across models & domains. It does make sense, though, to publish some of the "common models" as at least examples of structural models - IPP, UPDF, etc. are likely candidates for this. This exposes some of useful constructs (such as the composite feature you describe below) for reuse. thanks, bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:robertt@vcd.hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -----Original Message----- From: Norbert Schade [mailto:norbertschade@attbi.com] Sent: Monday, July 08, 2002 7:32 AM To: Print Services group Cc: UPD group Subject: PS> Semantic model: media handling I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020717/1623e816/attachment-0001.html From NorbertSchade at oaktech.com Wed Jul 17 16:05:39 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> data type separation Message-ID: Bob, I attach the current version of our current data types schema. If I understand your vision properly, this should exactly demonstrate the separation of attribute structures and the overall implementation - in our case the UPDF device description schemas. Depending on how close we'll come eventually, I could imagine taht we even include a Semantic Model data type schema within the UPDF data type schema and take the duplicates out of our current version. But I don't want to be too optimistic, before I see a clear path of the Semantic Model. And there could be some other significant requirements specific to a UPDF device description. Regards Norbert (See attached file: UPDF Data Types.xsd) "Harry Lewis" m.com> cc: Norbert Schade , Print Services group , UPD group Sent by: owner-upd@pwg Subject: UPD> RE: PS> Semantic model: media handling .org 07/17/2002 11:34 AM I like Bob's analysis. I think the Semantic Model will be most useful taking this approach. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "TAYLOR,BOB (HP-Vancouver,ex1)" To: Norbert Schade Sent by: owner-ps@pwg.org , Print Services group cc: UPD group 07/16/2002 09:13 PM Subject: RE: PS> Semantic model: media handling Hi Norbert, all, One of the things we (HP) have been suggesting for the semantic model is the separation of the raw "attribute/element" definitions from the structures/model that pull them together for a particular use. As you not, UPDF has done this structuring in a different way than IPP - which is also somewhat different than UPnP & PSI, etc. I'm not sure we want to try codify any one structure as part of the core semantic model - these will tend to vary by market segment and domain, and I'm not sure we can do this one-size-fits-all. What we would like to see, though, is common definition of the core "attributes/elements" - this seems much more reusable across models & domains. It does make sense, though, to publish some of the "common models" as at least examples of structural models - IPP, UPDF, etc. are likely candidates for this. This exposes some of useful constructs (such as the composite feature you describe below) for reuse. thanks, bt --------------------------------------------------- Bob Taylor Senior Architect IPG Strategic Technology Development Hewlett-Packard Co. mailto:robertt@vcd.hp.com phone: 360.212.2625/T212.2625 fax: 208.730-5111 --------------------------------------------------- -----Original Message----- From: Norbert Schade [mailto:norbertschade@attbi.com] Sent: Monday, July 08, 2002 7:32 AM To: Print Services group Cc: UPD group Subject: PS> Semantic model: media handling I have problems to follow two different ways to specify media handling and UPDF would have problems to support that. I'm fine with the specification of single media attributes like size, type, etc. I agree that there should exist a media instance a level higher, which is a media element with a number of media attributes. The number of attributes can vary. In one sample it may be just size and type, in another it may be something like the IPP media collection. My point is that the attributes a media is described by may vary. There should not be a predefined media collection in a common Semantic Model representing one implementation. Feel free to check the composite feature definition we have in UPDF. Open the UPDF.xsd schema to do this and follow the path down to PrintCapabilities.Features. The current sample description xml of an imaginary LJ9000 has a 'Media' composite feature. We can compose any number of features to a new feature, be it Media, Quality or anything else. This is a very flexible structure and is expected to be used frequently. We got very positive feedback once we finished it last year. We'd appreciate if the Semantic Model does something down that path. Otherwise the spec is ambiguous. Another statement: We've seen the current schema of the Semantic Model. We know there are a number of ways to write schemas. The UPDF group made the experience that working with attributes instead of assigning text to elements directly has advantages. Validation is easier and we can define constraints (these are really constraints and not dependencies) for attributes. You may think that over. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Data Types.xsd Type: application/octet-stream Size: 70451 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020717/fe5649f7/UPDFDataTypes-0001.obj From norbertschade at attbi.com Tue Jul 23 21:07:28 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> UPDF web site update Message-ID: <000a01c232ae$7b4960e0$a8948018@ne1.client2.attbi.com> I have updated the UPDF web site. Check out ftp://ftp.pwg.org/pub/pwg/upd/Current_Version and the schema and samples subfolders. These files have every change and extension we talked about before, in and since Portland. I'll send out more detailed reports the next two days. Regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020723/daf77815/attachment-0001.html From norbertschade at attbi.com Tue Jul 23 21:20:51 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> classifying identifiers with two-dimensional parameters Message-ID: <002301c232b0$59f422c0$a8948018@ne1.client2.attbi.com> We redesigned the classifying identifiers with two-dimensional parameters. 1. Virtual units Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'virtualUnits' + '_' + positiveInteger + 'x' + positiveInteger. 2. Device Resolution Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'deviceResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. 2. Raster Resolution within the raster objects A raster object is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'rasterResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. 2. Positioning Is now an element with Predefined_ID/Proprietary_ID attributes. Predefined_ID has its own data type for demonstration purpose and popular values. The syntax is 'deviceResolution' + '_' + positiveInteger + 'x' + positiveInteger. We have changed the values to dpi. We have combined the two attributes for the maximum values to one attribute 'MaximumValue'. The syntax is positiveInteger + 'x' + positiveInteger. The values represent the maximum values for the command sequence. This can be, but is not necessarily identical to dpi values. There are PDL out there, where these values are not arbitrary, but have a rather small limit. that means the driver perhaps has to repeatedly send relative positioning command sequences. This attribute helps identifying that special condition (e.g. think of some Canon bubble jets). With this feature we have some small discussion going on with devices in mind, which cannot position with x and y dimension in one command sequence. These are typically banding devices. We will keep you informed. Attributes 'Reference' and 'Direction' are now mandatory. The driver must rely on finding that information. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020723/57a9901b/attachment-0001.html From norbertschade at attbi.com Sun Jul 28 21:26:25 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> compression modes Message-ID: <000a01c2369e$f4d61a40$a8948018@ne1.client2.attbi.com> We have defined a data type for compressions used within the raster graphic definition. Please check and comment. I guess it may need some more work on the details once we finish different device descriptions. The files are on our web site already. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020728/3dc22038/attachment-0001.html From NorbertSchade at oaktech.com Mon Aug 5 10:27:31 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> specification documentation Message-ID: We are heavily working on the documentation these weeks. Find a new version of the spec on the UPDF web site, access from the UPDF page (detailed file name: UPDF_Functional_Specification.pdf). There is still more to do, we know. but we have been able to add info a number of sections including connectors, composite features and dependencies. Have a look. Norbert From hlava at us.ibm.com Mon Aug 12 16:09:02 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Wed May 6 14:05:17 2009 Subject: UPD> Comments on UPDF specification Message-ID: The following are some comments about the UPDF specification (Universal Printer Description Format, Version 0.83.1) document. I am new to UPDF, but perhaps this is a positive thing in that it will provide the perspective of someone coming to UPDF "cold" and only having what's written down in the spec to go by. * There is no table of contents and no index, making it impossible to use this as a reference document. * Heading levels are not numbered like they were in 0.81.3, making an already difficult-to-follow nesting structure (see the following point) now impossible-to-follow. There are not even page numbers in the current version! * It is very difficult to discern the nesting of the XML elements. You have to either flip back and find the list of sub-elements in the containing element (in 0.81.3 you could count the numbering level in the numeric header, which gets very difficult as the nest level deepens). I would suggest using heading numbers and indenting as well to make the nesting visually obvious. * Many elements merely list the attributes without any explanation. While the purpose of some can be deduced from the names, this is very imprecise in a standards document and opens it up for misunderstandings and incompatibilities between vendors. * "XML-DTD encoding of UPDF" section references a DTD file but the UPDF is actually defined via XML schema (XSD) files. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020812/b77907f4/attachment-0001.html From NorbertSchade at oaktech.com Mon Aug 12 17:17:37 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> Comments on UPDF specification Message-ID: I answered Alan a minute ago with the email below and sent him my current version of the spec, which is slowly showing some sign of professional layout. I detached the doc file from this email, as I'm still working on it and it's not yet in PDF format. But it's good to notice that more people are getting to the heart of UPDF. Makes those who devote parts of their life to it feel better. Expect the next public version of the format this week. Norbert ----- Forwarded by Norbert Schade/oaktech/us on 08/12/2002 05:11 PM ----- Norbert Schade To: "Alan Hlava" 08/12/2002 cc: 05:09 PM Subject: Re: UPD> Comments on UPDF specification(Document link: Norbert Schade) Hi Alan, welcome to the group. There will be the day and time when I take a bit more time to talk to you, but for nowE just a short answer you may be very interested in. Thanks for your feedback. As you can imagine, we know about the lacks. But it simply needs time to do all this stuff. Fortunately (as a matter of fact to a perfect time for you) I attach my latest version of the specification documentation. I leave it to you to play with it. You may enjoy it. this is the result of the evenings of last week. It's not yet converted to PDF, as I'm still working a bit on some sections. I assume you have a WinWord somewhere in access. After that it has to rest again, as we have to get back to the technical side again. Your last two items are known, but unchanged for now. It will be fun to have somebody new to the group with serious interest. we'll talk again. Norbert "Alan Hlava" cc: Sent by: Subject: UPD> Comments on UPDF specification owner-upd@pwg .org 08/12/2002 04:09 PM The following are some comments about the UPDF specification (Universal Printer Description Format, Version 0.83.1) document. I am new to UPDF, but perhaps this is a positive thing in that it will provide the perspective of someone coming to UPDF "cold" and only having what's written down in the spec to go by. * There is no table of contents and no index, making it impossible to use this as a reference document. * Heading levels are not numbered like they were in 0.81.3, making an already difficult-to-follow nesting structure (see the following point) now impossible-to-follow. There are not even page numbers in the current version! * It is very difficult to discern the nesting of the XML elements. You have to either flip back and find the list of sub-elements in the containing element (in 0.81.3 you could count the numbering level in the numeric header, which gets very difficult as the nest level deepens). I would suggest using heading numbers and indenting as well to make the nesting visually obvious. * Many elements merely list the attributes without any explanation. While the purpose of some can be deduced from the names, this is very imprecise in a standards document and opens it up for misunderstandings and incompatibilities between vendors. * "XML-DTD encoding of UPDF" section references a DTD file but the UPDF is actually defined via XML schema (XSD) files. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com From NorbertSchade at oaktech.com Tue Aug 20 14:57:41 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: You can find a new version of the UPDF specification on our web site. Just use the reference in the UPDF site. Although the exact version number is 0.84.0, we'll nickname it 'Version 84' for short reference, as we expect to refer to this level regularly. We consider Version 84 as a major milestone of the document, as we have accomplished some targets. 1. All information merged into one document. Before we had documents, which referred to one special schema. We had documents at different places. Not all documents could be accessed from the UPDF web site. Now we have one document for the specification. The link known by all people involved in UPDF refers to that document. It's in PDF format. >From now on this will be the only document, where you'll find official information about the specification. One place to search. One file to edit. 2. The spec shows all tags of all schemas. Version 84 reflects all UPDF schemas. There is one section per schema (except the data type schema, which is really for the experts). All elements and attributes of all schemas are listed. We know that not all tags are documented as well as we'd like to. But now that's simpler to fill in. 3. The spec shows a professional layout. Although we were hoping for some time that we'd get some help from people who do that for living, we finally had to move on. I hope we proved that some dry engineers can get something together, which really looks like a specification. Important details include a table of contents and headings in nine levels for all elements. Attributes are formatted in blue for easier detection, as they are the main target to look out for when seeking information. Headings are numbered for perfect reference. >From now on it is possible that more than one work on the spec, as we have detailed references to avoid overlapping and double-work. General We know it's not final. But this version can be easily extended and is an excellent base for discussion. Once all tags are filled as required we will be able to start a series of last calls. We expect that to start after the New Orleans conference. If you have thought about reading through the spec, but always were confused by the differences to the schemas, now is the time to jump in. One reason for finish the spec on this level was to provide some document for discussions with the Semantic Model group in PWG in the Linux guys from the freestandards.org. It will now be easier to demonstrate how things are suppose to work with this kind of architecture. Now the effort for the spec has to come down a bit again to make room for the technical work. Meet you there! Regards Norbert Schade From jsommer at bellatlantic.net Thu Aug 22 08:01:04 2002 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:17 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: <5.1.1.6.2.20020822080051.00b5b188@incoming.verizon.net> Norbert, The new version of the spec looks great. It's much easier to identify elements and attributes and overall much more readable. A major step forward. Jim At 8/20/2002 02:57 PM, NorbertSchade@oaktech.com wrote: >You can find a new version of the UPDF specification on our web site. Just >use the reference in the UPDF site. Although the exact version number is >0.84.0, we'll nickname it 'Version 84' for short reference, as we expect to >refer to this level regularly. > >We consider Version 84 as a major milestone of the document, as we have >accomplished some targets. > >1. All information merged into one document. >Before we had documents, which referred to one special schema. We had >documents at different places. Not all documents could be accessed from the >UPDF web site. >Now we have one document for the specification. The link known by all >people involved in UPDF refers to that document. It's in PDF format. > From now on this will be the only document, where you'll find official >information about the specification. >One place to search. One file to edit. > >2. The spec shows all tags of all schemas. >Version 84 reflects all UPDF schemas. There is one section per schema >(except the data type schema, which is really for the experts). All >elements and attributes of all schemas are listed. >We know that not all tags are documented as well as we'd like to. But now >that's simpler to fill in. > >3. The spec shows a professional layout. >Although we were hoping for some time that we'd get some help from people >who do that for living, we finally had to move on. I hope we proved that >some dry engineers can get something together, which really looks like a >specification. >Important details include a table of contents and headings in nine levels >for all elements. Attributes are formatted in blue for easier detection, as >they are the main target to look out for when seeking information. Headings >are numbered for perfect reference. > From now on it is possible that more than one work on the spec, as we have >detailed references to avoid overlapping and double-work. > > >General >We know it's not final. >But this version can be easily extended and is an excellent base for >discussion. >Once all tags are filled as required we will be able to start a series of >last calls. We expect that to start after the New Orleans conference. > >If you have thought about reading through the spec, but always were >confused by the differences to the schemas, now is the time to jump in. > >One reason for finish the spec on this level was to provide some document >for discussions with the Semantic Model group in PWG in the Linux guys from >the freestandards.org. It will now be easier to demonstrate how things are >suppose to work with this kind of architecture. > >Now the effort for the spec has to come down a bit again to make room for >the technical work. Meet you there! > >Regards >Norbert Schade From hlava at us.ibm.com Thu Aug 22 08:12:28 2002 From: hlava at us.ibm.com (Alan Hlava) Date: Wed May 6 14:05:17 2009 Subject: UPD> new UPDF specification document: Version 84 Message-ID: The new headings look great, but the document still seems to be missing page numbers. This makes the table of contents very much less useful. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020822/0cc42cfa/attachment-0001.html From norbertschade at attbi.com Thu Aug 22 08:31:05 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> new UPDF specification document: Version 84 References: Message-ID: <000d01c249d7$c92a8b00$a8948018@ne1.client2.attbi.com> Page numbers should only be a minor change. I'll add footers the next time. Good to see that people acknowledge the effort. Looks, as if the feedback is positive. So we'll stay with the overall layout. Regards Norbert Schade ----- Original Message ----- From: Alan Hlava To: upd@pwg.org Sent: Thursday, August 22, 2002 8:12 AM Subject: Re: UPD> new UPDF specification document: Version 84 The new headings look great, but the document still seems to be missing page numbers. This makes the table of contents very much less useful. Regards, Alan Hlava IBM Printing Systems Division hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020822/3b7b768d/attachment-0001.html From norbertschade at attbi.com Mon Sep 16 09:45:05 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> update UPDF site Message-ID: <002401c25d87$4385b740$a8948018@ne1.client2.attbi.com> I have updated the schema and XML files on the UPDF site. Nothing major, just some little repairs of some oversights. Currently under review or discussion: - specification documentation - review general section about dtd and schemas - review command sequences - messages in dependencies - especially with regards to composite features - a UPDF namespace and a transparent relationship to the Semantic Model - wildcards - some entry to indicate that all data files based on UPDF are not considered IP. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020916/44e3c383/attachment-0001.html From NorbertSchade at oaktech.com Mon Sep 16 14:20:22 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> min/max custom sizes Message-ID: Now that we have a complete architecture and play around with samples, we see some chances. One of them is the smart handling of custom media sizes, which is a pain in the neck in many drivers. Right now our main schema has some custom media size related attributes in media source. Basically fine, nothing wrong with that. We can say that a specific tray can only feed sizes between this and that. We had some feedback that printers may have similar limitations for duplex and somebody else said it could basically happen anywhere (printer xxx can't staple larger than etc.). Valid input! Calls for a better solution. Proposal to start discussion: We remove the custom media size related attributes from media source and create one general custom media size element (attributes: HorizontalMinimum, HorizontalMaximum, VerticalMinimum, VerticalMaximum) under the media size feature (not the record of the feature). Somebody may enter some default values there. The main point would be that everybody can now define dependencies with these attributes. Sample: If duplex, override the minimum values. No schema change required. You can now define a dependency for every feature, if you like. Comments??? Norbert From NorbertSchade at oaktech.com Mon Sep 16 14:36:34 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> dependencies for composite features Message-ID: There is another discussion going on: How shall a driver behave when it comes to dependencies for composite features. Two weeks ago I was coming from a position that a composite feature is a feature as any other. So it may as well have its own dependencies. The 'old' ones referring to basic features used as components are to be ignored. I'm not that sure any more. Basically most of the old ones would have to be redefined while just replacing the condition. May be even the same warning messages are used. If not, a new localization effort is necessary. In the meantime I'm leaning towards 'use what you have'. It's there. If it can be used, no extra effort is necessary. Once creating messages be a bit careful with the wording as they may pop up with composite features later. So there will not be any new localization. To be clear: If the composite feature needs something special, go ahead and create a new dependency. Sample: If !simplex, don't use media type transparency. Assume we have that dependency for the two basic features and we have a composite feature 'Media' with media size and type as components. If long-edge is selected and the user tries to select a ComponentSet, which involves transparency, the original dependency should pop up. I understand that people can have different opinions on this, but we'd like to recommend an expected behavior for UPDF drivers in the spec. So let's hear some opinions and see, if we can agree. Norbert From norbertschade at attbi.com Wed Sep 18 20:11:20 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> Copyright for UPDF device description Message-ID: <000d01c25f71$153c1f00$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.xsd Type: application/octet-stream Size: 73823 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020918/0319620e/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 97881 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020918/0319620e/UPDFDeviceDescription-HPLaserJet9000PCL5e-0001.xml From hamzy at us.ibm.com Fri Sep 20 11:35:02 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:17 2009 Subject: UPD> Copyright for UPDF device description Message-ID: I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From hamzy at us.ibm.com Fri Sep 20 11:53:55 2002 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:17 2009 Subject: UPD> Copyright for UPDF device description Message-ID: Sigh. Let's try this again and hope of the cr/lfs are correct this time. I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From NorbertSchade at oaktech.com Fri Sep 20 12:09:08 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> MIT attributes Message-ID: Just to explain where I came from. Yes, I use an XML editor and thought we want the license to pop up there in a way that you can easily read it in the app on one screen. If we assume the files will rather be opened in a straight text editor, I understand Mark's comment. Of course, we could fill it all into one attribute (I'd have to check for max length). I haven't seen a way to wrap lines in my app, so it would show up a one long line, where you have to scroll. All MIT attributes are of type fixed, which to my knowledge is the only way I can protect the wording. My interpretation of fixed is mandatory, but I noticed that my Turbo XML does not care so much. If I just declare it as 'required', anybody could change the text, which we don't either, do we? Norbert From Rob.McDougall at adobe.com Mon Sep 23 16:06:30 2002 From: Rob.McDougall at adobe.com (Rob McDougall) Date: Wed May 6 14:05:17 2009 Subject: UPD> Copyright for UPDF device description Message-ID: <311000B0752ED211B61700805F0D6B09036CB052@ottmail3.jetform.com> Just FYI, the xml declaration must occur before any XML comments, so you'll have to move the comments after that line. Regards Rob -----Original Message----- From: Mark Hamzy [mailto:hamzy@us.ibm.com] Sent: September 20, 2002 11:54 AM To: UPD group Subject: Re: UPD> Copyright for UPDF device description Sigh. Let's try this again and hope of the cr/lfs are correct this time. I am going to have to throw a tomato here. I think that the syntax is really awkward here and it seems that it was done this way to avoid a problem in the xml editor. What problem are you trying to solve here? Copyright is required but the MIT attributes are not. So, I can design a updf file that contains a different copyright in the comments without the MIT copyright in the Copyright tag: ... Your xsd cannot stop copyright in xml comments and cannot enforce the MIT copyright. Also, I think that this: is more readable than this this long line: At best you can make the MIT attributes required but it still does not stop copyright statements in the comments. Tomatoes, ... err comments, anyone? Mark Take a look at the Linux Omni Printer Driver Framework at http://www.ibm.com/linux/ltc/projects/omni/ From NorbertSchade at oaktech.com Wed Sep 25 13:42:52 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> demonstration of composite features and dependencies in New Orleans Message-ID: Although we do not have a detailed agenda yet, it is sure that we will use the opportunity to explain and demonstrate composite features and dependencies at the UPDF meeting in New Orleans on Friday, Nov. 8th. We'll use an implementation provided by Granite Systems. This is not just a set of UPDF xml schemas or files, but a full size printer driver under MS Windows. We will prepare various sample device descriptions to show different concepts and ideas all supported by the same implementation. Depending on feedback we might do it the first two hours (8.30am - 10.30am) of the day. Feel free to send in some questions concerning this functionality. so we can work them into the demo. Regards Norbert Schade From norbertschade at attbi.com Wed Sep 25 21:13:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> new copyright proposal Message-ID: <003101c264f9$ee8dcd20$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.xsd Type: application/octet-stream Size: 72845 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020925/ec976af4/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 97909 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20020925/ec976af4/UPDFDeviceDescription-HPLaserJet9000PCL5e-0001.xml From sommer at granitesystems.com Wed Sep 25 22:06:02 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:17 2009 Subject: UPD> Sample UPDF Driver Message-ID: <5.1.1.6.2.20020925213606.020a3968@incoming.verizon.net> I have uploaded a sample Windows 2000/XP UPDF printer driver to the PWG web site. There are two files: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/GraniteSystems/Driver/GraniteSampleDriver.zip ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/GraniteSystems/XML%20Samples/GraniteSampleUPDF.zip GraniteSampleDriver.zip contains the driver files. GraniteSampleUPDF.zip contains the UPDF schemas and XML for my sample. This is based on Norbert's sample. If you wish to install this do the following: 1) Unzip the two files. You can unzip them to the same or different directories. 2) In the directory that you unzipped the driver there is a file named GSPLUPDF.INI. Edit this file and change the Directory= entry to the directory that you unzipped the UPDF sample into. This should be a complete path and it should not be a network drive. 3) Run "Add Printer" and point it to the directory that contains the driver. The driver should now be installed. There are three composite features defined - one with media size as the dominant feature and two without dominant features. The media composite feature appears in the Features list in place of media size. The other two composites appear on the Presets tab. All three composites are user extensible so you may define new records for them using the Composites tab. The new records will appear in the appropriate lists. If you open Word and go to Page Setup you will see the media composite feature listed instead of the standard sizes. There are a bunch of dependencies defined - at least one of each type (filter, message, selection). You can look at the XML to see all of them (some are in the device description and some are in the user policy and they are a bit confused right now) but examples are: Filter - Duplex != Simplex AND Media Type = Lables Message - Bin = Top AND Stapling != None then display message. If OK (which has been renamed "No Stapling" is selected then set stapling to none, gray it out, and put an information icon on it. There are still plenty of bugs but I think this demonstrates composite features and dependencies pretty well. I will continue to work on this but what will be demonstrated at the New Orleans UPDF meeting will be based on this implementation. Please feel free to contact me with questions and comments. Jim mailto:sommer@granitesystems.com 978-486-3068 From sommer at granitesystems.com Thu Sep 26 08:55:21 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:17 2009 Subject: UPD> Dependencies Message-ID: <5.1.1.6.2.20020926072649.00bde960@incoming.verizon.net> I have been working quite a bit with implementing dependencies and have some comments for the group. Introduction To Dependencies: UPDF defines three types of dependencies - filter, message, select. All dependencies consist of one or more conditions. The conditions are AND'd together. Each condition can be either and EQUAL or a NOT EQUAL. Conditions are defined using unique IDs. Therefore, a condition appears as - MediaDuplex_Record.ID NOT EQUAL Simplex AND MediaType_Record.ID EQUAL Type_Transparency. Filter - A filter dependency defines a group of settings (it may be a group of one) that should never be displayed. If N conditions are defined for the filter and N-1 of the conditions are true then all settings that would make the remaining condition true are to be hidden. Using the conditions above, if media type is set to transparency then all settings with duplex not equal to simplex are hidden. Also, if duplex is not set to simplex then all settings with media type equal to transparency are hidden. Filters are not a very user friendly dependency but they do have their uses. Message - A message dependency defines a message that should be displayed when a group of settings (it may be a group of one) is selected. The message must have an OK and/or a Cancel button. If the user clicks the Cancel button then the last action performed by the user is undone. If the user clicks the OK button then a group of settings selections (it may be a group of zero) is automatically made. In addition, any of the features in selections may be grayed out and an information icon may be added to the feature to explain why it is grayed out. Using the conditions above, when duplex is not simplex and media type is transparency the message "You cannot duplex transparencies. Click OK to turn off duplexing. Click Cancel to undo your last change." is displayed. If OK is clicked then duplex is set to simplex, grayed out, and an information icon is added to the duplex feature. When the information icon is clicked, the message "You cannot duplex transparencies." is displayed. All this is defined within the message dependency. Select - The select dependency is really a degenerate form of the message dependency. The select dependency has no message and assumes the OK button is clicked. So, what you have is a group of settings selection (it may be a group of one, zero doesn't make sense) that is automatically made when a group of settings (it may be a group of one) is selected. In addition, any of the features in automatic selections may be grayed out and an information icon may be added to the feature to explain why it is grayed out. Using the conditions above, when duplex is not simplex and media type is transparency then duplex is set to simplex, grayed out, and an information icon is added to the duplex feature. When the information icon is clicked, the message "You cannot duplex transparencies." is displayed. All this is defined within the select dependency. Implementation: This is how I implemented dependencies to provide the results that one would expect from the UPDF definition. When the user interface is brought up, dependencies are run against the saved settings. This should not produce any messages or cause any selections to be made since the saved settings should be valid. Filters may cause settings to be hidden from some features. Each time the user changes a setting by either changing a standard feature (ie destination changed from top bin to left bin) or changing a composite feature setting (ie media changed from "plain letter in tray 1" to "plain legal in tray 2") dependencies are checked. The following steps are then taken - 1) Save the settings before applying the current change. If the current change is a composite feature then set all the component features to their appropriate settings. 2) Make all settings visible (undo any filters), ungray all features, and clear all information icons. 3) Start dependency checking with those dependencies defined in the user policy file. The user policy dependencies may duplicate some of the device description dependencies but are assumed to be more appropriate. For example, the device description may define a select dependency whereas the user policy defines the same condition as a message. 4) Check the conditions of each dependency and act on each as appropriate (filter, message, or select). 5) If a select dependency is true or the user clicks OK on a message dependency then set the automatic selections and restart dependency checking (goto step 2) with the new settings. 6) If the user clicks Cancel on a message dependency then stop checking dependencies and restore the saved settings (from step 1). I made this mistake in another email so I want to note that if a dependency grays out and/or adds an information icon to a feature then you do not have to write another dependency to ungray the feature and/or remove the information icon. I do this in step 2 above. I think we should make this part of the definition of UPDF dependencies - When a dependency is no longer true, features will be displayed normally and information icons will be removed. Dependencies and Composite Features: Dependencies can be defined using standard features or composite features. A condition can be MediaDuplex_Record.ID != Simplex AND MediaType_Record.ID = Type_Transparency or it can be MediaDuplex_Record.ID != Simplex AND Media.CompositeFeature_Record.ID = CF_Media_Transparency. Using the standard feature, all settings which cause media type to be transparency will cause the condition to be true whereas using the composite feature will only cause condition to be true for a specific composite feature setting. One other use of dependencies is for user extensible composite features. A composite feature record should not be defined that causes any dependency based on the components of the composite to be true. For example, if a media composite feature has the components media size, type, and source and there is a dependency that says #10 envelopes can only come from the envelope feeder then the user should not be able to create a composite feature record with a media size of #10 envelope and source not equal to the envelope feeder. I have not implemented this portion of dependencies yet but my plan is that during the definition of a composite feature record I will apply only those dependencies that have all condition features as components of the composite. If you've read this far, I hope I've helped you understand dependencies a little better. Please feel free to respond with questions and comments. Jim mailto:sommer@granitesystems.com 978-486-3068 From NorbertSchade at oaktech.com Thu Sep 26 10:20:56 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> glossary Message-ID: We see some conversation going on on different reflectors accompanied by the announcement of various implementations. It may help you simpify things in your mind with a little glossary how terms are used in the UPDF world. Composite Features: A set of basic features, in this case called components, forming a group. You may find the abbreviation 'c.f.' used from time to time. In theory c.f. can themselves be grouped to a new c.f. on a higher level. Dominant component: A c.f. can (not must) have one. Exactly one component can be picked, e.g. media size as the dominant feature of a c.f. Media. If assigned, it is suppose to replace the corresponding basic feature in the UI and all according API to the system. The same second all other components become hidden in the top level UI as well. All components are supposed to be available in a special area of the UI, where the composite feature can be managed, let's say to create a new record or edit an existing user defined one. Without a dominant component all components stay active in the top level UI. The c.f. feature serves more like a collective default setting for features involved. User extensible: If a c.f. feature is user extensible, the end user will be able to create new records and edit them. Predefined records created by the IHV can never be edited, only viewed to identify the settings used for single components. A nice detail is that a system administrator has the power to switch this attribute in a user policy. So s/he can create new records and then block the extensibility for all subsequent users. Dependencies: The definition of actions, how interference between features should be resolved. Often mixed up with the term of 'constraints'. Constraints typically define a feature by showing up as the set of allowed records. Filters: A dependency action. Hide special records of special features under special conditions. Sample: If record 5 of feature A, don't show record 2 of feature B. Selections: A dependency action. Select special records of special features under special conditions. Sample: If record 5 of feature A, select record 2 of feature B. Messages: A dependency action. In case a special condition with a set of features and their records involved is identified bring up a message box to indicate the condition. Typically offered with an OK and a Cancel button. Cancel brings back the previous settings, OK forces the last setting selected to become active and the driver is supposed to resolve all conflicting settings. Usually the OK case is realized with a Selection action. Sample: If record 5 of feature A, show a message indicating that record 2 of feature B conflicts with record 5 of feature A. Hope makes reading easier. If you'd see my wall at home, you'd find out that I have these little stickers all over my place. Norbert From NorbertSchade at oaktech.com Thu Sep 26 10:49:59 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> UPDF implementation in a Windows based printer driver Message-ID: I am delighted to see the first complex implementation sample available from Granite Systems in form of an MS Windows based printer driver, for now under Windows 2K/XP. It excellently demonstrates the rich architecture of UPDF in a rather technical implementation without wasting to much energy on customizing the user interface. Just playing around with it following Jim's recommendations should bring the concept more to life in your mind. It's always easier to get the idea, if you have something to play with. If somebody wants to change and try own UPDF device descriptions that can be done with this implementation as well. Contact Jim, if you have problems with the procedure. I'm ready to help in any way (email or phone), too, to lead you through the functionality of the demo driver. Regards Norbert From sommer at granitesystems.com Fri Sep 27 09:55:53 2002 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:17 2009 Subject: UPD> Re: Sample UPDF Driver In-Reply-To: Message-ID: <5.1.1.6.2.20020927090958.020c0130@incoming.verizon.net> Alan, Presets are composite features that do not have a dominant feature. In my example, I have two of these - N-Up and Reports. N-Up has two records/settings - American 9-Up and Japanese 9-Up. Reports has one record/setting - Department. Select a preset in the Presets list box. The combo box below will then contain the records/settings for the preset. Choose the setting and select the Apply Preset button. This will set the component features of the preset to their appropriate values. In the case of N-Up, the component features are N-up, N-up order, and N-up borders. Since these composites do not have a dominant feature, all the component features are still separately selectable on the Features tab. The Composites tab is used to manage all composite features. Using this tab you can view the component settings for each record/setting of the composite feature. If a composite feature is user extensible, you can add user defined records to the composite or modify and delete previously defined user records. You cannot modify or delete composite feature records that are defined in the device description or user policy XML. The two blank buttons are a bug, I'll fix that. From within an application, only the View button should be visible. From Document Defaults (2000) or Printing Preferences (XP) from the Printers window, you will see New, Edit, and Delete buttons. The Features tab is where you can view and set individual features. When you apply a preset on the Presets tab, the component settings are reflected on the Features tab. To change a feature, select the feature in the Features list box. The combo box below will then contain the records/settings for the selected feature. Norbert's Media is a composite feature with media size as its dominant feature. In the device description this composite is named Media but the user policy file renames it to Norbert's Media. Since this composite has a dominant feature, the composite is displayed in place of the dominant feature (instead of on the Presets tab) and all components are hidden (they are no longer separately selectable). The Norbert's Media composite feature is user extensible so you can define new records using the Composites tab. These new records will then be displayed for the composite on the Features tab. I hope this explanation along with sample help you to understand the composite feature concept and the difference between the two types (with and without a dominant feature). Let me know if you have any other questions. Jim PS I copied the mailing list on this response in case anyone else has the same or similar questions. At 9/27/2002 09:08 AM, you wrote: >I installed and have started to play with this sample. It definitely >helps to illustrate some of the UPDF capabilities concepts! > >Some questions/comments: > * What are "presets"? (It's not obvious from the print dialog what > this tab is meant to contain) > * On the Composites tab, there are two unlabeled buttons, above and > below the View button. Is this intentional or am I missing something? > * It's not clear how I select a composite. On the Composites tab N-UP > and American 9 Up are displayed, but when I click on the features tab it > shows Norbert's Media and Stationery Letter from Tray 1 as the first > feature. Which one is my current selection and how do I change it? > > * Regards, > > * Alan Hlava > * IBM Printing Systems Division > * hlava@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20020927/8fcdb9c3/attachment-0001.html From NorbertSchade at oaktech.com Thu Oct 3 15:27:49 2002 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> preliminary New Orleans agenda Message-ID: We have some ideas what we have to work on, nothing formal yet: Preliminary agenda Friday, Nov. 8th, 8.30am to 3pm 8.30 to 10.30: Driver demo We'll show Granite's implementation of a Windows driver using a full UPDF device description. Highlights will be dependencies, composite features and user policies. This will be the perfect chance to ask questions. The nice thing is that we can change the data on-the-fly and show it right away without any driver compilation. 10.15 MIT license 10.30 Manual duplex other items - prepare last calls on spec - check closer alignment with SM - requirements for release 2 (user interface, use other standard for bidi) I'll be in Europe for the next days, back on Tuesday Oct. 15th. Jim will cover me. regards Norbert Schade From norbertschade at attbi.com Sun Nov 17 17:25:40 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> meeting minutes of New Orleans Message-ID: <002c01c28e88$43f325a0$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021117/18596166/Latest_Meeting_Minutes-0001.htm From norbertschade at attbi.com Mon Nov 18 22:31:26 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> meeting minutes Message-ID: <000a01c28f7c$25114280$a8948018@ne1.client2.attbi.com> I copied the meeting minutes of New Orleans to the UPDF web site, now with a complete and correct list of attendees. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021118/5276781b/attachment-0001.html From norbertschade at attbi.com Tue Nov 19 20:43:15 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> just another one Message-ID: <000e01c29036$320f6a60$a8948018@ne1.client2.attbi.com> I added Mark Hamzy to the list, too. sometimes the crowd is bigger than you think. Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021119/d3b95ee2/attachment-0001.html From norbertschade at attbi.com Tue Nov 19 21:15:32 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> latest schemas and XML Message-ID: <002001c2903a$b4570560$a8948018@ne1.client2.attbi.com> I just copied the latest schemas and XML files to the UPDF web site. Typical pathes: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML%20Schemas/ ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML%20Samples%20based%20on%20schemas/ or access them directly from our web site. All we discussed the last weeks is implemented except a solution for the manual duplex. I'll send some notes on some details the next days and will refer to this set of files. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021119/ce6e449e/attachment-0001.html From norbertschade at attbi.com Wed Nov 20 08:20:00 2002 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> command sequences in font handling Message-ID: <005101c29097$877d6a40$a8948018@ne1.client2.attbi.com> We are providing the following font related entries in the event_enum: 1. FontObjects when entering or leaving the world of fonts in the printer 2. DeviceFonts when entering or leaving the world of resident (not download) fonts in the printer 3. DeviceFont the command sequence at start or end of a resident font in the printer 4. DeviceFontCharacter 1. and 2. are general events and easy to handle. 3. and 4. require more attention. A driver would check all DeviceFont related events (four in the sample below) when any of the font attributes on the host platform have changed (e.g. from Arial to TNR, from upright to italic or else). A driver would check all DeviceFontCharacter related events (two in the sample below) to find out if the Parameter_ID of Character.Parameter (please help me check, if attribute Character_PrintOut is only a duplicate of this parameter and therefore redundant and can be removed. I haven't been to that detail for quite a while) or of Character.SymbolSet.Parameter has changed. We assume a device description developer would create an event per Parameter element. A sample data flow could look like - command sequence reference EnterFontObjects at start of event FontObjects. no parameter references used. - c.s.r. EnterResidentFont at start of event DeviceFonts. no parameter references used. - c.s.r. StartDeviceFont at start of event DeviceFont. DeviceFont.Parameter.Parameter_ID used. - c.s.r. DeviceFontStyle at start of even DeviceFont. ModifyingAttributes.Style.Parameter.Parameter_ID used. - c.s.r. DeviceFontWeight at start of even DeviceFont. ModifyingAttributes.Weight.Parameter.Parameter_ID used. - c.s.r. DeviceFontColor at start of even DeviceFont. ModifyingAttributes.Color.Parameter.Parameter_ID used. Other modifying attributes possible but not used in this sample. - c.s.r. DeviceFontCharacterSymbolSet at start of event DeviceFontCharacter. Character.SymbolSet.Parameter.Parameter_ID used. - c.s.r. DeviceFontCharacterTransparent at start of event DeviceFontCharacter. Character.Parameter.Parameter_ID used. This is to print transparent characters. The command sequence is supposed to tell the printer 'interpret the next byte as a character instead of an escape'. - c.s.r. LeaveFontObjects at end of event FontObjects. no parameter references used. To make this work I think we need one common agreement: If a specific Parameter_ID attribute is empty or the Parameter element is not assigned, the corresponding command sequence is not sent at all if and only if the command sequence refers to that Parameter_ID attribute. That is the first time we specify command sequence handling to that detail for font handling. I forgot something? Any questions or feedback? regards Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20021120/4b4043d1/attachment-0001.html