From hastings at cp10.es.xerox.com Wed Jan 17 12:57:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:50 2009 Subject: UPD> PWG media size name mini-project Message-ID: <918C79AB552BD211A2BD00805F15CE85045E1003@x-crt-es-ms1.cp10.es.xerox.com> To: Ron and others interested in the PWG mini-project to compile an open list of standard media size names for use in IPP "media" attribute, UPnP, Bluetooth, Printer MIB, IPP FAX, Internet FAX, etc. At the December UPnP Imaging WG meeting, the they requested that the PWG compile a list of standard media size names, rather than inventing its own set for UPnP. Other protocols have the same requirements and slightly different sets of lists. Having a single set of media size names will help a lot. There may need to be alias names for a few sizes where there are different names for the same media size. At the December PWG meeting, Ron Bergman volunteered to start making a list. Mike Shepherd from Xerox is willing to work with Ron on this. Please take a look at the compilation that Jim Lo from Sun compiled (see attached email fragment) and sent to the IPP and UPD DLs in November. He researched the IPP, GPD, and PPD (and others) for media size names and compiled a list that he sorted by size name, by size, and by source. I've converted his .html to LANDSCAPE .doc and .pdf so that it prints without truncation. I've copied it to a new sub-directory: new_MEDIA (which we can use for the media object in the future as well). I've also copied two RFCs that have media sizes for Internet FAX (see email attached from Lloyd McIntyre). ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.htm ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/rfc2534.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/rfc2879.txt Thanks, Tom -----Original Message----- From: Jim Lo [mailto:Jim.Lo@eng.sun.com] Sent: Tuesday, November 14, 2000 12:37 To: upd@pwg.org; ipp@pwg.org Subject: IPP> Re: UPD> registered parameters Hi, Just in case it may be of any help, attached please find the collection of all predefined paper sizes from many standards (number of entries -- all:175 / IPP:73 / GPD:117 / PPD:151) Best regards ................... Table of Content ---------------- A. PaperSizes (all/GPD/PPD/IPP/TIPSI/ISO/JIS) Sorted By Name/Size B. Feature/Option Display Names For en_US Locale Outline ------- A. PaperSizes (all/GPD/PPD/IPP/TIPSI/ISO/JIS) Sorted By Name/Size 1. All PaperSizes (Sorted By Name) 2. All PaperSizes (Sorted By Size) 3. IPP PaperSizes (Sorted By Size) 4. PPD PaperSizes (Sorted By Size) 5. GPD PaperSizes (Sorted By Size) //The table contains the option keywords currently registered for all (version 1.0) PaperSize feature, //which designates a given physical paper size on a printing device. Most of those predefined options //are from the following standards: // // IPP: Internet Printing Protocol (PWG) // // ISO: International Standard Organization // // JIS: Japanese Industry Standard // // TIPSI: Transport Independent Print System Interface (Lexmark) // // PPD: PostScript Printer Description format (Adobe) // // GPD: Generic Printer Description format (Microsoft) -----Original Message----- From: McIntyre, Lloyd Sent: Tuesday, November 21, 2000 17:41 To: Hastings, Tom N; McIntyre, Lloyd; Hastings, Tom N Cc: McDonald, Ira; Herriot, Robert; Buckley, Robert R Subject: RE: IANA registry of media size names [where's the beef?] Tom, The beef [media size names for Internet FAX] is in the two RFC references, RFC 2534 (Section 2: Media Feature Registrations) and 2879 (Appendix A: Feature registrations). This list no where as exhaustive as that you have provided. It is, however, open for expansion. Lloyd From emed11 at libero.it Thu Jan 18 10:22:58 2001 From: emed11 at libero.it (emed11@libero.it) Date: Wed May 6 14:04:50 2009 Subject: UPD> Obtain Biotech IPOs! 206 Message-ID: <770.778301.377776@libero.it> An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010118/c30f3e06/attachment.html From xi11101 at address.com Mon Jan 22 01:25:19 2001 From: xi11101 at address.com (XVA International) Date: Wed May 6 14:04:50 2009 Subject: UPD> Message-ID: <20010122062519.3864.qmail@uwdvg021.cms.usa.net> WOULD YOU STUFF ENVELOPES FOR $1,000'S WEEKLY? $2 For Each Envelope You Stuff SIMPLE, PLEASANT WORK YOU CAN DO AT HOME!!! HELP SOLVE YOUR MONEY PROBLEMS. No more worries over inflation, recession, bills, rising gasoline and other costs. If you are looking for easy extra income, to relieve financial pressures, you owe it to yourself to investigate our offer. HERE IS YOUR CHANCE to earn extra money working at home by becoming an active participant of our successful mailing association. You receive cash daily for the envelopes you stuff. There is no limit. You stuff as many as you wish. NO EXPERIENCE OR SPECIAL SKILLS REQUIRED. Our HOMEMAILER'S PROGRAM is designed especially for people with little or no business experience and provides step-by step instructions. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ WHY IS THIS POSSIBLE? There are many mail-order companies who want to expand their business, but do not want to hire more people. If they hired more employees, they would have to supervise them, rent more office space, pay more taxes and insurance, all involving more paperwork. It is much easier for them to set it up so that independent homeworkers can earn money doing the work themselves. This program is designed to help people cash in with a company who needs homeworkers. Each member is an independent homeworker. You serve a company that pays good commissions to have their circulars mailed. This program has been perfected so that it has become one of the most successful and profitable ones ever. We invite you to take part in our success. The money you earn is up to you. We do not require that you mail a certain number of pieces each week. You can take on whatever amount of business that fits your schedule, and you can quit whenever you want, there are no obligations. This work mainly consists of the securing of envelopes. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ You may work in the comfort of your own home, choose your own hours, and set your own pace. No need to leave your present job. The possibilities are unlimited - get the whole family to join in. Form workshops with your friends. We will further show you how to expand your operation and boost your new income as high as you wish to go. NOW, IT'S ALL UP TO YOU! The opportunity for the better life is here - it's waiting! But only YOU can take that all-important step that separates the achievers from the dreamers! Order NOW! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ALL BUSINESS can be done by MAIL and we give you complete assistance at every step to insure your success. You can START THE SAME DAY you receive the instructions and begin RECEIVING MONEY WITHIN TWO WEEKS and every week from then on, as long as you desire. You will be supplied with the materials to be stuffed. Envelopes will be already stamped and addressed. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ GUARANTEE: We welcome you to this program and extend to you our unconditional guarantee that everything we have said about this program is true and that you will be delighted with the money you make. Our goals and continued success depends on your 100% satisfaction with the HOMEMAILER'S PROGRAM. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ DON'T BE FOOLED There are many fraudulent envelope addressing and chain letter schemes being sold today. We recommend that you avoid them. Why fool with some questionable scheme when our program enables you to earn so much money legally. This is not an offer of employment. It is an opportunity to become an independent commission mailer for our company. Remember, unlike the others, this is not a get-rich-quick scheme. It is a proven program for making money while filling the needs of a company who need people to mail their circulars. IN ORDER TO GET YOU STARTED IMMEDIATELY, we must require a one-time fee of only $13.95. This covers our expense in showing you what to do and guarantees you can work with us as long as desired. You will not be required or asked to pay for any additional information or manuals. Inasmuch as we would like to send you our program with the small charge, we must protect ourselves from those who are not serious and have no intention other than to satisfy their own curiosity. Naturally, no business can afford to send out costly material to everyone who writes in asking for it. This small charge assures us that you are serious about wanting to earn money at home. DON'T DELAY - START IMMEDIATELY!!! This is money. You can begin now by putting your time to the best of use. The next few minutes can literally change your life. Don't let this extraordinary opportunity pass. YOUR REGISTRATION FEE REFUNDED as soon as you submit your first 100 envelopes. Send a check or money order in the amount of $13.95 to: X V A International 11948, 207th Street, Suite 309 Maple Ridge, BC, Canada V2X 1X7 Please include your name, address, phone number, and an email address. Never send cash through the mail. XVA International is a licensed business operating in BC, Canada; license #14126. Please allow 4 to 6 weeks for delivery of your starter kit. This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email with the word "remove" in the subject line. ____________________________________________________________________ Get Free Internet Access and WebEmail at http://www.address.com Click on this link http://www.address.com/giveaways/free.asp for great offers. From norbertschade at oaktech.com Fri Feb 23 14:48:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> UPDF 2001 schedule Message-ID: <004701c09dd1$8e7b60f0$500714ac@NSCHADEW1> One item on the upcoming agenda for Tampa will be discussing the future of the UPDF group, especially concerning the lead and conferences. I propose two other conferences in 2001: the one in Toronto and the one in Texas. Targets for Toronto are to discuss some real device descriptions based on our format, work out the difficulties while creating them and solve remaining issues. I hope that we get three to five samples from printer manufacturers, even if they are incomplete in some sections. Group 1 of candidates include Oak, Lexmark, Canon, Xerox and Hitachi. Among others Sun will be another contact. We should get to a more detailed plan in Tampa. Second target for Toronto would be discussing the chances for driver implementation of the format to be able to test and find weaknesses. Group 1 of candidates include IBM and Granite Systems. I will check inhouse. Target for Texas would be presenting level 1 of the format to the public. This certainly needs a lot more work done on the documentation side. As we all (myself included heavily) are facing serious budget cuts, to accomplish these targets would need some extra work other than f2f meetings. I'd like to have a tele con on Monday of the April PWG instead of a f2f meeting. Some more tele cons would be necessary, probably once a month until Texas. We need some people dedicating themselves to certain jobs. I consider two to three days per month per company (until Texas). Above statements tell about the tasks. As I would like to create a detailed plan and schedule in Tampa, I am soliciting feedback. For those, who attend the Tampa meeting, please give a general impression. Do you think it's doable? Counter proposals? Improvements? For those, who cannot attend Tampa, please provide a detailed statement. Check on what tasks you and your company can work. Provide your feedback during next week, before Tampa, so that we'll have it on the table. A more detailed agenda for Tampa will follow. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010223/8d00393f/attachment.html From hahaha at sexyfun.net Mon Feb 26 00:46:27 2001 From: hahaha at sexyfun.net (Hahaha) Date: Wed May 6 14:04:50 2009 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! Message-ID: Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... -------------- next part -------------- A non-text attachment was scrubbed... Name: sexy virgin.scr Type: application/octet-stream Size: 23040 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010225/bbc2de3c/sexyvirgin.obj From richNOgSPAM at plustechnologies.com Mon Feb 26 10:45:41 2001 From: richNOgSPAM at plustechnologies.com (Rich Gray) Date: Wed May 6 14:04:50 2009 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! **VIRUS ALERT** Message-ID: <3A9A7A25.2AA5F8CA@plustechnologies.com> This e-mail tripped our virus scanner: Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: undisclosed-recipients From: Hahaha Sent: 444700810,29401015 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! Attachment Details:- Attachment Name: sexy virgin.scr File: sexyvirg.scr Infected? Yes Repaired? No Virus Name: W32/Hybris.gen@MM -- Richard B. Gray, Sr. Software Egr. Plus Technologies division of Digital Controls Corp. mailto:richNOgSPAM@plustechnologies.com (remove NO SPAM to reply) http://www.plustechnologies.com From lombardiv at earthlink.net Mon Feb 26 10:46:13 2001 From: lombardiv at earthlink.net (Victor J. Lombardi) Date: Wed May 6 14:04:50 2009 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! **VIRUS ALERT** References: <3A9A7A25.2AA5F8CA@plustechnologies.com> Message-ID: <3A9A7A45.C0853B7C@earthlink.net> This guy should be shot!!! Rich Gray wrote: > This e-mail tripped our virus scanner: > > Action Taken: > An attempt to disinfect the attachment was unsuccessful, > so the attachment was quarantined from the message and replaced with > a text file informing the recipient of the action taken. The infected > attachment > has been placed in the designated quarantine folder. > Please exercise extreme caution when handling the quarantined attachment > > To: > undisclosed-recipients > > From: > Hahaha > > Sent: > 444700810,29401015 > > Subject: > UPD> Snowhite and the Seven Dwarfs - The REAL story! > > Attachment Details:- > > Attachment Name: sexy virgin.scr > File: sexyvirg.scr > Infected? Yes > Repaired? No > Virus Name: W32/Hybris.gen@MM > > > > -- > Richard B. Gray, Sr. Software Egr. > Plus Technologies division of Digital Controls Corp. > > mailto:richNOgSPAM@plustechnologies.com (remove NO SPAM to reply) > http://www.plustechnologies.com From norbertschade at oaktech.com Mon Feb 26 11:59:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> Tampa agenda Message-ID: <009701c0a015$85d7be80$500714ac@NSCHADEW1> I propose the following agenda: 1. UPDF schedule and directions in 2001 What meetings should we have and what will the milestones be, until we can represent level 1 of the format? Who will provide sample UPDF descriptions for some real printers and work on some sample implementation on the driver side? 2. Global paper size list That's Ron Bergman's list. 3. Command sequences in a separate module This should especially help easing the creation of font modules, but would generally make it easier to transfer a printer's description from one PDL to another. 4. Color One of the last open sections. 5. File structure and file names. We have to settle down this section more in detail. Here it comes to questions how installable options will be handled and what sections of a description are separate modules. If you have additional requirements please let me know. Regards Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010226/f98ef950/attachment.html From norbertschade at oaktech.com Tue Feb 27 16:57:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> command sequences Message-ID: <002001c0a108$3b158410$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 6884 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 686 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFCommandSequences.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 663 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 4833 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150.xml Type: text/xml Size: 19206 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__Locale en_us.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150__Localeen_us.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__CommandSequences.xml Type: text/xml Size: 2336 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150__CommandSequences.xml From norbertschade at oaktech.com Wed Feb 28 11:54:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> command sequences Message-ID: <000d01c0a1a7$2f71ee60$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__CommandSequences.xml Type: text/xml Size: 2786 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/e9c0d657/HPLaserJet8150__CommandSequences.xml From norbertschade at oaktech.com Wed Feb 28 13:52:50 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> media sizes Message-ID: <000c01c0a1b7$a6260310$500714ac@NSCHADEW1> In the files I spread around yesterday I created a temporary test size, which I will remove again in the public files. It is very similar to the normal Letter size. This was to demonstrate the chance of having two media sizes with the same MediaSize_Global_ID and/or MediaSize_Name_ID. In this case the value for x and y are identical as well. In case these values are switched, I would expect the RotatedFormat field to be set to TRUE the same time. The ID field should always be unique, as it is in this case. The major difference is the field FeedingMethod. A sample in the real world could be that a Letter has to be fed shortedge from the manual tray, but longedge from other trays. In this case the CommandSequence_ID is different, which is not necessarily the case. Another case where you would want to create a second Letter size with even all fields set to the same values would be, if you have different minimum hardware margins for it in different trays. These are just some usability studies how to work with the fields. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010228/b508296e/attachment.html From norbertschade at oaktech.com Wed Feb 28 15:28:49 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> installable options Message-ID: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> We need more discussion on that issue. this is part of item 5 of the Tampa agenda. We have agreed so far that the same set of dtd files would be used for any installable option, so you would have a new set of XML files for any installable option. that will make it easy to remove it again at any time. Definition I consider any piece of hardware, which can be physically removed from the peripheral device, an option. This may include RAM cards, input options, output options, duplexers or anything else. Rule 1: Do not specify any option in the master description. Options may come with the device - as part of the original shipment. Or they can be bought and added later. Newer options may even replace older ones. Required features Any driver should provide some functionality to ensure that at least one element is available for certain features. For printers these features include input and output features (to be discussed). RAM? So in most descriptions a master description would include an input feature, but in theory it doesn't need to. The printer could be shipped with one or more default options. Same with RAM. Now how do we specify that in detail? I see three chances to do that. 1. We could do something with the file names. Primitive sample: Printer ABC Master.xml, Printer ABC Option 2 Input Trays.xml, Printer ABC Option Duplexer, etc. Looks doable. Advantage would be to have an easy search for options when you have the master description. Sounds a bit artificially constructed and wooden. 2. We could provide some fields internally. We could create a field "Master Unit". In case this fields entry matches the unit name of the description, it must be the master. Otherwise this field would list the unit name of the master description. The master field would be repeatable to be able to tell that a certain unit can be added to a number of master descriptions. Sounds a little more sophisticated, but I'm not sure about searching performance and confusions at run time. 3. We could work with a config file. I think this requires either the implementation of option 2 or an additional install file for docking information per installable option. Then the config file is the real data entry point for the driver. It has to hold an entry for the master unit plus a more or less infinite number of optional units. All listed units are active. Deactivated units have to be removed from the config file. Adding an installable option would mean searching for an XML file, where the first entry is "Docking Information" (so called docking files), and then read whether the current master unit is listed in the list. Then add it to the XML file, where the first entry is "Configuration Information" (so called config files). This would not require any file naming conventions. I must admit that version 3 is my favovite. I will write some primitive sample docking and config files for demonstration later today and send them around. Any other proposal? What is your favorite? In all versions we agree that the description of the optional unit is based on the same set of dtd files as the master unit. Typically the master unit is the biggest description. That gives us the chance for all times to add an installable option with any feature. Unsolved challenges 1. I am concerned about the UI representation of it. In many drivers this part is shown on a config tab. In case a driver shows any optional unit as a separate check box, no problem. In case a driver shows all optional unit in a multiselect list box, no problem. Anything else gets difficult. We haven't created something like categories for installable options (input options, output options, etc.). The danger with categories is to anticipate the future. Do all options fit into the categories? Will there be additional categories in future? Free for discussion. 2. Constraints is a heavy duty. There are two questions. First is how to solve the problem that certain units cannot be attached the same time? Second is how to specify feature constraints (duplex may not work for all trays) with installable options in mind, which are yet unknown. Anyhow I think it is important to know about limitations, even if we don't solve them all. Ok, now it's up to you to think about it. As in many cases I develop some basic ideas and ask for improvement and polishing. I'm always trying to keep a concept as open as possible for future extensions. Regards Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010228/d5b8c439/attachment.html From norbertschade at oaktech.com Wed Feb 28 17:10:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> installable options, part 2 Message-ID: <002701c0a1d3$42ea32f0$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Docking Info HP Duplexing Unit.xml Type: text/xml Size: 400 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInfoHPDuplexingUnit.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Configuration HP LaserJet 8150.xml Type: text/xml Size: 410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFConfigurationHPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Description HP LaserJet 8150.xml Type: text/xml Size: 18745 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDescriptionHPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Docking Info HP 2000 Sheet Input Tray.xml Type: text/xml Size: 338 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInfoHP2000SheetInputTray.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences HP LaserJet 8150.xml Type: text/xml Size: 2606 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFCommandSequencesHPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale en_us HP LaserJet 8150.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFLocaleen_usHPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DockingInformation.dtd Type: application/octet-stream Size: 387 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInformation.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 388 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDeviceConfiguration.obj From sommer at granitesystems.com Wed Feb 28 17:25:31 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:51 2009 Subject: UPD> installable options In-Reply-To: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010228172353.00966a40@mailbox.bellatlantic.net> Norbert, What is you reason for not specifying the options in the master description file? If you have to make a configuration file then why don't you just put the information in the master file and eliminate the configuration file? Jim From norbertschade at oaktech.com Wed Feb 28 18:41:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> installable options References: <4.2.0.58.20010228172353.00966a40@mailbox.bellatlantic.net> Message-ID: <004b01c0a1e0$03c25eb0$500714ac@NSCHADEW1> Jim, thought about it some time before. If you'd add options with all their stuff into the master description, I am convinced that we only get that running for options known at the time of the master description editing. There is no chance to add/remove options later, which is the idea (especially for third parties). At least if you'd add some later, you'll have to do some serious merging of information at many different places. I consider this missing extensibility a lack of the GPD concept. Adding the configuration stuff to the master description is a fair request. We will talk it over in the meeting. There was no other reason for me than not touching a finished description after having shipped it. And I would have to add/remove references to options later. No other reason. One may have the same thinking about the docking info. I'm open in that area as well. Norbert ----- Original Message ----- From: "Jim Sommer" To: "UPD group" Sent: Wednesday, February 28, 2001 5:25 PM Subject: Re: UPD> installable options > Norbert, > > What is you reason for not specifying the options in the master description > file? If you have to make a configuration file then why don't you just put > the information in the master file and eliminate the configuration file? > > Jim > > > From norbertschade at oaktech.com Thu Mar 1 14:26:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> UPDF fonts Message-ID: <000c01c0a285$758403f0$500714ac@NSCHADEW1> I'm taking the time to review font handling in preparation to the conference. Some time ago we already agreed on a number of tasks to be done in a second step after the first definition of the font structure. Targets of this phase: 1. Move command sequences from the font handling dtd to the command sequence dtd. 2. Edit field names to have more MS Windows independent naming conventions. 3. Get a better understanding, which fields are more font technology specific and which are more device implementation specific. 4. Think about an as easy as possible job for font companies to create font descriptions. 5. Create two sample fonts. Courier and Arial with characters from 0020 to 007E and from 00A0 to 00FF only. As in many cases I am willing to do the initial work, but would appreciate some help when settling it down. Who is willing to help me some time tomorrow considering my results as it could be done in this short time? Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010301/afdf1bc2/attachment.html From hastings at cp10.es.xerox.com Mon Mar 5 00:58:13 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> PWG Media Size Standardized Names ISSUE: media type of "envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE85049977BE@x-crt-es-ms1.cp10.es.xerox.com> For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From kugler at us.ibm.com Mon Mar 5 11:20:10 2001 From: kugler at us.ibm.com (Carl Kugler) Date: Wed May 6 14:04:51 2009 Subject: UPD> Re: [Lpr-discuss] Re: PPD file for Epson Stylus Color 600 and GPr Message-ID: Some discussion about UPD-like topics is occuring on lpr-discuss. ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 03/05/2001 09:16 AM --------------------------- Robert L Krawitz @lists.sourceforge.net on 03/02/2001 06:36:38 PM Sent by: lpr-discuss-admin@lists.sourceforge.net To: thubbell@compumetric.com cc: mpruett@valinux.com, lpr-discuss@lists.sourceforge.net Subject: Re: [Lpr-discuss] Re: PPD file for Epson Stylus Color 600 and GPr Date: Fri, 02 Mar 2001 11:57:55 -0600 From: Thomas Hubbell Mark Pruett wrote: > > It looks like gpr is segfaulting when it attempts to return from > the fill_option_menus() routine. This usually indicates that > some statement within fill_option_menus() has trashed the > stack (and the function's return address). I'm trying to discover > exactly where this is happening now. I figured out what the problem is. I've actually seen this before, to tell you the truth. The problem is that gpr has a static array for the number of menu items in the Paper size menu. It's set at 45, but the ppd has 52 or so entries for page size. I doubt that the printer actually supports this many paper sizes "officially", but the gs/stp driver may have other capabilities. Epson printers are quite happy to take any size you give it, as long as it's within bounds. We went and scrounged just about everything we could find, and wound up with over 100 defined sizes. So, a quick fix to increase the array size will solve this problem. But, I wonder when we'll encounter another printer that supports 75 media sizes! Any of the large format printers probably do. Now, the foomatic PPDs may work perfectly well, but they may not necessarily be what you (or HP) want. It seems to me that these PPDs all contain UIOptions that conform directly to what the gs driver supports. Therefore, they will contain a variety of "esoteric" entries that some users may not know how to handle (Floyd-Steinberg dithering, for example). HP may prefer to create a PPD that has entries that are much closer to the windows drivers (i.e., "Best", "Normal", and "Draft" versus "1,200 x 1,200 dpi", "600 x 600 dpi", "300 x 300 dpi"). The PPD structure would allow you to combine several of the driver options into one setpagedevice command, creating something equivalent to a "Normal" mode, for instance. In this case, vendor-supplied PPDs would probably be desirable, as they (or one of their contractors) could best determine what constitutes these various modes. Again, like I said earlier -- be careful. A vendor supplied PPD with a vendor supplied driver is fine, but generally you want the PPD to match up with what whoever wrote the driver intended. That said, stp has a huge variety of options, and that's only going to get more so over time, but a lot of these options will be really obscure and only intended for people who really want to experiment -- Robert Krawitz http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton _______________________________________________ Lpr-discuss mailing list Lpr-discuss@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/lpr-discuss From hastings at cp10.es.xerox.com Mon Mar 5 13:18:35 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE85049977E1@x-crt-es-ms1.cp10.es.xerox.com> Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From imcdonald at sharplabs.com Mon Mar 5 13:34:07 2001 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ED09D@mailsrvnt02.enet.sharplabs.com> Hi Tom et al, Yes, we should use ABNF to specify what's rapidly becoming a complicated syntax. I'm neutral on your alternatives for allowing or removing media-type in the syntax. Cheers, - Ira McDonald -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 10:19 AM To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From don at lexmark.com Mon Mar 5 17:36:19 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <200103052237.RAA08382@interlock2.lexmark.com> All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 5 18:18:52 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE8504997838@x-crt-es-ms1.cp10.es.xerox.com> Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 5 19:03:26 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> Editorial comments on the "PWG Media Size Standardized Names" Dra ft D0.3 Message-ID: <918C79AB552BD211A2BD00805F15CE8504997841@x-crt-es-ms1.cp10.es.xerox.com> Ron, Great job at producing this draft! Its very readable and short. A number of us reviewed it at Xerox and we like the table organization as well (but see separate comment about '-envelope' and MediaType exception which I won't repeat in these editorial comments). Here are some editorial comments. They probably don't need to be covered at the meeting, unless some reviewer wants to being up something in particular (or disagree with my suggestions). 1. It would help to produce a line numbered .pdf version for ease of making comments. 2. Do you want to down load the .doc file too. Then the meeting could make changes if they wanted to. I created a /media-sizes sub-directory under /pwg. 3. First line of Abstract is: This document specifies standard names to be used to indicate media sizes in other PWG standards. The next sentences say that this PWG standard will be used by other standards as well, such as the Printer MIB, IPP, IPP FAX, UPnP, and wireless standards. Therefore, replace "other PWG standards" with "other standards". 4. Since many of these other standards are already published, they cannot contain references to this PWG Standard. Therefore, it would also help to identify the attributes in these other standards in which these Media Size names are intended to be used, such as: Printer MIB (RFC 1759) and Printer MIB v2, Appendix B, Media Size Names ... IPP/1.1 Model and Semantics (RFC 2911), "media" Job Template attribute The standards that are still under development can contain a reference to this PWG standard in their definitions, such as: UPnP BasicPrint Template, MediaSize parameter UPnP EnhancedLayoutPrint Template, MediaSize parameter 5. Page 4, section 1, Introduction: We should also reference existing practice as specified in the PPD and GPD specifications. 6. Page 5, section 2, Terminology: The current definition of ASCII is: ASCII American Standards Code for Information Exchange. A character set encoding with printable characters defined in the range 0x21 to 0x7E. Normally refers to a US character set, but variants are defined for many national languages. Equivalent to ISO 8859-1 character set encoding. The term ASCII should always and only mean the ANS X3.4-1988 standard, same as in all IETF standards. ASCII does NOT mean the national character sets and does not mean ISO 8859-1. In an 8-bit environment, the 8th bit MUST be 0 for ASCII. I suggest using the definition from the IPP References section: [ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange (ASCII), ANSI X3.4-1986. This standard is the specification of the US-ASCII charset. 7. Page 5, section 2, Terminology: I suggest adding the term Media Size Self Describing Name. Then add a shorter form, say, Media Size Name, so we can distinguish these names from Media Name and Media Type Name. Perhaps even add these latter two terms as well. 8. Then consistently use first letter capitalization for terms to clearly indicate that they are intended to be the specialized terms in the Terminology section. 9. Page 5, section 3, need to explain the "Alias (common) names" column. 10. Page 5, section 3.1, 1st paragraph reads: This new format has the media size embedded within the string and allows a device to operate without a media name to media size table. I find it clearer to use the terms "dimension" to mean something that has a number, rather than the vaguer word "size", since this document uses size to be a name. The above paragraph with the above editorial suggestions would read: This new format has the media dimensions embedded within the string and allows a device to operate without a media size name to media dimensions table. 11. Page 5, section 3.1, we need to use ABNF. We also need to limit the characters in this standard to a much smaller subset of ASCII: Only lower case a-z, 10 decimal digits, ".", "-", and maybe "_". This is the set allowed in IPP keywords. Of course we need to be clear that the other standards that use this standard may also require all lower case, allow upper and lower case (as being equivalent), or require all upper case. Here is a crack at the ABNF: media_size_name = [na-] name "." short_dim "-" long_dim name = lowalpha *( lowalpha | digit | "-" | "_" ) short_dim = *digit long_dim = *digit lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" I specifically chose "short" and "long", not "width" and "length" so that there is absolutely no connation of orientation in the two numeric fields. I also chose "name", since I wanted to use the shorter Media Size Name for the whole thing, not just the component before the ".". This ABNF will then remove the need to describe the syntax in words, i.e., delete the following sentences: The prefix string shall be separated from the mediaName by a hyphen (0x2D). The mediaName can consist of multiple words, with each word separated by a hyphen (0x2D). The mediaName shall contain only US-ASCII characters using the codes 0x21 through 0x2D and 0x2F through 0x7E. A period (0x2E) must not be present in the mediaName. The widthDim is separated from the lengthDim by a hyphen (0x2D). No decimal values (i.e. periods) shall be present within a media size dimension. Symbol characters (0x21 through 0x2F, 0x3A through 0x3F, 0x5B through 0x5F, and 0x7B through 0x7E) are not prohibited, with the exception of the period (0x2E), but are not encouraged. 12. Section 3.1.4 General, the following sentence needs clarification: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. While Media Size Self Describing Names are presented using all lower case in this standard, other standards that use these names, MAY: a. also require only lower case as in this standard b. allow lower and upper case to be used with the same meaning as the names in this standard, i.e., case insensistive matching c. require all upper case letters to be used with the same meaning as the names in this standard 13. Section 3.2 Custom Media Size Name Format Using the ABNF, sections 3.2.1 through 3.2.4 can be compressed into the following single line of ABNF: media_size_name = [na-] "custom-" name "." short_dim "-" long_dim 14. Tables. A number of us reviewed the document at Xerox and we liked the organization and ordering of the entries in the tables (by increasing size of the smaller dimension) and the grouping of entries separated by blank lines (when there was another logical group. But this ordering should be explained. 15. Section 4 Conformance: I suggest that any standard referencing this standard needs to specify whether the names MUST be all lower case, may be mixed case with the same meaning, or MUST be all upper case. We also need a URL so they can publish the reference to this standard. 16. Section 5 IANA Considerations ISSUE 1 IANA has a registry of media names. We need to say something about whether or not we are using it to publish our names and why. 17. Internationalization Considerations ISSUE 2 Wow. If we allow any other charsets for custom names, which does seem reasonable, then we have to modify the ABNF for custom names. Yes, we should be modern and mention UTF-8. Unfortunately, if we were to allow any charset, such as national use charsets or EBCDIC, our ABNF becomes incredibly hairy. Also there would have to be a way to convey the charset in what ever protocol was being use, so we'd have to add that requirement on the standard that was referencing out standard. I'm not sure we want to go there. Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Tue Mar 6 18:07:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F259@x-crt-es-ms1.cp10.es.xerox.com> Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From imcdonald at sharplabs.com Tue Mar 6 20:37:09 2001 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: IPP> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ED0A4@mailsrvnt02.enet.sharplabs.com> Hi Ron and Tom, Excellent! I agree with all of your conclusions below. Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: IPP> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From norbertschade at oaktech.com Thu Mar 8 18:37:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" References: <918C79AB552BD211A2BD00805F15CE8504C5F259@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <00b801c0a828$b16e06b0$500714ac@NSCHADEW1> >From the point of view of UPDF the consens described below is the way to go. 1. Keep the media type out of the Media size standard. Remove duplicates. We don't have problems with using 'monarch' and '10x13' in the size names. 'monarch' is a useful and familiar word for a specific size. 2. We would appreciate another small standard for media types. As we are already implementing the Media size standard into UPDF, we are in need for some type ID anyhow in the corresponding structure for media types. I'm not a color expert, but in case ICC profiles have a list of predefined media type names, that's worth considering as a source as well. 3. We are not in need for a media name, as proposed in Tom's notes. A media can have a number of attributes including size and type. In our system we need an unique ID for any media, but that is up to the editing developer. He/she may use Tom's way to create an ID or simply use a number or a more simple string. The eventual UI string will be different anyhow. Regards Norbert Schade ----- Original Message ----- From: "Hastings, Tom N" To: "ipp (E-mail)" Cc: "pwg (E-mail)" ; "UPDF WG (E-mail)" Sent: Tuesday, March 06, 2001 6:07 PM Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" > Ron and I had a phone discussion and have come up with the following simple > suggestions for this issue about envelope media type in the PWG Media Size > standard: > > 1. We agreed that most sizes are not intended for envelopes, some are > intended for envelopes, and some are intended for both stationery and > envelopes. > > 2. The Media Size standard should not mention media types at all. So the > exception about envelope media type in section 1.1 Scope will be removed. > We suggest that a separate short PWG standard for Media Types would be good, > that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production > Printing standards can cite for their Media Type attribute values. > > 3. The '-envelope' will be removed from all Media Size Names in the > standard, and any resulting duplicate names will be eliminated. The > envelope tables will be merged with the other tables. As has been done for > postcards, the Alias (common name) column will have "(envelope)" in > parenthesis added in order to indicate that the size is intended for > envelopes. We didn't discuss how to distinguish between the sizes, such as > na-monarch, that are intended only for envelopes and those, such as > na-10x13, which are intended for envelopes and other media types. Thoughts? > > Comments? > > Thanks, > Tom > > P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as > well. > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Monday, March 05, 2001 15:19 > To: don@lexmark.com > Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media > type of " envelope" > > > Don, > > I agree with you NOT re-order any Media Self Describing Media Name (Media > Size Name for short) from the order that is in the D0.3 draft. > > What I was talking about is, if we want to also add Media Type names to the > standard as a separate concept (also needed by UPnP and the Printer MIB), we > could do that. Then we could also define an additional syntax for Media > Names (used by IPP "media" attribute) which puts the Media Type Name in > front of the Media Size Name (same order). These Media Type Names would NOT > be enumerated in combination with all the possible sizes, but would just be > a format. Please see the rest of the attached mail message that talks about > the problem of the current draft that mixes Media Type and Media Size Name, > but only for envelope Media Types. > > Tom > > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Monday, March 05, 2001 14:36 > To: Hastings, Tom N > Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of > " envelope" > > > > > All: > > I am opposed to ANY reordering of the self describing name. > > prefix - medianame . widthDim - lengthDIM is the right format. > > ********************************************** > * Don Wright don@lexmark.com * > * Chair, Printer Working Group * > * Chair, IEEE MSC * > * * > * Director, Strategic & Technical Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 859-232-4808 (phone) 859-232-6740 (fax) * > ********************************************** > > > > > > "Hastings, Tom N" on > 03/05/2001 01:18:35 PM > > To: "pwg (E-mail)" , "ipp (E-mail)" > , "UPDF WG (E-mail)" > > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " > envelope" > > > > Just to be clear, neither alternatives (a) or (b) that I suggested in the > original mail change the current D0.3 syntax for the Media Size Self > Describing Name format which is (using the notation in the D0.3 version): > > prefix - mediaName . widthDim - lengthDim > > Alternative (b) would add a syntax for Media Names which includes the Media > Type Name followed by the Media Size Self Describing Name. I also change > the suggestion for the Media Name syntax slightly to put the 'na-' as part > of the Self Describing Media Size Name field, instead of in front of > everything, i.e.,: > > mediaTypeName . prefix - mediaName . widthDim - lengthDim > > instead of: > > prefix - mediaTypeName . mediaName . widthDim - lengthDim > > > ISSUE: Should we use real ABNF for defining the syntax? > > > Examples: > > Media Size Self Describing Name (from current draft and with either > alternative a or b): > > iso-a4.2100-2970 > iso-b4.2500-3530 > na-letter.8500-11000 > > Media Name (if alternative b is added to the draft): > > stationery.iso-a4.2100-2970 > envelope.iso-b4-2500-3530 > stationery.na-letter.8500-11000 > transparency.na-letter.8500-11000 > > Tom > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Sunday, March 04, 2001 21:58 > To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of > "envelope" > > > For discussion about the "PWG Media Size Draft standard", D0.3, on the > mailing list and the UPDF and IPP WG meetings, Monday, March 5, and > Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the > upcoming meetings. Someone take good notes, since neither Ron nor I will be > able to attend. > > Summary of issue: > > Problem: > The current draft contains sizes that are independent of media type, except > for envelopes. For each of the envelope sizes the draft includes two names, > one without '-envelope' and one with '-envelope' with the same dimensions > and says that the names with '-envelope' also imply a media type of > envelope. > > Possible Solutions: > Either: > > a. "Media Size Standardized Names" - current title > The standard should be completely independent of media type but indicate > that the size names do NOT imply media type. However, the standard should > include all sizes, even those that are primarily suited for a single media > type, such as envelopes, as well as sizes for any other media types, such as > stationery, labels, business cards, postcards, etc. > > b. "Media Size, Media Type, and Media Standardized Names" > Same as (a), but add (1) Media Type Names to the standard as a separate part > and (2) a way to combine Media Type Names and Media Size Names into Media > Names using '.' as a field separator. > > We have at least six other standards that will use the results of this PWG > standard. Here is how these other standards would use alternatives (a) and > (b): > > Media Size Media Type Media > Name Name Name > (a and b) (b) (b) > Printer MIB: > prtInputMediaName (App C) x > prtInputMediaType x > Appendix B x > > IPP: > "media" attribute x could x > > PWG IEEE/ISTO 5100.3: > "media-type" in "media-col" x > > IPP FAX: > "media" attribute x > > UPnP: > MediaType parameter x > MediaSize parameter x > > Wireless: > hopefully the same as UPnP > > > > Detailed Discussion: > The D0.3 Draft has the following paragraph in the Scope section > > 1.1 Scope > This document defines media sizes only. Other media attributes such as > color, type, or weight are not included. One exception is the inclusion of > the media type of 'envelope.' Since many envelope sizes are unique and > envelopes have very special physical characteristics which requires special > handling and printing formats, this attribute is included with the size. > > > I suggest that having this exception for envelopes will cause confusion. > The control of media type should be independent wherever Media Size Names > are used. For example, I might want to specify a stationery media type that > is any envelope size in order to proof my envelope printing. Also I might > want to specify an envelope media to be a stationery media size. > > For protocols in which the Media Type and Media Size are independent, such > as the Printer MIB and UPnP, having this exception for envelope sizes will > cause problems. Which takes precedence, if say, the Media Type is > 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? > > For protocols where the same attribute can take on Media Names and Media > Size Names, such as IPP, having Size Names that are the same as Media Names > will be ambiguous. > > In IPP, the "media" Job Template attribute takes three different kinds of > keyword names (in the following order in Appendix C): > > Media Names: > 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm > 'iso-b4-envelope': Specifies the ISO B4 envelope medium > > Input Tray Names: > 'top': The top input tray in the printer. > > Media Size Names: > 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in > ISO 216 > > This issue does point out a bug in IPP Appendix C names for the North > American keywords (but isn't for ISO and JIS names). The same keywords > appear twice with different meanings: > > Media Names: > 'na-10x13-envelope': Specifies the North American 10x13 envelope > medium > 'monarch-envelope': Specifies the Monarch envelope > 'na-number-10-envelope': Specifies the North American number 10 > business envelope medium > > Media Size Names: > 'na-10x13-envelope': Specifies the North American 10x13 size: 10 > inches by 13 inches > 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 > in) > 'na-number-10-envelope': Specifies the North American number 10 > business envelope size: 4.125 inches by 9.5 inches > > The bug is that both the Media Names and the Media Size Names have the > '-envelope' component in them, meaning that they are duplicate names. The > '-envelope' should be removed from the IPP North American Media Size Name > keywords in order to eliminate the duplicate keywords that mean different > things. The ones with '-envelope' mean an envelope medium, the ones without > '-envelope' mean just the size. How the media type is determined depends on > the IPP implementation (and possibly other attributes such as the > "media-type" member attribute of the "media-col" Job Template attribute (see > PWG Production Printing standard, for example: IETF-ISTO 5100.3 available > at: > ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). > > > Back to the PWG Media Size Name standard D0.3: > There is some duplication of semantics (if we agree NOT to include the > envelope media type semantics and stick to size names only) between: > > Table 3.3 North American Standard Sheet Media Sizes AND > Table 3.4 North American Standard Envelope Media Sizes > > and complete duplication of the ISO b and c series between: > Table 3.5 ISO Standard Sheet Media Sizes AND > Table 3.6 ISO Standard Envelope Media Sizes > > where the only difference in the Self Describing Name is whether or not > there is an '-envelope' component. > > So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. > For those entries in Table 3.4 and Table 3.6 that don't have any > corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, > either removing the '-envelope' or change it to 'envelope-size'. For > example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to > either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', > depending on which the group thinks is clearer. Same for > 'na-number-11-envelope.4500-10375', etc. > > I don't know about the Japanese and Chinese envelope sizes. > > > > Alternative (b) (add Media Type Names and Media Names) > > Alternative (b) needs all the same changes as alternative (a). In addition > we would add a list of Media Type Names. Lets start with the names from the > Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing > which includes some Media Type Names needed by UPnP: > > stationery > transparency > envelope > envelope-plain > envelope-window > continuous > continuous-long > continuous-short > tab-stock > pre-cut-tabs > full-cut-tabs > multi-part-form > labels > multi-layer > screen > screen-paged > photographic > cardstock > other > > The syntax for Media Names could be: > > [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim > > Media Names wouldn't need to be added as additional tables or table entries > in the standard, but just a rule for generation from the MediaTypeName and > the MediaSizeName values. > > Comments? > > Thanks, > Tom > > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, February 28, 2001 11:50 > To: ipp (E-mail); pwg (E-mail) > Subject: PWG> FW: Update to Media Sizes Document (version D0.3) > > > I've created a sub-directory for the PWG media-sizes project and copied D0.3 > version into it: > > ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf > > I've also copied the versions of Jim Lo's original document in .doc, .pdf, > and .html: > > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf > > Also two RFCs the deal with media from the Internet Fax group: > > RFC 2879 - Content Feature Schema for Internet Fax (V2) > RFC 2534 - Media Features for Display, Print, and Fax > > ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt > ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt > > Tom > > -----Original Message----- > From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] > Sent: Friday, February 23, 2001 07:53 > To: IMAGING@FORUM.UPNP.ORG > Subject: Update to Media Sizes Document (version D0.3) > > > I did not receive any comments on the D0.2 version, so this update only > includes the missing paragraphs plus some corrections i discovered. > > I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. > Since I am not able to attend these meetings, someone needs to take good > notes. > > Ron Bergman > Hitachi Koki Imaging Solutions > <> > > > > > > From lfarrell at cissc.canon.com Fri Mar 9 21:19:52 2001 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:04:51 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <6C940F5153E5D211937A0090274E8D8B01E411BA@cissc.cisoc.canon.com> Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 12 19:09:27 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F4C9@x-crt-es-ms1.cp10.es.xerox.com> Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From wayde.gardner at intelligraphics.com Tue Mar 13 12:15:34 2001 From: wayde.gardner at intelligraphics.com (Wayde Gardner) Date: Wed May 6 14:04:51 2009 Subject: UPD> Bluetooth technology Message-ID: <001f01c0abe1$37322b80$940211ac@intelligraphics.com> We would be happy to contribute where possible. http://www.intelligraphics.com/wireless_bluetooth.html Wayde Gardner Digital Imaging Technologies Intelligraphics, Inc. http://www.intelligraphics.com mailto:waydeg@intelligraphics.com Phone: 972-479-1770 x110 Fax: 972-479-1760 -------------- next part -------------- A non-text attachment was scrubbed... Name: Wayde Gardner.vcf Type: text/x-vcard Size: 442 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010313/22027bfa/WaydeGardner.vcf From don at lexmark.com Fri Mar 16 12:47:06 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:51 2009 Subject: UPD> Re: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Message-ID: <200103161756.MAA10986@interlock2.lexmark.com> Tom, et al: The opinion expressed at the IPP meeting in Tampa was that the MEDIA SIZES and MEDIA TYPES should be in the same document if the "-envelope" was removed from the self-describing media names in the current MEDIA SIZES document. We believed that it was important for applications that use one standard (i.e. Media Sizes) MUST also use the Media Types. By making them one standard with a conformance statement requiring usage of both we would insure conforming applications to be able to distinguish fully all sizes and types. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/12/2001 07:09:27 PM To: "pwg (E-mail)" cc: "ipp (E-mail)" , "UPDF WG (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Thu Mar 22 03:24:09 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:51 2009 Subject: UPD> MED - Media Standardized Names Draft D0.4 down-loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F8AF@x-crt-es-ms1.cp10.es.xerox.com> So Ron and I have agreed to add the Media Type Names to the Media Size Name standard, if that was the consensus at the meeting. We need to work on the conformance language some more. Since the Printer MIB and the PWG Production Printing "media-color" member attribute also use Media Color Names, we added them too. ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04-rev.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04-rev.pdf ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04.pdf Ron and I haven't merged the envelope size names with the other size names with the clarification that the size names do not imply media type. That is flagged as an issue in each of the envelope tables. Ron also has some more sizes to add. Here is the Abstract: This document specifies standard names to be used to indicate media types, media colors, and media sizes in other standards. These lists of names are a superset of the names that are currently presented in the Printer MIB [RFC1759] and the IPP Model and Semantics [RFC2911] documents. It is intended to supplement the currently defined lists as well as to provide a normative reference for all subsequent standards. This document is a draft of an IEEE-ISTO PWG Proposed Standard and is in full conformance with all provisions of the PWG Process (see http://www.pwg.org/chair/pwg-process-990825.pdf). PWG Proposed Standards are working documents of the IEEE-ISTO PWG and its working groups. The list of current PWG projects and drafts can be obtained at http://www.pwg.org. I've also sent this to the UPnP Imaging WG who originally requested the PWG to write such a standard that could be used by other print protocols. They have a telecon, Thursday, March 22. Please send comments to the above DLs. Ron and I will collaborate on updating the document. Thanks, Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, March 16, 2001 09:47 To: Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail) Subject: Re: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Tom, et al: The opinion expressed at the IPP meeting in Tampa was that the MEDIA SIZES and MEDIA TYPES should be in the same document if the "-envelope" was removed from the self-describing media names in the current MEDIA SIZES document. We believed that it was important for applications that use one standard (i.e. Media Sizes) MUST also use the Media Types. By making them one standard with a conformance statement requiring usage of both we would insure conforming applications to be able to distinguish fully all sizes and types. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/12/2001 07:09:27 PM To: "pwg (E-mail)" cc: "ipp (E-mail)" , "UPDF WG (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From norbertschade at oaktech.com Thu Mar 22 11:42:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> custom media Message-ID: <003e01c0b2ef$27edfd10$500714ac@NSCHADEW1> I like the syntax for custom media sizes, which can work for proprietary (added by some IHV) sizes added to a driver before compilation as well as sizes defined by the end user working with an installed driver. Do we want to think of something similar for types and colors? I see 'Other' in the types section. But this is just one. So if I wanted to add two proprietary ones, I'd have to use the same keyword. Don't like that. Even something like 'Other-N', where 'N' is a positive integer leaves everything open. I'm sure there are better ways to do it. Same with color? Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010322/2708169f/attachment.html From norbertschade at oaktech.com Thu Mar 22 16:41:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> generic features Message-ID: <003301c0b318$e8c670c0$500714ac@NSCHADEW1> We are talking for some time about limiting our specification to certain features like media handling, font handling, color, etc., but providing a generic method to add others like EconoMode, REt, etc. I call the latter group of features the generic features from now on for better identification. We said we would provide a number of fields to make the most entries and probably even prepare different structures for different groups of features (the simple On/Off features, finishing features like stapling/punching with position values, etc). I must say I suffer. I admit I suffer for quite a while already. As much as I like the idea to limit the UPDF to the most common features and have one more generic feature called 'GenericFeature', I don't trust it really. The more I think about it the more I suffer. And I have this suspicious feeling in my stomach that we oversee something. As some of you know I care alot about my stomach. Enough joking. I haven't solved all issues around the generic features so far. Either we solve it or they will go or we'll buy some weaknesses. 1. Bidirectional communication When it comes to bidi, the driver must detect the meaning of a certain incoming feature to make the connection to a driver setting. We haven't talked about bidi too much so far, but even if we leave it out in the first level of UPDF, I want us to anticipate enough functionality that we will not have to change a previous spec when adding new functionality in future. I have certain expectations of bidi. I do not expect bidi to tell me everything a driver may have or likes to know about a certain feature. It is enough when bidi is telling me what of the information the driver has already (either compiled or as UPDF) is to be activated. As a consequence this may activate a whole group of other information not having been passed in. And that's ok. So it comes to keywords and settings. Settings can be different things: values, ranges, structures and may be more. The point when talking about generic features is that the driver must be able to anticipate, which keywords and settings the bidi routine will pass in. Sample: it must know that the bidi keyword is EconoMode and not EMode. It must know that the setting is a toggle and not one within a range of values. If we do not care about this anticipation, we let the whole API between a driver and a communication routine open. That would mean we forget about a common API to a communication routine and leave that open to everybody's proprietary solution - which is a legitimate way to go. But I am still dreaming there will be one common IPP communication routine and one common PJL (or whatever) communication routine. That would mean every UPDF would have to anticipate the same keywords and settings. So if we find a solution for the bidi problem, I feel it must include a spec for predefined keywords and a description how settings can come in. Then a driver can understand incoming parameters. 2. Constraints I think this is even more serious. Imagine we generic features and somebody implements two instances of them: EconoMode and REt. The element name in the dtd would be GenericFeature in both cases. Literally it is not GenericFeature1 and GenericFeature2. That's the point. The element names are not unique. How would somebody specify a constraint that EconoMode=On cannot go with REt=On (forget about the nonsense of the statement)? This constraint issue is going wild in my stomach. This is definitely a showstopper! Please help me out. Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010322/0df2e837/attachment.html From RonBergman at aol.com Thu Mar 22 17:44:47 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:51 2009 Subject: Fwd: RE: UPD> custom media Message-ID: <21.929a61a.27ebda5f@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> custom media Date: Thu, 22 Mar 2001 13:40:30 -0800 Size: 6327 Url: http://www.pwg.org/archives/upd/attachments/20010322/769dbac3/attachment.mht From mike at easysw.com Fri Mar 23 08:48:53 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:51 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5F8AF@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3ABB5445.A1905FED@easysw.com> "Hastings, Tom N" wrote: > > So Ron and I have agreed to add the Media Type Names to the Media > Size Name standard, if that was the consensus at the meeting. We > need to work on the conformance language some more. > ... OK, some general comments: 1. For the media type names, is "continuous" considered to be the same as "roll"? I ask only because roll paper does not have the perforations that continuous forms have. I suggest adding a "roll" media type or ammending the description for "continuous" to include roll type media with no perforations. 2. The current media types don't address variations of particular media types; these variations are generally the "finish" of the media (glossy, matte, etc.), so I would recommend adding standard "media finish" values that can be used to identify an exact media type, rather than overloading the current media types with additional name-finish varients. 3. There is presently no way to define the min & max custom media size; this is absolutely required for this to work in the real world (otherwise how do you know what media sizes are valid?), e.g.: "custom-size-minimum." short-dim "-" long-dim "custom-size-maximum." short-dim "-" long-dim This would essentially research the "size-minimum" and "size-maximum" names, but allow a device to communicate that any size from the minimum to the maximum dimensions is supported. If these sizes are not available then the client should only select media sizes from the provided list. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Fri Mar 23 10:54:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> coating and other attributes of media Message-ID: <004401c0b3b1$94d82370$500714ac@NSCHADEW1> I second Michael Sweet's request for a "finish" (or whatever the name will be) attribute. In UPDF we have to have some solution for that anyhow. See below my view from a driver's point of view. Why is a driver/client interested in getting information about media types from the device? 1.. Simply showing it in the client's user interface for further selection. This would not require any different functionality of the client. It would mainly be marketing information that the device is able to feed a number of print media. 2.. Temperature related issues. In this case it is useful to know, which is the current media type. This requires a different print file to be sent. In the simpliest case this requires just one additional job command. 3.. Constraints The print file (not only the job settings, but the binary part) has to be seriously changed depending on the current media type. There are two areas: 3.1. Mechanical issues This can affect driver functionality at page start/end. Means sending different or additional command sequences at page start/end or even staying away from printing in certain areas e.g. at the top of the page (media type specific minimum or at least recommended margins). A special case of this issue can be to stay away from certain areas, as the media is prepared a certain way like preprinted or prepunched. It could also have tray related constraints. Certain media types may not be fed from some trays, as they need a straight paper path. Other constraints like transparency -> no duplex is another issue. 3.2. Color conversion including grey scale. When the color conversion is done in the device, e.g. you have an sRGB device, it is enough for the client to send a simple job setting like in issue 2. If the device is not capable of doing that the client may want to do the conversion itself, which means serious changes in the binary section of the print file. Sometimes device objects (fonts, rectangles and other graphical objects, etc.) are handled by the device, while raster graphics are handled by the driver. This typically is surface or finish related. Sometimes this attribute is called coating. Unfortunately it is reality that all these media type attributes are thrown into one list, more or less big and often very model and PDL specific. My private golden rule so far is, that I become suspicious, when a media seems to be two media types the same time, e.g. glossy and prepunched. To serve reality my proposal for the UPDF is that we keep one list of media types in our description. We will use the keywords of the global media standard (Ron's spec), but add at least one more attribute to each media type, called Coating. This coating seems to be the attribute a Windows 2000 devmode is interested in - more than the rather physical attributes of Ron's spec, which have more to do with the overall shape (outside the size) or stiffiness of the media. So even if two media would have the same spec keyword, we'd have a chance to differenciate between them. I wonder whether other attributes like Pre-handled (prepunched, preprinted, etc.) or opacity would be of further help. Glad we have color now. I do not see the need for other attributes. An indication whether there are enough attributes with enough variations in Ron's spec might be: Do we expect that most of the media types we know today playing a role in the game of printing are covered? Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010323/45cb4b6a/attachment.html From mike at easysw.com Fri Mar 23 10:59:02 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:51 2009 Subject: UPD> [Fwd: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded] Message-ID: <3ABB72C6.30A00945@easysw.com> -------- Original Message -------- Subject: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded Date: Fri, 23 Mar 2001 09:41:57 -0500 From: Mike Bartman To: "'Michael Sweet'" I'm just curious...why are you folks trying to name every possibility for media type that might ever have existed, or will exist? Why not just do it like DOCUMENT_FORMAT and make it an arbitrary string to be defined elsewhere, if at all? That would seem to be simplest, most flexible and even easier to implement. Why add complexity that will only limit future utility? I mean, have you included "billboard" as a media type? I know of at least one "printer" that can print billboard-sized sheets all at once...I think Fujitsu makes it. What about "bedsheet"? We have iron-on T-shirt media now (is that defined for IPP? Which size?) and someday there might be someone who makes a printer to do the same for bedsheets too. Businness card forms exist today, as do greeting cards, brochures (bi- and tri-fold) and a number of other media types, in a host of "weights", colors, textures and rag contents. There probably is, or will be, a printer server that can handle all of them from one device or media source or another...are you going to try to name them all explicitly?? Why? Maybe that got discussed when I wasn't looking, but it sure seems confusing now! :^) -- Mike > -----Original Message----- > From: Michael Sweet [mailto:mike@easysw.com] > Sent: Friday, March 23, 2001 8:49 AM > To: Hastings, Tom N > Cc: ipp (E-mail); UPDF WG (E-mail) > Subject: Re: IPP> MED - Media Standardized Names Draft D0.4 > down-loaded > > > "Hastings, Tom N" wrote: > > > > So Ron and I have agreed to add the Media Type Names to the Media > > Size Name standard, if that was the consensus at the meeting. We > > need to work on the conformance language some more. > > ... > > OK, some general comments: > > 1. For the media type names, is "continuous" considered to be > the same as "roll"? I ask only because roll paper does not > have the perforations that continuous forms have. > > I suggest adding a "roll" media type or ammending the > description for "continuous" to include roll type media > with no perforations. > > 2. The current media types don't address variations of particular > media types; these variations are generally the "finish" of > the media (glossy, matte, etc.), so I would recommend adding > standard "media finish" values that can be used to identify > an exact media type, rather than overloading the current > media types with additional name-finish varients. > > 3. There is presently no way to define the min & max custom > media size; this is absolutely required for this to work > in the real world (otherwise how do you know what media > sizes are valid?), e.g.: > > "custom-size-minimum." short-dim "-" long-dim > "custom-size-maximum." short-dim "-" long-dim > > This would essentially research the "size-minimum" and > "size-maximum" names, but allow a device to communicate > that any size from the minimum to the maximum dimensions > is supported. If these sizes are not available then the > client should only select media sizes from the provided > list. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > From norbertschade at oaktech.com Fri Mar 23 11:15:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> more attributes for media Message-ID: <001001c0b3b4$8ba622e0$500714ac@NSCHADEW1> One more comment: I do not in every case require that a new media attribute like Coating goes with a list of predefined keywords. In some cases it may just be fine to agree on certain attributes that drivers/client deal with the same kind of structures, so they have a similar approach to understanding a number of communication protocols, etc. API's would be similar. An attribute Coating can as well go with a specification for custom coating as the only 'predefined' keyword, just following the general approach just in this spec. Perhaps we want to add the most common keywords in case of coating as well. For other attributes a custom keyword can be sufficient and leaves the spec open to any future extension. Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010323/0d408f15/attachment.html From norbertschade at oaktech.com Fri Mar 23 15:08:24 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> UPDF meeting notes from Tampa Message-ID: <003001c0b3d5$041a6ae0$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 145 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010323/d298ff7a/attachment.gif From mike at easysw.com Mon Mar 26 10:20:34 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:51 2009 Subject: UPD> [Fwd: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded] Message-ID: <3ABF5E42.158B0EDB@easysw.com> -------- Original Message -------- Subject: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded Date: Fri, 23 Mar 2001 12:18:22 -0500 From: Mike Bartman To: "'Michael Sweet'" > From: Michael Sweet [mailto:mike@easysw.com] > Mike Bartman wrote: > > > > I'm just curious...why are you folks trying to name every > > possibility for media type that might ever have existed, or will > > exist? Why not just do it like DOCUMENT_FORMAT and make it an > > arbitrary string to be defined elsewhere, if at all? That would > > seem to be simplest, most flexible and even easier to implement. > > Why add complexity that will only limit future utility? > > I think the main issue is that *standard* media types need to be > enumerated (by keyword value) so that you don't end up with 50 > different names for "plain paper"... :) Ok, I can see that. With document-format isn't the deal that you can use any mime-media type, defined by RFC, or an arbitrary string? That would get you the base level of standardization that everyone could count on (assuming that there's an equivalent for media formats like there was for document data formats), without limiting proprietary extensions that may be necessary in some cases. I'm not sure that just having a single "custom" value is good enough...I'd like to be able to reference my own media type by a name that makes sense to me, not by "custom" with a definition each time. "bonus stickers" might be a value I want to use for media type...and it might make sense to my programmable printer, where it's equal to "bin 1" or "make operator request with that name" or something. If there was a "media-types-supported" value in the get-printer-attributes reply, I could even present such a thing to a user for them to select if they want to. > Without a standard naming convention (whether all the valid values > are defined or not) there can be no interoperability between > systems and devices. The goal is to allow a single piece of > software/hardware to communicate with any presentation device > without having to be hardcoded/wired for each device. No problem with that as a base, I just wouldn't like to see it stop there. I want to be able to extend the media type names that are available, either because the printer knows them, or because it can be told what to call things that it knows about (alias naming?) to more closely match user expectations for various forms of media (Purchase Order Forms, Billboards, etc.). The client doesn't have to have things hardcoded...they can be configuration settings, or acquired from the printer through query. My client will accept anything the user cares to enter for most items, and only overrules when there's a printer attribute that the client has received that says it isn't going to work (i.e. user asks for 1000 copies on a printer with a valid copies range of 1:99). I don't want to waste your time on this if all this has been handled. Just trying to offer a suggestion in case it wasn't already ruled out for some reason. Like I said, I haven't followed the entire discussion on this one. I've been implementing my IPP client... (now in beta test! :^) Thanks for reading. If it's useful, feel free to pass it on, if it's not, then just ignore me. :^) -- Mike Bartman From norbertschade at oaktech.com Mon Mar 26 12:17:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF Message-ID: <000c01c0b618$95964ee0$500714ac@NSCHADEW1> We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010326/25e5a077/attachment.html From sommer at granitesystems.com Mon Mar 26 22:00:58 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF In-Reply-To: <000c01c0b618$95964ee0$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010326220023.00954320@mailbox.bellatlantic.net> I vote for one PDL per UPDF. Jim At 3/26/01 12:17 PM, Norbert Schade wrote: >We never finally decided whether we will allow exactly one PDL per UPDF >description or more. >I put that on vote. >Please send your vote this week. >We will decide on Friday, March 30th, late afternoon. > >My personal vote is one PDL only. >Reasons: >Don't move more information around than you need. >Editing of XML files is easier, when there are parrallel files (master >description, command sequences, locales, etc.) instead of editing >different sections in very different areas of one huge file. >Development is possible in steps done by different groups, while one huge >description probably never gets done. > >Regards >Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010326/15d51f08/attachment.html From don at lexmark.com Tue Mar 27 08:12:43 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF Message-ID: <200103271313.IAA20417@interlock2.lexmark.com> As much as I'd like one all encompassing UPDF, I think having only one PDL per UPDF is the only practical solution. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Norbert Schade" on 03/26/2001 12:17:06 PM To: "UPD group" cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> PDL per UPDF We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010327/f18a0445/att1.htm From harryl at us.ibm.com Tue Mar 27 09:29:48 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF Message-ID: One PDL per UPDF. While UPDF may seem to be lagging in development and adoption, I still think it is a powerful idea. I'm afraid the complexity of simultaneously addressing multiple PDLs might keep things from ever getting off the ground. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Norbert Schade" Sent by: owner-upd@pwg.org 03/26/2001 10:17 AM To: "UPD group" cc: Subject: UPD> PDL per UPDF We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade From sommer at granitesystems.com Tue Mar 27 10:30:59 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:51 2009 Subject: UPD> Generic Features In-Reply-To: <004401c0b3b1$94d82370$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010327100751.009687e0@mailbox.bellatlantic.net> Norbert and I met yesterday to go over a few items. The one item that we spent the most time with was the "Generic Feature". If you recall, the generic feature was a way of allowing the definition of features that we couldn't possibly conceive of but that are generally controlled with either PJL, IPP or special PS at the beginning of a job. The generic feature doesn't affect how the driver generates PDL, it just generates special, device specific commands. Defining the structure for the generic feature wasn't a problem but handling them in constraints was. Norbert and I couldn't come up with a generic solution so we've had to fall back to the following: - Identify common, currently-used printer features and define these in UPDF. - Allow for a fixed number of other printer features and allot space for them in UPDF. The proposal is to allot space for 16 generic, undefined printer features. In addition, the following features will be predefined: - Output Order - Jog - Staple - Punch - Finishing - Print Density - Print Quality - Resolution Enhancement - Toner Saver - Page Protect - Jam Recovery The structure of each of the predefined features will be exactly the same as the generic features so they can really be used as desired. If anyone has any other items that they'd like to be predefined, we're open to suggestions. I think that if we have 16 predefined features in addition to 16 generic features then that should be more than adequate. Comment? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010327/a132caba/attachment.html From mike at easysw.com Tue Mar 27 12:41:40 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:51 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE56@triton.hitachi-hkis.com> Message-ID: <3AC0D0D4.7D566C36@easysw.com> "Bergman, Ron" wrote: > ... > 1. Roll paper was purposely omitted from the document. Refer to > the second paragraph of section 1.1, Scope. This decision was > made for two reasons; 1) it adds another level of complexity to > the document and 2) there appears to be very little interest by > PWG participants in roll feed devices. That's a shame, since roll feed devices are extremely popular and would benefit from some "standard" support. I'm not sure what additional complexity you see, aside from describing the min and max size of the media. Adding a "roll" media type will at least allow the media to be accurately specified - cutter control, etc. can be left to other attributes in other places. > 2. Since we have already "bit the bullet" and added Media Type > and Color, finish is a likely next step. Since my time is > currently limited and knowledge of this subject is minimal, > a volunteer is needed to provide the necessary input. So, > when can you have a draft? ;-) :) I'll be out of the office for the next couple weeks, so unless you can wait that long don't expect anything from me... > 3. Maximum and minimum values define a characteristic of the > printer and I believe this is way beyond the scope of this > document. The Printer MIB currently provides an excellent > source for this information. That may be true, but that doesn't help IPP clients... If the printer MIB defines attribute names, maybe we can mirror them here so that they will be used in other protocols with the same names and ranges? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From markv at us.ibm.com Tue Mar 27 20:51:05 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF Message-ID: >At 3/26/01 12:17 PM, Norbert Schade wrote: >We never finally decided whether we will allow exactly one PDL per UPDF description or more. Yes, I am listening and I vote 1 PDL per updf. Reason: Varying capabilities between PDL personalities such as fonts, resolutions, printable area, ... would cause too much confusion. Additional comments: Having a separate command file will give some flexibility. Additional concerns: Some previsions must be made for PDLs which contain multiple modes or commands to do the same thing. For example, PCL5 (a single PDL has an HPGL/2 mode). Or are you saying PCL5 not using HPGL/2 is one PDL and PCL5 in HPGL/2 MODE is another. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Wed Mar 28 11:15:13 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> PDL per UPDF References: Message-ID: <002301c0b7a2$4505b200$500714ac@NSCHADEW1> I think we got to support different 'RenderingMode' like Raster and GL. E.g. fonts have to be accessible in both modes, but they have different command sequences. We have to check, where this element belongs in our description. I guess it's on a quite high level. The support of GL is one major reason, why I wanted to provide support for 'IF'-statements in command sequences. See Parameter converter documentation. This may become clearer now. So we can support two or more modes in one command sequence. that is definitely not possible in any other device description. Norbert Schade ----- Original Message ----- From: "Mark VanderWiele" To: Sent: Tuesday, March 27, 2001 8:51 PM Subject: Re: UPD> PDL per UPDF > >At 3/26/01 12:17 PM, Norbert Schade wrote: > >We never finally decided whether we will allow exactly one PDL per UPDF > description or more. > > Yes, I am listening and I vote 1 PDL per updf. > > Reason: Varying capabilities between PDL personalities such as fonts, > resolutions, printable area, ... would cause too much confusion. > > Additional comments: Having a separate command file will give some > flexibility. > > Additional concerns: Some previsions must be made for PDLs which contain > multiple modes or commands to do the same thing. For example, PCL5 (a > single PDL has an HPGL/2 mode). Or are you saying PCL5 not using HPGL/2 is > one PDL and PCL5 in HPGL/2 MODE is another. > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678-4779 > MARKV@IBMUS > email: markv@us.ibm.com > > From norbertschade at oaktech.com Wed Mar 28 13:16:03 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> open standard for locales Message-ID: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> If you look into the 'UPDF Entities.dtd', you see an entity defined for locales. It's a quite short list implemented by Mike Young about two years ago. I'd like to finish that section in the near future. So I am asking for a proper concept we can use in our open standard. Requirements: It has to be complete, which means it should support all major human languages. It must provide two components, where the first is the default language like English and the second is the dialect. This allows required fallback routines. Right now we have a more verbal system with an uncomplete list. Before we finish that I ask for feedback from experts. Even if you connect me to some people, who are supposed to be the experts, it'd be fine. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010328/008f41a2/attachment.html From sommer at granitesystems.com Wed Mar 28 14:26:11 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:51 2009 Subject: UPD> open standard for locales In-Reply-To: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> You can get language codes from http://www.unicode.org/unicode/onlinedat/languages.html. It has a table showing the language name, the 2 character ISO-639 code, the Windows code number, the Mac name, and the Mac code number. You can get country codes from http://www.unicode.org/unicode/onlinedat/countries.html. It has a table showing the country name, the 2 and 3 character ISO-3166 codes, the Windows code number, the Mac name, and the Mac code number. Of course it's hard to know which languages are spoken in which countries. You could just allow a locale to consist of any language code with any country code. If you want to limit the list, I got the following list of language - country pairs from the Microsoft help: Arabic - Saudi Arabia Arabic - Iraq Arabic - Egypt Arabic - Libya Arabic - Algeria Arabic - Morocco Arabic - Tunisia Arabic - Oman Arabic - Yemen Arabic - Syria Arabic - Jordan Arabic - Lebanon Arabic - Kuwait Arabic - U.A.E. Arabic - Bahrain Arabic - Qatar Bulgarian - Bulgaria Catalan - Spain Chinese - Taiwan Chinese - PRC Chinese - Hong Kong Chinese - Singapore Chinese - Macau Czech - Czech Republic Danish - Denmark German - Germany German - Switzerland German - Austria German - Luxembourg German - Liechtenstein Greek - Greece English - United States English - United Kingdom English - Australia English - Canada English - New Zealand English - Ireland English - South Africa English - Jamaica English - Caribbean English - Belize English - Trinidad English - Zimbabwe English - Philippines Spanish - Spain Spanish - Mexico Spanish - Spain (International Sort) Spanish - Guatemala Spanish - Costa Rica Spanish - Panama Spanish - Dominican Republic Spanish - Venezuela Spanish - Colombia Spanish - Peru Spanish - Argentina Spanish - Ecuador Spanish - Chile Spanish - Uruguay Spanish - Paraguay Spanish - Bolivia Spanish - El Salvador Spanish - Honduras Spanish - Nicaragua Spanish - Puerto Rico Finnish - Finland French - France French - Belgium French - Canada French - Switzerland French - Luxembourg French - Monaco Hebrew - Israel Hungarian - Hungary Icelandic - Iceland Italian - Italy Italian - Switzerland Japanese - Japan Korean - Korea Dutch - Netherlands Dutch - Belgium Norwegian - Norway (Bokmal) Norwegian - Norway (Nynorsk) Polish - Poland Portuguese - Brazil Portuguese - Portugal Romanian - Romania Russian - Russia Croatian - Croatia Serbian - Serbia (Latin) Serbian - Serbia (Cyrillic) Slovak - Slovakia Albanian - Albania Swedish - Sweden Swedish - Finland Thai - Thailand Turkish - Turkey Urdu - Pakistan Indonesian - Indonesia Ukrainian - Ukraine Belarusian - Belarus Slovene - Slovenia Estonian - Estonia Latvian - Latvia Lithuanian - Lithuania Classic Lithuanian - Lithuania Farsi - Iran Vietnamese - Viet Nam Armenian - Armenia Azeri - Azerbaijan (Latin) Azeri - Azerbaijan (Cyrillic) Basque - Spain FYRO Macedonian - Former Yugoslav Republic of Macedonia Afrikaans - South Africa Georgian - Georgia Faeroese - Faeroe Islands Hindi - India Malay - Malaysia Malay - Brunei Darussalam Kazak - Kazakstan Swahili - Kenya Uzbek - Uzbekistan (Latin) Uzbek - Uzbekistan (Cyrillic) Tatar - Tatarstan Bengali - India Punjabi - India Gujarati - India Oriya - India Tamil - India Telugu - India Kannada - India Malayalam - India Assamese - India Marathi - India Sanskrit - India Konkani - India Jim From sommer at granitesystems.com Wed Mar 28 14:40:46 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:51 2009 Subject: UPD> open standard for locales In-Reply-To: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> References: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010328143038.00955bb0@mailbox.bellatlantic.net> Another table of Windows language - country pairs can be found at http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm Jim From norbertschade at oaktech.com Wed Mar 28 15:44:39 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:51 2009 Subject: UPD> open standard for locales References: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> Message-ID: <005a01c0b7c7$e8cfc7c0$500714ac@NSCHADEW1> Ok, with these ones we can be sure that we are on the safe side. I'd rather stay away from the Microsoft list. This kind of conversion would be up to the Windows driver. Looks that we go with the ISO code for the language and the ISO Code2 for the country right now. Do we want to stick with it? If yes, we'd want to have an entity for locales to be used as the parameter in Locale_ID in our locale files. These entries should look like 'Arabic - Saudi Arabia - arSA'. The first two components make it easy for the human reader to select the proper entry. The third component of the keyword is the ISO abbreviation. Our locale files have three components: a predefined identifyer "UPDF Locale", a second component and the IHV component like "HP LaserJet" (supposed to be used with all HP LaserJets in this sample). I do not think the second component should be the first two components of the language/country keyword. This could result in an unbelievable long file name. So I'd appreciate to use the ISO abbreviation instead. A developer editing locale files could easily detect the abbreviation from the third component of the Locale_ID list. this would always be a four character entry. Has even advantages when sorting. This would keep us almost identical with our entity list. We'd eliminate the underscore and extend the list. Would be a significant step in our file naming convention. I'd appreciate some short statements before we make it a rule. Hope to confirm that tomorrow as well as the PDL per UPDF description. Regards Norbert Schade BTW: Assuming we will not get serious complaints about the above option who can quickly assemble the three-component list as described??? Let's say somewhere next week when confirmed tomorrow? ----- Original Message ----- From: "Jim Sommer" To: "Norbert Schade" ; "UPD group" Sent: Wednesday, March 28, 2001 2:26 PM Subject: Re: UPD> open standard for locales > You can get language codes from > http://www.unicode.org/unicode/onlinedat/languages.html. It has a table > showing the language name, the 2 character ISO-639 code, the Windows code > number, the Mac name, and the Mac code number. > > You can get country codes from > http://www.unicode.org/unicode/onlinedat/countries.html. It has a table > showing the country name, the 2 and 3 character ISO-3166 codes, the Windows > code number, the Mac name, and the Mac code number. > > Of course it's hard to know which languages are spoken in which countries. > You could just allow a locale to consist of any language code with any > country code. If you want to limit the list, I got the following list of > language - country pairs from the Microsoft help: > > Arabic - Saudi Arabia > Arabic - Iraq > Arabic - Egypt > Arabic - Libya > Arabic - Algeria > Arabic - Morocco > Arabic - Tunisia > Arabic - Oman > Arabic - Yemen > Arabic - Syria > Arabic - Jordan > Arabic - Lebanon > Arabic - Kuwait > Arabic - U.A.E. > Arabic - Bahrain > Arabic - Qatar > Bulgarian - Bulgaria > Catalan - Spain > Chinese - Taiwan > Chinese - PRC > Chinese - Hong Kong > Chinese - Singapore > Chinese - Macau > Czech - Czech Republic > Danish - Denmark > German - Germany > German - Switzerland > German - Austria > German - Luxembourg > German - Liechtenstein > Greek - Greece > English - United States > English - United Kingdom > English - Australia > English - Canada > English - New Zealand > English - Ireland > English - South Africa > English - Jamaica > English - Caribbean > English - Belize > English - Trinidad > English - Zimbabwe > English - Philippines > Spanish - Spain > Spanish - Mexico > Spanish - Spain (International Sort) > Spanish - Guatemala > Spanish - Costa Rica > Spanish - Panama > Spanish - Dominican Republic > Spanish - Venezuela > Spanish - Colombia > Spanish - Peru > Spanish - Argentina > Spanish - Ecuador > Spanish - Chile > Spanish - Uruguay > Spanish - Paraguay > Spanish - Bolivia > Spanish - El Salvador > Spanish - Honduras > Spanish - Nicaragua > Spanish - Puerto Rico > Finnish - Finland > French - France > French - Belgium > French - Canada > French - Switzerland > French - Luxembourg > French - Monaco > Hebrew - Israel > Hungarian - Hungary > Icelandic - Iceland > Italian - Italy > Italian - Switzerland > Japanese - Japan > Korean - Korea > Dutch - Netherlands > Dutch - Belgium > Norwegian - Norway (Bokmal) > Norwegian - Norway (Nynorsk) > Polish - Poland > Portuguese - Brazil > Portuguese - Portugal > Romanian - Romania > Russian - Russia > Croatian - Croatia > Serbian - Serbia (Latin) > Serbian - Serbia (Cyrillic) > Slovak - Slovakia > Albanian - Albania > Swedish - Sweden > Swedish - Finland > Thai - Thailand > Turkish - Turkey > Urdu - Pakistan > Indonesian - Indonesia > Ukrainian - Ukraine > Belarusian - Belarus > Slovene - Slovenia > Estonian - Estonia > Latvian - Latvia > Lithuanian - Lithuania > Classic Lithuanian - Lithuania > Farsi - Iran > Vietnamese - Viet Nam > Armenian - Armenia > Azeri - Azerbaijan (Latin) > Azeri - Azerbaijan (Cyrillic) > Basque - Spain > FYRO Macedonian - Former Yugoslav Republic of Macedonia > Afrikaans - South Africa > Georgian - Georgia > Faeroese - Faeroe Islands > Hindi - India > Malay - Malaysia > Malay - Brunei Darussalam > Kazak - Kazakstan > Swahili - Kenya > Uzbek - Uzbekistan (Latin) > Uzbek - Uzbekistan (Cyrillic) > Tatar - Tatarstan > Bengali - India > Punjabi - India > Gujarati - India > Oriya - India > Tamil - India > Telugu - India > Kannada - India > Malayalam - India > Assamese - India > Marathi - India > Sanskrit - India > Konkani - India > > > Jim > > From RonBergman at aol.com Wed Mar 28 21:17:17 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: Fwd: FW: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <8f.8ddbfb9.27f3f52d@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Wed, 28 Mar 2001 18:17:38 -0800 Size: 1896 Url: http://www.pwg.org/archives/upd/attachments/20010328/3c742e05/attachment.mht From hastings at cp10.es.xerox.com Wed Mar 28 21:50:57 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FB2C@x-crt-es-ms1.cp10.es.xerox.com> In response to Michael's three suggestions: 1. Request to add roll media as a media type. I agree with Ron's answer. The current definition of the 'continuous' types indicates that it consists of sheets (of a predetermined size) connected together, while roll media requires cutting. Here are the definitions from the Media standard: continuous Continuously connected sheets of an opaque material - which edge is connected is not specified continuous-long Continuously connected sheets of an opaque material connected along the long edge continuous-short Continuously connected sheets of an opaque material connected along the short edge So I think we should not introduce the notion of roll media and stick with roll media being out of scope. 2. Request to add media finish, here is what the PWG IEEE-ISTO Production Printing standard, 5100.3 has for "media-front-coating" and "media-back-coating" (not media finish, but I think they are the same thing): 3.13.10 media-front-coating (type3 keyword | name(MAX)) and media-back-coating (type3 keyword | name(MAX)) The "media-front-coating" and "media-back-coating" member attributes indicate what pre-process coating has been applied to the front and back of the desired media, respectively. Standard keyword values for "media-front-coating" and "media-back-coating" are: 'none' Indicated that the media MUST not have any coating. 'glossy' Indicates that the media MUST have a "glossy" coating. 'high-gloss' Indicates that the media MUST have a "high-gloss" coating. 'semi-gloss' Indicates that the media MUST have a "semi-gloss" coating. 'satin' Indicates that the media MUST have a "satin" coating. 'matte' Indicates that the media MUST have a "matte" coating. The "media-front-coating-supported" (1setOf (type3 keyword | name(MAX))) and "media-back-coating-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of these "media-front-coating" and "media-back-coating" member attributes that the Printer supports. JDF Spirial 6 also includes the same values and as "coatings", not "finish": FrontCoatings ? Enumeration-Span What pre-process coating has been applied to the front surface of the media. Possible values are: None: the default. Glossy HighGloss Matte Satin Semigloss So I would not oppose adding MediaCoating to the Media standard, what do others think? 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim Such an addition would be necessary, if the UPnP Printer template is to reference our PWG standard for its MediaType and MediaSize syntaxes and standardized values, instead of defining its own syntax. So I'd be in favor of adding the minimum and maximum syntax for use with custom media sizes. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, March 27, 2001 08:36 To: 'Michael Sweet'; Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Michael, In response to your comments: 1. Roll paper was purposely omitted from the document. Refer to the second paragraph of section 1.1, Scope. This decision was made for two reasons; 1) it adds another level of complexity to the document and 2) there appears to be very little interest by PWG participants in roll feed devices. 2. Since we have already "bit the bullet" and added Media Type and Color, finish is a likely next step. Since my time is currently limited and knowledge of this subject is minimal, a volunteer is needed to provide the necessary input. So, when can you have a draft? ;-) 3. Maximum and minimum values define a characteristic of the printer and I believe this is way beyond the scope of this document. The Printer MIB currently provides an excellent source for this information. Ron Bergman Hitachi Koki Imaging Solutions -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, March 23, 2001 5:49 AM To: Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail) Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Hastings, Tom N" wrote: > > So Ron and I have agreed to add the Media Type Names to the Media > Size Name standard, if that was the consensus at the meeting. We > need to work on the conformance language some more. > ... OK, some general comments: 1. For the media type names, is "continuous" considered to be the same as "roll"? I ask only because roll paper does not have the perforations that continuous forms have. I suggest adding a "roll" media type or ammending the description for "continuous" to include roll type media with no perforations. 2. The current media types don't address variations of particular media types; these variations are generally the "finish" of the media (glossy, matte, etc.), so I would recommend adding standard "media finish" values that can be used to identify an exact media type, rather than overloading the current media types with additional name-finish varients. 3. There is presently no way to define the min & max custom media size; this is absolutely required for this to work in the real world (otherwise how do you know what media sizes are valid?), e.g.: "custom-size-minimum." short-dim "-" long-dim "custom-size-maximum." short-dim "-" long-dim This would essentially research the "size-minimum" and "size-maximum" names, but allow a device to communicate that any size from the minimum to the maximum dimensions is supported. If these sizes are not available then the client should only select media sizes from the provided list. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Wed Mar 28 22:20:59 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5FB2C@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AC2AA1B.58CBEDE9@easysw.com> "Hastings, Tom N" wrote: > ... > So I think we should not introduce the notion of roll media and > stick with roll media being out of scope. I personally disagree with this decision, especially since there *are* consumer inkjets today (and for the past several years, in fact) that support roll (sometimes called "banner") media of more-or-less arbitrary length. I understand that some things about roll media may be out of scope (cutting, marking, etc.), but to ignore roll media entirely will make this specification useless. I merely propose that the following media type be added to the current specification: 'roll' - A continuous roll of media whose limits are described by the custom-min and custom-max sizes. Again, it is *extremely* important that we support roll media types because they are available for many consumer inkjets as well as high-end devices. Most of these devices *do* need to know that you want to use roll fed media, and if no keyword is defined for it then you'll end up with a different name for each implementation. I agree, however, that things like cutter control and marking the page area on the media are beyond the scope of this specification, so any mention of roll media should be limited to the media type and not any of the other issues. > ... > So I would not oppose adding MediaCoating to the Media standard, > what do others think? Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? > ... > Translating the UPnP syntax to our ABNF would become: > > custom-media-size-max-self-describing-name = > [prefix] "custom-max" "." short-dim "-" long-dim > > custom-media-size-min-self-describing-name = > [prefix] "custom-min" "." short-dim "-" long-dim Yes, this will work perfectly well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From sommer at granitesystems.com Thu Mar 29 09:02:14 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:52 2009 Subject: UPD> open standard for locales In-Reply-To: <005a01c0b7c7$e8cfc7c0$500714ac@NSCHADEW1> References: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> Message-ID: <4.2.0.58.20010329085740.00956310@mailbox.bellatlantic.net> I think that using the ISO abbreviations is the best way to go. My only preference would be that the 4 character locale code be the fist component instead of the last component but it doesn't make that much of a difference. Since I already have a list started, I will volunteer to complete the list and post it soon. Jim At 3/28/01 03:44 PM, Norbert Schade wrote: >Ok, with these ones we can be sure that we are on the safe side. >I'd rather stay away from the Microsoft list. >This kind of conversion would be up to the Windows driver. >Looks that we go with the ISO code for the language and the ISO Code2 for >the country right now. Do we want to stick with it? >If yes, we'd want to have an entity for locales to be used as the parameter >in Locale_ID in our locale files. >These entries should look like 'Arabic - Saudi Arabia - arSA'. >The first two components make it easy for the human reader to select the >proper entry. >The third component of the keyword is the ISO abbreviation. >Our locale files have three components: a predefined identifyer "UPDF >Locale", a second component and the IHV component like "HP LaserJet" >(supposed to be used with all HP LaserJets in this sample). >I do not think the second component should be the first two components of >the language/country keyword. This could result in an unbelievable long file >name. So I'd appreciate to use the ISO abbreviation instead. >A developer editing locale files could easily detect the abbreviation from >the third component of the Locale_ID list. >this would always be a four character entry. Has even advantages when >sorting. > >This would keep us almost identical with our entity list. We'd eliminate the >underscore and extend the list. >Would be a significant step in our file naming convention. > >I'd appreciate some short statements before we make it a rule. Hope to >confirm that tomorrow as well as the PDL per UPDF description. > >Regards >Norbert Schade > >BTW: Assuming we will not get serious complaints about the above option who >can quickly assemble the three-component list as described??? Let's say >somewhere next week when confirmed tomorrow? From norbertschade at mediaone.net Thu Mar 29 08:21:59 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:52 2009 Subject: UPD> Device configuration in UPDF Message-ID: <000201c0b86d$6cd7c540$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFCommandSequences.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Configuration.doc Type: application/octet-stream Size: 95744 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFConfiguration.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 8150.xml Type: text/xml Size: 917 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceConfiguration-HPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 18374 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 1340 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceConfiguration.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 740 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deAT-HP LaserJet.xml Type: text/xml Size: 1767 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale-deAT-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale-enUS-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Option Configuration-HP Duplexing Unit PCL5e.xml Type: text/xml Size: 758 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFOptionConfiguration-HPDuplexingUnitPCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF OptionConfiguration.dtd Type: application/octet-stream Size: 1283 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFOptionConfiguration.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2517 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFCommandSequences-HPLaserJetPCL5e.xml From RonBergman at aol.com Thu Mar 29 12:06:21 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Thu, 29 Mar 2001 08:56:53 -0800 Size: 9069 Url: http://www.pwg.org/archives/upd/attachments/20010329/d1f535ca/attachment.mht From RonBergman at aol.com Thu Mar 29 12:07:26 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Thu, 29 Mar 2001 09:00:29 -0800 Size: 3888 Url: http://www.pwg.org/archives/upd/attachments/20010329/07e59575/attachment.mht From mike at easysw.com Thu Mar 29 14:50:02 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6E@triton.hitachi-hkis.com> Message-ID: <3AC391EA.2E38703B@easysw.com> "Bergman, Ron" wrote: > > Michael, > > I will add your roll definition to the Media Types section. In > your first request for this addition, I envisioned a major change > to the sizes table to include roll. This definition will be > included in the next draft. > ... Thanks! -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Thu Mar 29 15:09:18 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6D@triton.hitachi-hkis.com> Message-ID: <3AC3966E.B2859926@easysw.com> "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From sommer at granitesystems.com Thu Mar 29 15:16:46 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded In-Reply-To: <3AC3966E.B2859926@easysw.com> References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6D@triton.hitachi-hkis.com> Message-ID: <4.2.0.58.20010329151318.00971100@mailbox.bellatlantic.net> I agree with Michael, I think we should define the keywords that are used to identify the smallest and largest user-defined, custom paper sizes. These two "paper sizes" can appear in the list of supported sizes and indicate that custom sizes are supported and the range of allowable sizes. I think it fits in perfectly with what we're trying to do with this document. Jim At 3/29/01 03:09 PM, Michael Sweet wrote: >"Bergman, Ron" wrote: > > ... > > I disagee with your proposal for adding printer size restrictions > > to the document. So far this specification has only involved > > attributes related to media. Now you are proposing that we add > > an attribute that is related to printers. This belongs in the > > appropriate UPnP or IPP or other document that defines how to > > describe a printer. If we add this then it will be necessary > > ... > >I'm not sure I agree with this (or maybe I just not understanding >your objection right); the purpose of this standard/spec is to >define the names used for media sizes, types, finishes, etc. so >that other protocols can then use those names uniformly. > > From an implementation standpoint, it may be desireable to have >media size names that are reserved for representing 1) whether >custom media sizes are supported, and 2) what the size limits are >for the device being queried. This allows all protocols to use >a common method for conveying the custom media size information, >while the exact values used in the custom size names are determined >by the device and not the protocols or this spec. > >IPP contains no explicit support for custom media sizes; CUPS >works around this limitation by supporting a "custom" media size >keyword and relies on the to know that they can request a custom >media size using the name "custom.WWWxLLL", where "WWW" and "LLL" >are the width and length of the media in points (works well for >a PS-based printing system... :) This only works for CUPS, and >I have no idea what Microsoft does, for example, with their >media support under Windows 2000... > >So, I guess what I'm saying is this: > > 1. Describe "custom-min" and "custom-max" media size names > and the format they use. Specify that these names will > only be present for devices that support custom sizes, and > that both must appear if they are used at all. > > 2. Explicitly state that the values used in the custom-min/max > names are defined by the device and not the spec. > > 3. Explicitly state that the units for media sizes in the > size names are set by the media spec and not by the > protocol spec. Units outside the size name can obviously > be anything the protocol wants... > >#1 will make sure that any client can determine if a device supports >custom sizes, no matter what protocol is being used. > >#2 will remove any requirement for additional info in the media spec >on how to manage custom sizes. > >#3 will ensure that the dimensions in size names are consistent no >matter what protocol is being used. > >-- >______________________________________________________________________ >Michael Sweet, Easy Software Products mike@easysw.com >Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Thu Mar 29 15:33:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:52 2009 Subject: UPD> min/max custom size values Message-ID: <001a01c0b88f$77a2dc90$500714ac@NSCHADEW1> Hmmmmmm... We are reaching dangerous areas. As much as I like to have the keywords a driver can look for to find those values, I hope that nobody is expecting this to tell anything, where the two values belong to. Explicitely: If somebody sends the current print media sizes available in the different trays to the host with a communication protocol like IPP (or another), he should not add a min/max custom size value generally. This would indicate that these two values are valid for all input trays, which normally is wrong. These are input tray specific values. I know that they can be affected by some other setting as well like a duplexer. These conditions are certainly out of scope of the global media list. So as long as we just identify the two keywords and leave it to the communication protocol (or whatever other routine wants to use it) to tell about interdependencies, fine. If we add the two keys, this must be clear in the comment. Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010329/d808fdcf/attachment.html From mike at easysw.com Thu Mar 29 16:31:08 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values References: <001a01c0b88f$77a2dc90$500714ac@NSCHADEW1> Message-ID: <3AC3A99C.765308BB@easysw.com> Norbert Schade wrote: > ... > This would indicate that these two values are valid for all input > trays, which normally is wrong. These are input tray specific > values. I know that they can be affected by some other setting as > well like a duplexer. These conditions are certainly out of scope > of the global media list. That is correct, but I think we can add a fourth "rule" for the spec, which will apply to *all* attributes (remember, there are plenty of printers that can't print on cardstock from particular trays, too, so it ain't just an issue for custom sizes... :) I think this will be appropriate for the "scope" section; it should mention that the media spec just defines the values, not what will be supported for a particular combination, and that the underlying protocols must handle this mess themselves (e.g. IPP uses the media collection stuff or validate-job to determine the valid combinations of values...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From markv at us.ibm.com Fri Mar 30 10:44:11 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Fri Mar 30 12:42:00 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values References: Message-ID: <002301c0b940$b9896a50$500714ac@NSCHADEW1> Mark, I know where you are coming from. But in this case I disagree with you. I think it's the job of the global media spec to provide lists of keywords for size, type, coating (if media source would be added, I'd be the first to take it over in UPDF). Any semantic level, where keywords are combined to information about a device status, is the task of a communication protocol like IPP (or even a MIB), a device description like UPDF or a driver. So I'd expect IPP to tell me that there is a media present with four attributes 'Letter,Stationary,Glossy,ManualTray' and two other media with other attribute parameters. In UPDF we want to provide a chance to declare these four attributes a unit. And the driver hopefully has some functionality to create an appropriate UI for that. This would result in the required behavior of the whole environment. The two keywords for min/max custom sizes may as well come as attributes of media sources or duplex settings or any other section within the communication protocol. It's only about relying on a certain syntax on keywords. If the communication protocol or the UPDF use it wrong in their context, then that's there fault. Regards Norbert Schade ----- Original Message ----- From: "Mark VanderWiele" To: "Norbert Schade" Cc: "UPD group" ; "IPP Group" ; "Pete Zannucci" ; "Mark_Hamzy/Austin/IBM%IBMUS" Sent: Friday, March 30, 2001 10:44 AM Subject: Re: UPD> Re: IPP> min/max custom size values > Careful, we may be making the same mistake we made in IPP where the form > size, media type, and tray are returned separately causing user interface > nightmare since all three of these really must be selected together and > represent the actual configuration of the printer. Therefore, I would > propose that when we have settled in on a syntax for the form size, media > type, and tray we go one step further and define a way to join the fields > so that the proper constraints can be represented. Perhaps a simple "+" > character. Again, form size by itself is meaningless. > > Regards, > Mark VanderWiele > IBM, Linux Tecnology Center > 512-838-4779, t/l 678-4779 > MARKV@IBMUS > email: markv@us.ibm.com > > From RonBergman at aol.com Fri Mar 30 20:58:29 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <84.138f0ddf.27f693be@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Date: Fri, 30 Mar 2001 16:53:03 -0800 Size: 4718 Url: http://www.pwg.org/archives/upd/attachments/20010330/4ef44e52/attachment.mht From sommer at granitesystems.com Mon Apr 2 09:48:04 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:52 2009 Subject: UPD> open standard for locales In-Reply-To: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010402093510.00963290@mailbox.bellatlantic.net> Here's a list of locales that use the ISO language and country codes. I know it's not all encompassing since I don't what countries speak some of the languages. However, it's a good start and people should post any missing entries. I have the list sorted by code. It's not necessarily an obvious sort for English but it's probably the best to use since nothing is going to be good for everyone. Jim -------------------------------------- code - language - country afZA - Afrikaans - South Africa arAE - Arabic - United Arab Emirates arBH - Arabic - Bahrain arDZ - Arabic - Algeria arEG - Arabic - Egypt arIQ - Arabic - Iraq arJO - Arabic - Jordan arLY - Arabic - Libya arMA - Arabic - Morocco arOM - Arabic - Oman arLB - Arabic - Lebanon arKW - Arabic - Kuwait arQA - Arabic - Qatar arSA - Arabic - Saudi Arabia arSY - Arabic - Syria arTN - Arabic - Tunisia arYE - Arabic - Yemen asIN - Assamese - India azAZ - Azerbaijani - Azerbaijan beBY - Byelorussian - Belarus bgBG - Bulgarian - Bulgaria bnIN - Bengali - India caES - Catalan - Spain csCZ - Czech - Czech Republic daDK - Danish - Denmark deAT - German - Austria deCH - German - Switzerland deDE - German - Germany deLI - German - Liechtenstein deLU - German - Luxembourg dzBT - Bhutani - Bhutan elGR - Greek - Greece enAU - English - Australia enBB - English - Barbados enBM - English - Bermuda enBZ - English - Belize enCA - English - Canada enGS - English - Bahamas enIE - English - Ireland enJM - English - Jamaica enNZ - English - New Zealand enPH - English - Philippines enUK - English - United Kingdom enUS - English - United States enZA - English - South Africa enTT - English - Trinidad and Tabago enVG - English - US Virgin Islands enVI - English - British Virgin Islands enZW - English - Zimbabwe esAR - Spanish - Argentina esBO - Spanish - Bolivia esCL - Spanish - Chile esCO - Spanish - Colombia esCR - Spanish - Costa Rica esCU - Spanish - Cuba esEC - Spanish - Ecuador esES - Spanish - Spain esDO - Spanish - Dominican Republic esGT - Spanish - Guatemala esHM - Spanish - Honduras esMX - Spanish - Mexico esNI - Spanish - Nicaragua esPA - Spanish - Panama esPE - Spanish - Peru esPR - Spanish - Puerto Rico esPY - Spanish - Paraguay esSV - Spanish - El Salvador esUY - Spanish - Uruguay esVE - Spanish - Venezuela etEE - Estonian - Estonia euES - Basque - Spain faIR - Farsi - Iran fiFI - Finnish - Finland foFO - Faeroese - Faeroe Islands frBE - French - Belgium frCA - French - Canada frCH - French - Switzerland frLU - French - Luxembourg frMC - French - Monaco frFR - French - France gaIE - Irish - Ireland guIN - Gujarati - India heIL - Hebrew - Israel hiIN - Hindi - India hrHR - Croatian - Croatia huHU - Hungarian - Hungary hyAM - Armenian - Armenia idID - Indonesian - Indonesia inID - Indonesian - Indonesia isIS - Icelandic - Iceland itCH - Italian - Switzerland itIT - Italian - Italy iwIL - Hebrew - Israel jaJP - Japanese - Japan jiIL - Yiddish - Isreal kaGE - Georgian - Georgia kkKZ - Kazahk - Kazahkstan klGL - Greenlandic - Greenland kmKH - Cambodian - Cambodia knIN - Kannada - India koKP - Korean - Democratic People's Republic of Korea koKR - Korean - Republic of Korea ksIN - Kashmiri - India kuIQ - Kurdish - Iraq loLA - Laothain - Laos ltLT - Lithuanian - Lithuania lvLV - Latvian - Latvia mkMK - Macedonian - Former Yugoslav Republic of Macedonia mlIN - Malayalam - India mnMN - Mongolian - Mongolia moMD - Moldavian - Moldava mrIN - Marathi - India msBN - Malay - Brunei Darussalam msMY - Malay - Malaysia mtMT - Maltese - Malta myMM - Burmese - Myanmar neNP - Nepali - Nepal nlBE - Dutch - Belgium nlNL - Dutch - Netherlands noNO - Norwegian - Norway orIN - Oriya - India paIN - Punjabi - India plPL - Polish - Poland ptBR - Portuguese - Brazil ptPT - Portuguese - Portugal roRO - Romanian - Romania ruRU - Russian - Russia saIN - Sanskrit - India skSK - Slovak - Slovakia slSL - Slovene - Slovenia smWS - Samoan - Samoa soSO - Somali - Somalia sqAL - Albanian - Albania suSD - Sudanese - Sudan svFI - Swedish - Finland svSE - Swedish - Sweden swKE - Swahili - Kenya taIN - Tamil - India teIN - Telugu - India thTH - Thai - Thailand trTR - Turkish - Turkey ukUA - Ukrainian - Ukraine urIN - Uru - India urPK - Urdu - Pakistan uzUZ - Uzbek - Uzbekistan viVN - Vietnamese - Viet Nam yiIL - Yiddish - Isreal zhCN - Chinese - China zhHK - Chinese - Hong Kong zhMO - Chinese - Macau zhSG - Chinese - Singapore zhTW - Chinese - Taiwan -------------------------------------- From RonBergman at aol.com Mon Apr 2 12:01:44 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Fwd: Media Names, case sensitivity Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: Media Names, case sensitivity Date: Mon, 2 Apr 2001 08:57:08 -0700 Size: 1936 Url: http://www.pwg.org/archives/upd/attachments/20010402/9ff54fea/attachment.mht From norbertschade at mediaone.net Mon Apr 2 18:16:05 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:52 2009 Subject: UPD> new locale list Message-ID: <003901c0bbc2$832407c0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 1810 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale-enUS-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 870 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1803 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale-deDE-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 9158 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFEntities.obj From hastings at cp10.es.xerox.com Mon Apr 2 19:51:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCA4@x-crt-es-ms1.cp10.es.xerox.com> Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. Ron From don at lexmark.com Mon Apr 2 20:23:03 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <200104030906.FAA04419@interlock2.lexmark.com> Ron, et al: We don't need to wait until last call to assign a number. Cindy: Could you assign 5100.5 to this project: "Media Standardized Names"? ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** RonBergman%aol.com@interlock.lexmark.com on 03/30/2001 08:58:29 PM To: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Return-Path: Received: from rly-zc03.mx.aol.com (rly-zc03.mail.aol.com [172.31.33.3]) by air-zc03.mail.aol.com (v77_r1.36) with ESMTP; Fri, 30 Mar 2001 19:49:48 -0500 Received: from triton.hitachi-hkis.com (mailport.dpc.com [192.101.159.107]) by rly-zc03.mx.aol.com (v77_r1.36) with ESMTP; Fri, 30 Mar 2001 19:49:17 -0500 Received: by triton.hitachi-hkis.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 16:53:12 -0800 Message-ID: <3BC1BD0C7E6DD411A13200508BDCC83D27BE70@triton.hitachi-hkis.com> From: "Bergman, Ron" To: "'Hastings, Tom N'" , "Bergman, Ron" , RonBergman@aol.com Cc: pwg@pwg.org, ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Date: Fri, 30 Mar 2001 16:53:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Thanks Tom! I believe I have all the other changes included and I plan to do a final check this weekend. So I'll hold off until these arrive so we can have a close to final draft next week. Regarding an ISTO-PWG assigned number, Don told me we have to wait until Working Group last call before it can be assigned. If we start the last call next week the earliest we would have a number is May 2nd. Why again must the UpNP have a number before the next meeting? Ron Here is the response from Don. >> >> Ron: >> >> We can assign this a number any time but.... >> >> 1) Since this is an output of the IPP working group, it needs a 2 week working >> group last call, then... >> >> 2) A PWG membership vote (another 2 weeks) >> >> 3) Then it will be posted to the PWG standards page probably as >> ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.5.pdf >> >> ********************************************** >> * Don Wright don@lexmark.com * >> * Chair, Printer Working Group * >> * Chair, IEEE MSC * -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 30, 2001 4:06 PM To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From don at lexmark.com Mon Apr 2 20:02:18 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> Fwd: Media Names, case sensitivity Message-ID: <200104030907.FAA04443@interlock2.lexmark.com> All: I prefer we go with case insensitive names. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** RonBergman%aol.com@interlock.lexmark.com on 04/02/2001 12:01:44 PM To: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: IPP> Fwd: Media Names, case sensitivity Return-Path: Received: from rly-xb04.mx.aol.com (rly-xb04.mail.aol.com [172.20.105.105]) by air-xb02.mail.aol.com (v77_r1.36) with ESMTP; Mon, 02 Apr 2001 11:53:31 -0500 Received: from triton.hitachi-hkis.com (mailport.dpc.com [192.101.159.107]) by rly-xb04.mx.aol.com (v77_r1.36) with ESMTP; Mon, 02 Apr 2001 11:53:11 2000 Received: by triton.hitachi-hkis.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 08:57:09 -0700 Message-ID: <3BC1BD0C7E6DD411A13200508BDCC83D27BE71@triton.hitachi-hkis.com> From: "Bergman, Ron" To: "Tom Hastings (E-mail)" Cc: "'ipp@pwg.org'" , "'upd@pwg.org'" , "'RonBergman@aol.com'" Subject: Media Names, case sensitivity Date: Mon, 2 Apr 2001 08:57:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. Just stating the names are not case sensitive, puts the burden on the client. But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. Ron From harryl at us.ibm.com Tue Apr 3 10:31:46 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> RE: Media Names, case sensitivity Message-ID: I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/02/2001 05:51 PM To: "Bergman, Ron" cc: "'ipp@pwg.org'" , "'upd@pwg.org'" , "'RonBergman@aol.com'" , "pmp (E-mail)" Subject: IPP> RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. Ron From RonBergman at aol.com Tue Apr 3 11:53:37 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Fwd: FW: IPP> RE: Media Names, case sensitivity Message-ID: <93.91e03df.27fb4bfa@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 08:29:37 -0700 Size: 6505 Url: http://www.pwg.org/archives/upd/attachments/20010403/71a95b8c/attachment.mht From hastings at cp10.es.xerox.com Tue Apr 3 15:30:22 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCDD@x-crt-es-ms1.cp10.es.xerox.com> Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 15:34:04 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCE0@x-crt-es-ms1.cp10.es.xerox.com> Michael wrote: Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? I think that we should just define the names and leave the attribute naming up to the print protocol folks. We should indicate that these names can apply to either or both sides of a medium. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Wednesday, March 28, 2001 19:21 To: Hastings, Tom N Cc: Bergman, Ron; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Hastings, Tom N" wrote: > ... > So I think we should not introduce the notion of roll media and > stick with roll media being out of scope. I personally disagree with this decision, especially since there *are* consumer inkjets today (and for the past several years, in fact) that support roll (sometimes called "banner") media of more-or-less arbitrary length. I understand that some things about roll media may be out of scope (cutting, marking, etc.), but to ignore roll media entirely will make this specification useless. I merely propose that the following media type be added to the current specification: 'roll' - A continuous roll of media whose limits are described by the custom-min and custom-max sizes. Again, it is *extremely* important that we support roll media types because they are available for many consumer inkjets as well as high-end devices. Most of these devices *do* need to know that you want to use roll fed media, and if no keyword is defined for it then you'll end up with a different name for each implementation. I agree, however, that things like cutter control and marking the page area on the media are beyond the scope of this specification, so any mention of roll media should be limited to the media type and not any of the other issues. > ... > So I would not oppose adding MediaCoating to the Media standard, > what do others think? Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? > ... > Translating the UPnP syntax to our ABNF would become: > > custom-media-size-max-self-describing-name = > [prefix] "custom-max" "." short-dim "-" long-dim > > custom-media-size-min-self-describing-name = > [prefix] "custom-min" "." short-dim "-" long-dim Yes, this will work perfectly well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From harryl at us.ibm.com Tue Apr 3 16:37:05 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 16:50:19 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCF4@x-crt-es-ms1.cp10.es.xerox.com> I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From harryl at us.ibm.com Tue Apr 3 17:04:49 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From hastings at cp10.es.xerox.com Tue Apr 3 17:23:25 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCFC@x-crt-es-ms1.cp10.es.xerox.com> Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 18:34:38 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD11@x-crt-es-ms1.cp10.es.xerox.com> So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From hastings at cp10.es.xerox.com Tue Apr 3 18:53:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD16@x-crt-es-ms1.cp10.es.xerox.com> Minor terminology issue, since we seem to be agreeing to all lower case for our names: Are we really defining "keywords", rather than "names", in this media standard? Keywords are usually for program to program communication as intended by our media standard and are usually all lower case and can use case sensitive matching for simple interoperability and efficiency. On the other hand, names, are usually mixed case and need case insensitive matching and are more intended for direct human input or output. This distinction is exactly what IPP means by the 'keyword' versus 'name' attribute syntax (data type). IPP 'keywords' are all lowers case and the standard defines many keywords. IPP 'names' are mixed case and the IPP standard defines no standard names. Would it help the understanding of our Media standard to change the terminology by changing "Name" to "Keyword" throughout the standard, i.e., the standard defines Media Type Keywords, Media Color Keywords, and Media Size Self Describing Keywords, instead of Media Type Names, Media Color Names, Media Size Self Describing Names. Note: that if we agree to Harry's and Mark's proposal to define a concatenated syntax of our keywords, then we would be defining Media Keywords which could be used directly by the IPP "media" (keyword | name) Job Template attribute as keyword values. So the 'stationery.na-letter.8500-11000.white' keyword could be used by IPP "media" Job Template attribute. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, April 03, 2001 15:35 To: Bergman, Ron; 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From RonBergman at aol.com Tue Apr 3 19:43:58 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From RonBergman at aol.com Tue Apr 3 19:50:26 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <42.12f7c934.27fbbbc3@aol.com> Tom, I am not sure we need to make the distinction here. If we strongly suggest all lower case then most of the difference is covered. Keywords may not be a universal term. Or the usage of the "media names" may vary with the referencing standard. Unless there is a very strong support for keyword, I propose we stick with name. Ron In a message dated Tue, 3 Apr 2001 6:53:56 PM Eastern Daylight Time, "Hastings, Tom N" writes: << Minor terminology issue, since we seem to be agreeing to all lower case for our names: Are we really defining "keywords", rather than "names", in this media standard? Keywords are usually for program to program communication as intended by our media standard and are usually all lower case and can use case sensitive matching for simple interoperability and efficiency. On the other hand, names, are usually mixed case and need case insensitive matching and are more intended for direct human input or output. This distinction is exactly what IPP means by the 'keyword' versus 'name' attribute syntax (data type). IPP 'keywords' are all lowers case and the standard defines many keywords. IPP 'names' are mixed case and the IPP standard defines no standard names. Would it help the understanding of our Media standard to change the terminology by changing "Name" to "Keyword" throughout the standard, i.e., the standard defines Media Type Keywords, Media Color Keywords, and Media Size Self Describing Keywords, instead of Media Type Names, Media Color Names, Media Size Self Describing Names. Note: that if we agree to Harry's and Mark's proposal to define a concatenated syntax of our keywords, then we would be defining Media Keywords which could be used directly by the IPP "media" (keyword | name) Job Template attribute as keyword values. So the 'stationery.na-letter.8500-11000.white' keyword could be used by IPP "media" Job Template attribute. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, April 03, 2001 15:35 To: Bergman, Ron; 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From hastings at cp10.es.xerox.com Tue Apr 3 20:05:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD1F@x-crt-es-ms1.cp10.es.xerox.com> I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From RonBergman at aol.com Tue Apr 3 20:31:06 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: UPD> Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: <73.c6b0934.27fbc543@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 17:08:26 -0700 Size: 14086 Url: http://www.pwg.org/archives/upd/attachments/20010403/75d40bf3/attachment.mht From RonBergman at aol.com Tue Apr 3 20:31:52 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:52 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <99.12f6b739.27fbc578@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Tue, 3 Apr 2001 17:31:11 -0700 Size: 7631 Url: http://www.pwg.org/archives/upd/attachments/20010403/242e0e8e/attachment.mht From hastings at cp10.es.xerox.com Tue Apr 3 20:37:35 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD25@x-crt-es-ms1.cp10.es.xerox.com> Looks good to me. One question: did you mean to say "case sensitive rules" or "case insensitive rules". If a referencing standard sticks with all lower case as we strongly recommend, then it can get away with the simpler case sensitive rules, right? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:08 To: 'RonBergman@aol.com'; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, Here is my proposal: "Media Names defined in this specification are presented using lower case characters. Other referencing standards may impose case sensitive rules if necessary. For interoperability and implementation efficiency, this standard strongly recommends these names be used in the lower case form defined in this document." Ron -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, April 03, 2001 4:44 PM To: ron.bergman@hitachi-hkis.com; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From hastings at cp10.es.xerox.com Tue Apr 3 20:50:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:52 2009 Subject: UPD> Re: min and max size and the creeping scope of the media standard [new subject] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD26@x-crt-es-ms1.cp10.es.xerox.com> Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:05 PM To: Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Tue Apr 3 22:13:20 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> RE: min and max size and the creeping scope of the media standard [all-in-one names] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD28@x-crt-es-ms1.cp10.es.xerox.com> Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:05 PM To: Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From harryl at us.ibm.com Wed Apr 4 10:47:12 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: Looks good. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- RonBergman@aol.com Sent by: owner-ipp@pwg.org 04/03/2001 06:31 PM To: , , cc: Subject: Fwd: RE: IPP> RE: Media Names, case sensitivity ----- Message from "Bergman, Ron" on Tue, 3 Apr 2001 17:08:26 -0700 ----- To: "'RonBergman@aol.com'" , harryl@us.ibm.com, hastings@cp10.es.xerox.com cc: ipp@pwg.org, owner-ipp@pwg.org, pmp@pwg.org, upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, Here is my proposal: "Media Names defined in this specification are presented using lower case characters. Other referencing standards may impose case sensitive rules if necessary. For interoperability and implementation efficiency, this standard strongly recommends these names be used in the lower case form defined in this document." Ron -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, April 03, 2001 4:44 PM To: ron.bergman@hitachi-hkis.com; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From RonBergman at aol.com Wed Apr 4 11:13:53 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: <32.12ee56dd.27fc9431@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 17:59:03 -0700 Size: 15282 Url: http://www.pwg.org/archives/upd/attachments/20010404/1d161266/attachment.mht From RonBergman at aol.com Wed Apr 4 11:14:37 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fwd: RE: min and max size and the creeping scope of the media standard [new subject] Message-ID: <99.12f8835c.27fc945d@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: min and max size and the creeping scope of the media standard [new subject] Date: Tue, 3 Apr 2001 18:38:31 -0700 Size: 9864 Url: http://www.pwg.org/archives/upd/attachments/20010404/d7a5d5f6/attachment.mht From RonBergman at aol.com Wed Apr 4 11:15:19 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fwd: RE: min and max size and the creeping scope of the media standard [all-in-one names] Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Date: Wed, 4 Apr 2001 08:01:47 -0700 Size: 12770 Url: http://www.pwg.org/archives/upd/attachments/20010404/368ac241/attachment.mht From kugler at us.ibm.com Wed Apr 4 11:35:48 2001 From: kugler at us.ibm.com (Carl Kugler) Date: Wed May 6 14:04:53 2009 Subject: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: I'm a little concerned about overloading the term Media Type for envelop, different kinds of paper, etc., since we already use that in document-format values (e.g., text/plain, application/postscript, etc.). -Carl From hastings at cp10.es.xerox.com Wed Apr 4 16:58:18 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Dr aft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD6E@x-crt-es-ms1.cp10.es.xerox.com> Yes, there is a potential for confusion between the term Media Type in our Media Name standard and MIME Media Types, but... The term "media" to mean something to write on has been around a lot longer than the IETF and MIME, so I think the best approach to avoid the obvious confusion is to put the adjective MIME in front of media when we are talking about document-format values and use the term "media type", i.e., MIME Media Type to distinguish it from Media Type (stationery, transparency, etc.), OK? Also the attribute "media-type" is a member attribute of the "media-col" attribute in the approved PWG IEEE-ISTO Production Printing Extension. Also the attribute MediaType is a parameter in the almost approved UPnP BasicPrint Template. Here is the current text in IPP RFC 2911 about the subject (which I think avoids any confusion): 4.1.9 'mimeMediaType' The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and registered according to the procedures of RFC 2048 [RFC2048] for identifying a document format. The value MAY include a charset, or other, parameter, depending on the specification of the Media Type in the IANA Registry [IANA-MT]. Although most other IPP syntax types allow for only lower-cased values, this syntax type allows for mixed-case values which are case-insensitive. "document-format" (mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. The value of this attribute identifies the format of the supplied document data. The following cases exist: 4.4.21 document-format-default (mimeMediaType) This REQUIRED Printer attribute identifies the document format that the Printer object has been configured to assume if the client does not supply a "document-format" operation attribute in any of the operation requests that supply document data. The standard values for this attribute are Internet Media types (sometimes called MIME types). For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9. Bottom line: I don't think we should change our Media Type terminology in our Media Names Standard. Tom -----Original Message----- From: Carl Kugler [mailto:kugler@us.ibm.com] Sent: Wednesday, April 04, 2001 08:36 Cc: ipp@pwg.org; upd@pwg.org; pwg@pwg.org Subject: Re: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I'm a little concerned about overloading the term Media Type for envelop, different kinds of paper, etc., since we already use that in document-format values (e.g., text/plain, application/postscript, etc.). -Carl From hastings at cp10.es.xerox.com Wed Apr 4 18:38:30 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD7C@x-crt-es-ms1.cp10.es.xerox.com> Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Wed Apr 4 20:37:24 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> Suggested Appendix for Media Names Standard for existing standard s Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD8F@x-crt-es-ms1.cp10.es.xerox.com> I've drafted and attached an MS-WORD short Appendix B for the Media Names standard to indicate the existing standards that are intended to make use of this standard, namely the Printer MIB, IPP/1.0 and IPP/1.1, and the PWG IEEE-ISTO 5100.3 IPP Production Printing Attributes - Set1. I've indicated which objects and attributes in these standards are intended to use which names in the Media Name standard. I assume that standards that have not yet been published, such as the UPnP BasicPrint Template, should reference the PWG Media Names standard directly before being published, so we don't need to do that in our Media Names standard, OK? So I did not include mention of the UPnP BasicPrint Template in the proposed Appendix. This proposal also assumes that we add an Appendix A before it that defines some way to do All In One Media Names, which I reference in the tables. I would have made a flat text version, but I did it as tables to keep it short and easy to use. Comments? Tom <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Appendix B-referenced-stds-as-tables.doc Type: application/msword Size: 38912 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010404/c00c3029/AppendixB-referenced-stds-as-tables.doc From don at lexmark.com Thu Apr 5 03:18:59 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <200104050721.DAA24965@interlock2.lexmark.com> All: I too am violently opposed to this addition to what STARTED as a nice, simple, short standard that accomplished a lot. I would hate to see this grow and grow and grow until we can specify: toilet-tissue.na-4x4.4000-4000.white.extra-soft.two-ply.lubricated PLEASE STOP!! Write another INFORMATIONAL document if you want to do this. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From markv at us.ibm.com Thu Apr 5 09:58:15 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:53 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From harryl at us.ibm.com Thu Apr 5 10:53:12 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: IPP> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: I don't know, Don... that's pretty descriptive and easy to understand and parse, to me! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-ipp@pwg.org 04/05/2001 01:18 AM To: ipp@pwg.org, upd@pwg.org cc: Subject: IPP> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard All: I too am violently opposed to this addition to what STARTED as a nice, simple, short standard that accomplished a lot. I would hate to see this grow and grow and grow until we can specify: toilet-tissue.na-4x4.4000-4000.white.extra-soft.two-ply.lubricated PLEASE STOP!! Write another INFORMATIONAL document if you want to do this. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Thu Apr 5 13:58:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FDC2@x-crt-es-ms1.cp10.es.xerox.com> Mark, I agree that you need all of the information together that an implementation supports for a sensible selection by the user. The problem is: Can we agree on what the information is, or does it vary so much from implementation to implementation, that we can only hope to agree to a core set and leave the rest to implementation? Unfortunately, leaving very much to implementation, means that a client is unlikely to be able to work with implementations from different vendors, especially if the client has to localize the fields for the user. So, what is your favorite list of media characteristics with values that you'd like to see in a standard? Is there a small subset that we can agree to now and work on additional fields in a separate standard that augments what we can agree to for the Media Names standard now? Don, I was think out loud about different ways that we could try to put all of the fields in the All In One Name Appendix. I agree with you that we should put into the Media Names Appendix only what we can agree to now and work on augmenting that in a future standard when we have more time. So lets not put anything into the current Appendix that we might regret in the future document. OK? Thanks, Tom P.S. Plug for the IEEE-ISTO 5100.3 IPP Production Printing Attributes - Set1 standard. It allows the user to select from 12 media fields using the "media-col" (collection) Job Template attribute. See http://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf, .doc, .rtf. -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Thursday, April 05, 2001 06:58 To: don@lexmark.com Cc: ipp@pwg.org; upd@pwg.org Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Thu Apr 5 19:48:11 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FDF3@x-crt-es-ms1.cp10.es.xerox.com> Ron, A number of us considered your proposal to add: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted to the Media Type Names. We think that would be a mistake. Draft D0.5 has the Media Type Names as: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock and we've agreed to add 'roll' and drop 'other' However, we think it would be a mistake to add the 5 values that you proposed, even though it seems simple. The reason for not adding them is that they are more orthogonal to Media Type, i.e., they apply to more than one type value: 'bond' can apply to stationery, envelope, envelope-plain, envelope-window 'recycled' can apply to stationery, envelope, envelope-plain, envelope-window, perhaps the 3 continuous values, the 3 tab values, cardstock, and roll. 'punched' can apply to stationery, tab-stock, pre-cut-tabs, full-cut-tabs, photographic. 'letterhead' can apply to stationery, envelope, envelope-plain, envelope-window. 'pre-printed' can apply to stationery, envelope, envelope-plain, envelope-window. We think that the better way to add these quasi orthogonal fields is as separate, optional fields set off by ".". So for our All In One Name, any of these values can be appended as fields. But if the media doesn't have the characteristic it doesn't have the field and doesn't have the ".". So the following are possible additional fields: bond recycled pre-punched letterhead or pre-printed They can be used in principle with any of the fields we have already defined. I'll send out a complete proposal later today. It is really simple, compared to the thoughts that I sent out yesterday that has gotten the negative reaction. Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 18:29 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Fri Apr 6 06:08:18 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE0B@x-crt-es-ms1.cp10.es.xerox.com> Ron, Minor issue: which wins if dimensions are correct for the media size name? For example, for the Media Size Self-Describing Name is iso-a4.100-200, is the size ISO A4 or 10 by 20 mm? I suggest that the dimensions take precedence over the name. So we need to add such a statement in the document. Comments? Tom From RonBergman at aol.com Fri Apr 6 16:20:31 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fwd: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <4a.13f299d0.27ff7f0f@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Date: Fri, 6 Apr 2001 11:12:43 -0700 Size: 24127 Url: http://www.pwg.org/archives/upd/attachments/20010406/48a620c6/attachment.mht From hastings at cp10.es.xerox.com Fri Apr 6 17:03:23 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> MED - Proposal for simple Media Self Describing Names (all in one names) Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE5B@x-crt-es-ms1.cp10.es.xerox.com> A number of us have looked at the problem posed by Harry and Mark to define a very simple "all-in-one" name syntax. This is our proposal. The entire proposal is three pages, plus examples, including listing the values that we currently have for Media Type and Media Color in the D0.5 draft. The attached .doc file is the MS-WORD version. We suggest that it could be a separate section or an Appendix in the Media Names Standard. Comments? Thanks, Tom and Bob Subj: Proposal for Simple Media Self Describing Names From: Tom Hastings, Bob Herriot File: simple-self-describing-names-010406.doc Date: 4/6/01 This paper proposes a very simple definition for Media Self Describing Names. It meets the objectives suggested by Harry and Mark for "all-in-one" names. We think that calling these names Media Self Describing Names will make the intent more clear. We suggest that Media Self Describing Names be added to the next draft, either as a new section or an Appendix, to go along side the D0.5 Draft Media Names which are: Media Size Self Describing Names, Media Type Names, and Media Color Names. Summary of Media Self Describing Names The central idea for the Media Self Describing Name is to provide a simple naming syntax that describes all of the salient characteristics of the media. Each salient characteristic is represented as a field separated by a "." character, starting with the Media Size Self Describing Name field. Each field, except for size, has a default value, which is the most commonly used value. To shorten the names and to follow existing media naming practice, the default value is never represented in the name. For example, the name: 'na-letter.8500-11000' represents white stationery, without holes, and not recycled, etc, and the name: 'na-personal.3625-6500.envelope.bond.blue' represents a blue bond personal envelope, not recycled, etc. This syntax is compatible with the IPP keyword syntax (all lower case, plus "." and "-") and can be used with the current IPP/1.1 client and Printer implementations of "media", "media-default", "media-ready", and "media-supported" attributes. A valid Media Self Describing Name MUST include the Media Size Self Describing Name (both Size Name and Dimensions fields as defined in the D0.5 Draft) followed by other fields which MUST be in the following order: Field Example Default Value ----- ------- ------------ 1 Media Size Self Describing Name na-letter.8500-11000 -- 2 Media Type Name envelope stationery 3 Media Stock Type Name bond plain 4 Media Color Name red white 5 Media Weight Name 80-gram unspecified 6 Media Hole Count Name holes-3 holes-0 7 Media Preprinted Name letterhead none 8 Media Recycled Name recycled none 9 Media Front Coating Name front-matte none 10 Media Back Coating Name back-glossy none 11 Media Order Count Name ordered-5 ordered-1 Any field whose value is the indicated default value MUST be omitted, including the "." separator character. Implementers MAY add additional fields. They MUST occur after the fields defined in this standard. Implementers MAY add additional field values to defined fields. Note that if a given field is not supported by an implementation, omitting that field is assumed to have the meaning as the default value. Thus this specification allows implementations to support whatever additional fields they want in addition to the REQUIRED Media Size Self Describing field. Thus there is no burden on implementations in defining the following additional fields in our Media Names standard. These definitions also provide a simple one-to-one mapping to the PWG IEEE-ISTO 5100.3 Production Printing Attributes - Set1 extension. Values for each field of Media Self Describing Names This section lists the values defined for each field of a Media Self Describing Name. The order presented is the same as is REQUIRED in the name when other than the default value is being represented. Media Size Self Describing Name (see D0.5 Draft): The ABNF for the Media Size Self Describing Name is: ["na-"] size_name "." short_dim "-" long_dim Media Type Name (see D0.5 Draft): stationery -- default transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock and we've agreed to add 'roll' and drop 'other' Media Stock Type Name: none -- default bond newsprint bristol Media Color Name (see D0.5 Draft): no-color -- ISSUE - get rid of this and clarify white to mean -- clear for transparency - white is the absence of -- color white -- default pink yellow blue green buff goldenrod red gray ivory orange Media Weight Name: unspecified -- default nnn-grams The default value is 'unspecified', meaning that leaving out the weight means that the weight is unspecified. Media Hole Count Name: holes-0 -- default holes-1 holes-2 holes-3 holes-4 holes-5 Media Preprinted Name: none -- default preprinted letterhead Media Recycled Name: none -- default recycled The Media Front Coating Name: none -- default front-glossy front-high-gloss front-semi-gloss front-satin front-matte The Media Back Coating Name: none -- default back-glossy back-high-gloss back-semi-gloss back-satin back-matte Media Order Count Name: ordered-1 -- default ordered-2 ordered-3 ordered-4 ordered-5 ordered-6 Examples na-letter.8500-11000 -- white stationery, no holes, etc. In other words, the size name by itself is the white stationery media, as in IPP na-personal.3625-6500.envelope -- white envelope, no holes, not recycled, etc. na-letter.8500-11000.transparency -- clear transparency (see issue above) na-3x5.3000-5000.photographic.front-matte -- white photographic front matte na-3x5.3000-5000.cardstock.blue -- blue 3x5 card stock na-letter.8500-11000.blue -- blue stationery, no holes, etc. na-letter.8500-11000.front-glossy -- white glossy on front side na-letter.8500-11000.front-glossy.back-glossy -- white glossy both sides na-letter.8500-11000.holes-3 -- three holed white stationery na-letter.8500-11000.envelope.blue -- blue envelope na-letter.8500-11000.recycled -- recycled white stationery na-letter.8500-11000.envelope.blue.recycled -- recycled blue envelope na-letter.8500-11000.bond -- white bond stationery, no holes, etc. na-letter.8500-11000.envelope.bond -- white bond envelope, etc. na-letter.8500-11000.letterhead.bond -- white bond letterhead, etc. na-letter.8500-11000.80-gram -- 80 grams per square meter white stationery. All of the examples above this one are of an unspecified weight, while this one is 80 grams per square meter weight. <> -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-self-desccribing-names-010406.doc Type: application/msword Size: 50176 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010406/72b0e57c/simple-self-desccribing-names-010406.doc From hastings at cp10.es.xerox.com Fri Apr 6 18:00:28 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE6A@x-crt-es-ms1.cp10.es.xerox.com> I just got off the phone with Shivaun and the plan is still for the UPnP BasicPrint Template to use the syntax for Media Size Self Describing Names from the PWG Media Names standard and reference it for the list of values. As a formality, the UPnP IMAGING WG will vote on the change at the Portland meeting, April 23-24. The hope is that the Portland meeting makes the final changes to the BasicPrint Template, based on the plug fest experience, what various venders actually support, and the PWG Media Names standard. Therefore, I think that we should put the "all-in-one" proposal in a separate PWG document, so that the UPnP BasicPrint Template has a stable document to reference. I'd be glad to continue the discussion about the "all-in-one" document in Portland, as well as finish the Media Names Standard. Ok? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 14:16 To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, I will be able to attend the Portland meeting (UPnP, PWG, and IPP FAX), so I'll volunteer to lead the discussion and collaborate with Ron after the meeting. I agree that the "all-in-one" is the real open issue and whether it should be included in the current document or made a separate document. I think it depends on the schedule from the UPnP group and whether or not they are going to use our format. If they need something stable and approved before we can agree on the "all-in-one" naming, then we should make the all in one a separate document. About the appendix to indicate which objects and attributes of existing standards are intended to use which Names in our standard, I think it is very important to include it in the Media Names standard. So I disagree about not including it. Otherwise, it will be very difficult for implementers to know which Names we intend as extensions to which objects and attributes in these existing standards (RFC 1759, IPP, and ISTO-IEEE 5100.3). Think about the implementers that aren't even on our mailing lists.... Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:58 To: 'Manros, Carl-Uno B'; Hastings, Tom N; Bergman, Ron; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, I agree with Carl-Uno's suggestion for extending the time to finish this document. Unfortunately I cannot attend the next meeting. So we will need a volunteer to lead the discussion and capture the results. I believe that the only real open issues concern the "all-in-one" format and if it should be included in this document or as a separate standard. There is also Tom's proposal for another appendix that specifies how existing standards are to use the Media standard. I have not seen any comment on this so I assume that no one cares either positively or negatively. I personally don't believe that this is necessary and should not be included. Any one disagree? Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:42 AM To: Hastings, Tom N; 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, As a last minute comment I would like to suggest extending the time to finish this document to span the next PWG meeting. It seems to me that there is still too much discussion and too many lose ends to close and publish this document quite yet... Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:14 AM To: 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, Unfortunately, I checked the wrong delivery service on the web site when I ordered the ASME Y14.1M a week ago Friday and it is being delivered by truck from New Jersey to LA and won't arrive until next Tuesday or Wednesday. The guy who I could get the numbers over the phone when home early today, so we're out of luck. I'm on vacation next week. So maybe we add these sizes later, perhaps as a corrigendum or during last call. Tom -----Original Message----- From: Hastings, Tom N Sent: Friday, March 30, 2001 16:06 To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Fri Apr 6 22:30:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE89@x-crt-es-ms1.cp10.es.xerox.com> Ron, I think you are right. There is no need for the Media Name Standard to say anything about what an implementation should do if the Media Size Name (e.g., na-letter), has dimensions that don't agree with the standard. So ignore my suggestion. Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:09 To: 'Hastings, Tom N'; ipp (E-mail) Cc: UPDF WG (E-mail) Subject: RE: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Tom, I am not sure why this is an issue. If we have defined a name in the specification with this mismatch, it must be corrected. If a name mismatch occurs in a custom name, it is up to the person that creates the custom name to ensure it is what he wanted. If you are referring to a corrupted name, then it is up to the receiver to determine the appropriate action, which should be specified by the protocol (UPnP, IPP, etc). If the device does not have a sizes table to compare, then all it can do is accept the size. If it can validate, then it should reject. I don't agree a statement is needed in the PWG Media specification for this case. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 3:08 AM To: ipp (E-mail) Cc: UPDF WG (E-mail) Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Ron, Minor issue: which wins if dimensions are correct for the media size name? For example, for the Media Size Self-Describing Name is iso-a4.100-200, is the size ISO A4 or 10 by 20 mm? I suggest that the dimensions take precedence over the name. So we need to add such a statement in the document. Comments? Tom From hastings at cp10.es.xerox.com Fri Apr 6 22:34:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE8A@x-crt-es-ms1.cp10.es.xerox.com> I don't know an exact date, but my sense is that the group wants to be finished with the UPnP BasicPrint Template at the Portland meeting. I left a message with Shivaun and did not get a reply. She is on vacation next week and will be back in the office, Monday April 16. I'm also taking a vacation next week and will be back in the office on Monday April 16. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 15:45 To: 'Hastings, Tom N'; Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org'; UPDF WG (E-mail) Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, Do you know when UPnP requires a "published" standard? Or do they just need the number to reference? I don't know why, if we ever agree on the "all-in-one", that it cannot be an appendix to the Media Standard. Just because UPnP doesn't require it, they do not have to ue everything in the standard. If we must publish the document soon, it could be a corrigendum (I must look up that word!) and then added when the Media spec is re-published (as a -2002). Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 3:00 PM To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org'; UPDF WG (E-mail) Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just got off the phone with Shivaun and the plan is still for the UPnP BasicPrint Template to use the syntax for Media Size Self Describing Names from the PWG Media Names standard and reference it for the list of values. As a formality, the UPnP IMAGING WG will vote on the change at the Portland meeting, April 23-24. The hope is that the Portland meeting makes the final changes to the BasicPrint Template, based on the plug fest experience, what various venders actually support, and the PWG Media Names standard. Therefore, I think that we should put the "all-in-one" proposal in a separate PWG document, so that the UPnP BasicPrint Template has a stable document to reference. I'd be glad to continue the discussion about the "all-in-one" document in Portland, as well as finish the Media Names Standard. Ok? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 14:16 To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, I will be able to attend the Portland meeting (UPnP, PWG, and IPP FAX), so I'll volunteer to lead the discussion and collaborate with Ron after the meeting. I agree that the "all-in-one" is the real open issue and whether it should be included in the current document or made a separate document. I think it depends on the schedule from the UPnP group and whether or not they are going to use our format. If they need something stable and approved before we can agree on the "all-in-one" naming, then we should make the all in one a separate document. About the appendix to indicate which objects and attributes of existing standards are intended to use which Names in our standard, I think it is very important to include it in the Media Names standard. So I disagree about not including it. Otherwise, it will be very difficult for implementers to know which Names we intend as extensions to which objects and attributes in these existing standards (RFC 1759, IPP, and ISTO-IEEE 5100.3). Think about the implementers that aren't even on our mailing lists.... Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:58 To: 'Manros, Carl-Uno B'; Hastings, Tom N; Bergman, Ron; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, I agree with Carl-Uno's suggestion for extending the time to finish this document. Unfortunately I cannot attend the next meeting. So we will need a volunteer to lead the discussion and capture the results. I believe that the only real open issues concern the "all-in-one" format and if it should be included in this document or as a separate standard. There is also Tom's proposal for another appendix that specifies how existing standards are to use the Media standard. I have not seen any comment on this so I assume that no one cares either positively or negatively. I personally don't believe that this is necessary and should not be included. Any one disagree? Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:42 AM To: Hastings, Tom N; 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, As a last minute comment I would like to suggest extending the time to finish this document to span the next PWG meeting. It seems to me that there is still too much discussion and too many lose ends to close and publish this document quite yet... Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:14 AM To: 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, Unfortunately, I checked the wrong delivery service on the web site when I ordered the ASME Y14.1M a week ago Friday and it is being delivered by truck from New Jersey to LA and won't arrive until next Tuesday or Wednesday. The guy who I could get the numbers over the phone when home early today, so we're out of luck. I'm on vacation next week. So maybe we add these sizes later, perhaps as a corrigendum or during last call. Tom -----Original Message----- From: Hastings, Tom N Sent: Friday, March 30, 2001 16:06 To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From don at lexmark.com Mon Apr 9 12:44:08 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: <200104091713.NAA14862@interlock2.lexmark.com> Mark, et al: I have no problem with creating the combined name but I think this is better done in the end standard that uses these names in a combined form. There may be reasons that UPD wants a certain set of characteristics in its media names that differ from what IPP might want, or uPnP might want, etc. If this standard tries to be all things to all users then it will never be done. One of the major issues raised by the IETF with IPP was it was just too big to deal with. It is thought to be better to create a number of smaller standards that deal with a smaller set of issues and then use those smaller standards as building blocks. I think this is a perfect example where smaller and simpler is better. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Mark VanderWiele" on 04/05/2001 09:58:15 AM To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com cc: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From RonBergman at aol.com Mon Apr 9 16:26:06 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fwd: FW: Media Standardized Names, Version D0.6 is now available Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: Media Standardized Names, Version D0.6 is now available Date: Mon, 9 Apr 2001 08:02:14 -0700 Size: 1659 Url: http://www.pwg.org/archives/upd/attachments/20010409/c2775d00/attachment.mht From markv at us.ibm.com Mon Apr 9 20:22:45 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Missing Locales arAA (Arabic) enBE (Belgium) enGB (Great Britain) enIN (India) shSP (Serbian Latin) shYU (Serbian Latin - Yugoslavia) srSP (Serbian Cyrillic) srYU (Serbian Cyrillic - Yugoslavia) slSI (Slovene) (the last character is uppercase "i") Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on 04/03/2001 07:08 PM --------------------------- Jim Sommer @pwg.org on 04/02/2001 08:48:04 AM Sent by: owner-upd@pwg.org To: UPDF cc: Subject: Re: UPD> open standard for locales Here's a list of locales that use the ISO language and country codes. I know it's not all encompassing since I don't what countries speak some of the languages. However, it's a good start and people should post any missing entries. I have the list sorted by code. It's not necessarily an obvious sort for English but it's probably the best to use since nothing is going to be good for everyone. Jim -------------------------------------- code - language - country afZA - Afrikaans - South Africa arAE - Arabic - United Arab Emirates arBH - Arabic - Bahrain arDZ - Arabic - Algeria arEG - Arabic - Egypt arIQ - Arabic - Iraq arJO - Arabic - Jordan arLY - Arabic - Libya arMA - Arabic - Morocco arOM - Arabic - Oman arLB - Arabic - Lebanon arKW - Arabic - Kuwait arQA - Arabic - Qatar arSA - Arabic - Saudi Arabia arSY - Arabic - Syria arTN - Arabic - Tunisia arYE - Arabic - Yemen asIN - Assamese - India azAZ - Azerbaijani - Azerbaijan beBY - Byelorussian - Belarus bgBG - Bulgarian - Bulgaria bnIN - Bengali - India caES - Catalan - Spain csCZ - Czech - Czech Republic daDK - Danish - Denmark deAT - German - Austria deCH - German - Switzerland deDE - German - Germany deLI - German - Liechtenstein deLU - German - Luxembourg dzBT - Bhutani - Bhutan elGR - Greek - Greece enAU - English - Australia enBB - English - Barbados enBM - English - Bermuda enBZ - English - Belize enCA - English - Canada enGS - English - Bahamas enIE - English - Ireland enJM - English - Jamaica enNZ - English - New Zealand enPH - English - Philippines enUK - English - United Kingdom enUS - English - United States enZA - English - South Africa enTT - English - Trinidad and Tabago enVG - English - US Virgin Islands enVI - English - British Virgin Islands enZW - English - Zimbabwe esAR - Spanish - Argentina esBO - Spanish - Bolivia esCL - Spanish - Chile esCO - Spanish - Colombia esCR - Spanish - Costa Rica esCU - Spanish - Cuba esEC - Spanish - Ecuador esES - Spanish - Spain esDO - Spanish - Dominican Republic esGT - Spanish - Guatemala esHM - Spanish - Honduras esMX - Spanish - Mexico esNI - Spanish - Nicaragua esPA - Spanish - Panama esPE - Spanish - Peru esPR - Spanish - Puerto Rico esPY - Spanish - Paraguay esSV - Spanish - El Salvador esUY - Spanish - Uruguay esVE - Spanish - Venezuela etEE - Estonian - Estonia euES - Basque - Spain faIR - Farsi - Iran fiFI - Finnish - Finland foFO - Faeroese - Faeroe Islands frBE - French - Belgium frCA - French - Canada frCH - French - Switzerland frLU - French - Luxembourg frMC - French - Monaco frFR - French - France gaIE - Irish - Ireland guIN - Gujarati - India heIL - Hebrew - Israel hiIN - Hindi - India hrHR - Croatian - Croatia huHU - Hungarian - Hungary hyAM - Armenian - Armenia idID - Indonesian - Indonesia inID - Indonesian - Indonesia isIS - Icelandic - Iceland itCH - Italian - Switzerland itIT - Italian - Italy iwIL - Hebrew - Israel jaJP - Japanese - Japan jiIL - Yiddish - Isreal kaGE - Georgian - Georgia kkKZ - Kazahk - Kazahkstan klGL - Greenlandic - Greenland kmKH - Cambodian - Cambodia knIN - Kannada - India koKP - Korean - Democratic People's Republic of Korea koKR - Korean - Republic of Korea ksIN - Kashmiri - India kuIQ - Kurdish - Iraq loLA - Laothain - Laos ltLT - Lithuanian - Lithuania lvLV - Latvian - Latvia mkMK - Macedonian - Former Yugoslav Republic of Macedonia mlIN - Malayalam - India mnMN - Mongolian - Mongolia moMD - Moldavian - Moldava mrIN - Marathi - India msBN - Malay - Brunei Darussalam msMY - Malay - Malaysia mtMT - Maltese - Malta myMM - Burmese - Myanmar neNP - Nepali - Nepal nlBE - Dutch - Belgium nlNL - Dutch - Netherlands noNO - Norwegian - Norway orIN - Oriya - India paIN - Punjabi - India plPL - Polish - Poland ptBR - Portuguese - Brazil ptPT - Portuguese - Portugal roRO - Romanian - Romania ruRU - Russian - Russia saIN - Sanskrit - India skSK - Slovak - Slovakia slSL - Slovene - Slovenia smWS - Samoan - Samoa soSO - Somali - Somalia sqAL - Albanian - Albania suSD - Sudanese - Sudan svFI - Swedish - Finland svSE - Swedish - Sweden swKE - Swahili - Kenya taIN - Tamil - India teIN - Telugu - India thTH - Thai - Thailand trTR - Turkish - Turkey ukUA - Ukrainian - Ukraine urIN - Uru - India urPK - Urdu - Pakistan uzUZ - Uzbek - Uzbekistan viVN - Vietnamese - Viet Nam yiIL - Yiddish - Isreal zhCN - Chinese - China zhHK - Chinese - Hong Kong zhMO - Chinese - Macau zhSG - Chinese - Singapore zhTW - Chinese - Taiwan -------------------------------------- From sommer at granitesystems.com Mon Apr 9 20:44:50 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: Message-ID: <4.2.0.58.20010409203512.00966810@mailbox.bellatlantic.net> I have enUK in the list but it should be enGB. I have slSL in the list but it should be slSI (lower case ell and upper case eye). The language sh is listed as Serbo-Croatian and sr is listed Serbian. I couldn't find the countries AA and SP in the ISO country code list. Jim At 4/9/01 08:22 PM, Mark VanderWiele wrote: >Missing Locales > > >arAA (Arabic) >enBE (Belgium) >enGB (Great Britain) >enIN (India) >shSP (Serbian Latin) >shYU (Serbian Latin - Yugoslavia) >srSP (Serbian Cyrillic) >srYU (Serbian Cyrillic - Yugoslavia) >slSI (Slovene) (the last character is uppercase "i") > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From harryl at us.ibm.com Tue Apr 10 07:20:53 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:04:53 2009 Subject: IPP> Re: UPD> Don't stop Do what is necessary Message-ID: I agree it might be more flexible and serve better in multiple protocols or environments if we avoid specifying one fixed form of concatenation. I think Mark's point, which I have heard him making for over a year, now, in UPDF and IPP meetings is that a client does need all this information in order for any of it to be effective. I think we should head this "warning". ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-ipp@pwg.org 04/09/2001 10:44 AM To: "Mark VanderWiele" cc: ipp@pwg.org, upd@pwg.org Subject: IPP> Re: UPD> Don't stop Do what is necessary Mark, et al: I have no problem with creating the combined name but I think this is better done in the end standard that uses these names in a combined form. There may be reasons that UPD wants a certain set of characteristics in its media names that differ from what IPP might want, or uPnP might want, etc. If this standard tries to be all things to all users then it will never be done. One of the major issues raised by the IETF with IPP was it was just too big to deal with. It is thought to be better to create a number of smaller standards that deal with a smaller set of issues and then use those smaller standards as building blocks. I think this is a perfect example where smaller and simpler is better. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Mark VanderWiele" on 04/05/2001 09:58:15 AM To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com cc: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Tue Apr 10 14:31:32 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> XML syntax Message-ID: <001001c0c1ec$773e5430$551414ac@hsg.ma.oaktech.com> I'm looking out for help today while trying to write some proper XML for what I want to implement. My intention: Let think about media types. It's quite easy to provide a list of predefined keywords to let the developer choose from allowed values only. That's an attribute with an enumerated list. But it's getting complicated when I want to allow him to choose from the list or enter his own name for a custom media type. So I was dreaming of something like an editable combo box. Does not seem to be possible with XML. What about workarounds? Who was facing that kind of problem already and developed some syntax for it? Or knows somebody who did or may know? A simple solution could be to add a keyword 'custom' to the list of predefined ones and adding another attribute, which then holds the custom string. Feels like a hack to me. In that case I'd expect a rule like 'show the custom string only when keyword custom is chosen in the predefined list'. Don't know that syntax either by heart. Help??? Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010410/1bb58f91/attachment.html From mike at easysw.com Tue Apr 10 15:56:14 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5FD1F@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AD3655E.90818BC2@easysw.com> [Agreement coming late, since I was off enjoying a bit of vacation time... :)] "Hastings, Tom N" wrote: > ... > A Printer that supports a minimum custom size of, say, 3 inches > by 5 inches, and a maximum of, say, 8.5 inches by 14, would have > the following two values: > > na-custom-max.8500-1400 > na-custom-min.300-500 > > Any disagreements? > > I also believe that this meets Michael's needs for custom sizes, > whether for the 'roll' Media Type or any of the other Media Type > values. > ... Yes... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Apr 10 16:03:08 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: min and max size and the creeping scope of the media standard[new subject] References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE86@triton.hitachi-hkis.com> Message-ID: <3AD366FC.CFCC4339@easysw.com> "Bergman, Ron" wrote: > ... > separator in the size name. So your example would be: > > stationery/na-letter.8500-11000/white/none > > Or, would a different character be better? > ... The "media-col" attribute (and associated collection syntax) can be used with the "standard" names defined here. Trying to shoehorn everything into the media attribute just won't work, and as much as I hate collections they seem to be the best solution to this particular problem. So, I would recommend to *not* add this kind of a proposal to the current spec - it is WAY out of scope and would apparently duplicate the work done for media-col without properly representing other media attributes (weight, etc.) that may be needed... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Apr 10 16:24:14 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: IPP> MED - Proposal for simple Media Self Describing Names (all in onenames) References: <918C79AB552BD211A2BD00805F15CE8504C5FE5B@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AD36BEE.C983D0A9@easysw.com> "Hastings, Tom N" wrote: > ... > A valid Media Self Describing Name MUST include the Media Size Self > Describing Name (both Size Name and Dimensions fields as defined in > the D0.5 Draft) followed by other fields which MUST be in the > following order: > ... What about a media with a glossy back finish but a matte front finish? Do you then explicitly include the "matte" for the front finish? Also, this requires the parser to know what keywords go with what attribute - that is, "matte" is a finish attribute, and "bond" is a media type name, "80-gram" is a media weight, etc... If we are going to make this a "standard", then we probably want to require any intervening names to be included, for example: na-letter.8500-11000.red should be: na-letter.8500-11000.stationary.plain.red or: na-letter.8500-11000...red with any unspecified fields *after* the last one set to the default (or matching any value) This is one of the reasons I think we should not try to add all-in-one names to the spec, but should use the existing mechanisms (e.g. for IPP the "media-col" attribute) and just standardize the naming of the values. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From don at lexmark.com Wed Apr 11 11:27:40 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: <200104111527.LAA12470@interlock2.lexmark.com> For some reason I thought both enUK and enGB were valid. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** Jim Sommer on 04/09/2001 08:44:50 PM To: "Mark VanderWiele" , owner-upd%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Re: UPDF open standard for locales I have enUK in the list but it should be enGB. I have slSL in the list but it should be slSI (lower case ell and upper case eye). The language sh is listed as Serbo-Croatian and sr is listed Serbian. I couldn't find the countries AA and SP in the ISO country code list. Jim At 4/9/01 08:22 PM, Mark VanderWiele wrote: >Missing Locales > > >arAA (Arabic) >enBE (Belgium) >enGB (Great Britain) >enIN (India) >shSP (Serbian Latin) >shYU (Serbian Latin - Yugoslavia) >srSP (Serbian Cyrillic) >srYU (Serbian Cyrillic - Yugoslavia) >slSI (Slovene) (the last character is uppercase "i") > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From norbertschade at oaktech.com Wed Apr 11 11:40:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales References: <200104111527.LAA12470@interlock2.lexmark.com> Message-ID: <001201c0c29d$b8c1b350$551414ac@hsg.ma.oaktech.com> Bad situation. We should be unique. Looking at the Unicode weg pages I tend to use enGB. I also stay with the Unicode language keywords for Serbo-Croation and Serbian. I'm waiting for some details from Mark to finish it up like what countries are AA and SP. He seems to have a slightly different source. Norbert Schade ----- Original Message ----- From: To: "Jim Sommer" Cc: "Mark VanderWiele" ; ; Sent: Wednesday, April 11, 2001 11:27 AM Subject: Re: UPD> Re: UPDF open standard for locales > > > For some reason I thought both enUK and enGB were valid. > > ********************************************** > * Don Wright don@lexmark.com * > * Chair, Printer Working Group * > * Chair, IEEE MSC * > * * > * Director, Alliances & Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 859-825-4808 (phone) 603-963-8352 (fax) * > ********************************************** > > > > Jim Sommer on 04/09/2001 > 08:44:50 PM > > To: "Mark VanderWiele" , > owner-upd%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: Re: UPD> Re: UPDF open standard for locales > > > > I have enUK in the list but it should be enGB. > > I have slSL in the list but it should be slSI (lower case ell and upper > case eye). > > The language sh is listed as Serbo-Croatian and sr is listed Serbian. > > I couldn't find the countries AA and SP in the ISO country code list. > > Jim > > > At 4/9/01 08:22 PM, Mark VanderWiele wrote: > > >Missing Locales > > > > > >arAA (Arabic) > >enBE (Belgium) > >enGB (Great Britain) > >enIN (India) > >shSP (Serbian Latin) > >shYU (Serbian Latin - Yugoslavia) > >srSP (Serbian Cyrillic) > >srYU (Serbian Cyrillic - Yugoslavia) > >slSI (Slovene) (the last character is uppercase "i") > > > >Regards, > >Mark VanderWiele > >IBM, Linux Technology Center > >512-838-4779, t/l 678 > >MARKV@IBMUS > >email: markv@us.ibm.com > > > > > > From sommer at granitesystems.com Wed Apr 11 11:55:00 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: <001201c0c29d$b8c1b350$551414ac@hsg.ma.oaktech.com> References: <200104111527.LAA12470@interlock2.lexmark.com> Message-ID: <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> I haven't seen any standard that has UK in it so I say use GB. AA and SP are IBM internal designation for all Arabic countries and Serbia (see email attached below). If you look at http://www.niso.org/3166.html#serbia you'll see the Serbia question addressed. So, I don't think these need to be added. Jim ---------- Subject: Re: UPDF open standard for locales To: sommer@granitesystems.com Cc: "Mark VanderWiele" From: "Mary Trumble" Date: Tue, 10 Apr 2001 19:14:07 -0400 Message-ID: "SP" is the abbreviation that IBM uses for Serbia. It's appropriate to call it a "territory", in the POSIX-locale sense, but, politically-speaking, there may be a difference of opinion about whether it's a country. "AA" is the IBM generic designation for "Arabic-speaking countries". If you're including only (and all) countries you don't need this. Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/5be92d05/attachment.html From norbertschade at oaktech.com Wed Apr 11 12:11:35 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales References: <200104111527.LAA12470@interlock2.lexmark.com> <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> Message-ID: <005e01c0c2a2$14feb060$551414ac@hsg.ma.oaktech.com> Based on the latest comments this is my proposal: Add enBE, enIN, shYU, srYU. Change enUK to enGB. Do not add arAA, shSP, srSP, as they are not based on the Unicode standard. Does that work for everybody? Regards Norbert Schade ----- Original Message ----- From: Jim Sommer To: Norbert Schade ; UPD group Sent: Wednesday, April 11, 2001 11:55 AM Subject: Re: UPD> Re: UPDF open standard for locales I haven't seen any standard that has UK in it so I say use GB. AA and SP are IBM internal designation for all Arabic countries and Serbia (see email attached below). If you look at http://www.niso.org/3166.html#serbia you'll see the Serbia question addressed. So, I don't think these need to be added. Jim ------------------------------------------------------------------------------ Subject: Re: UPDF open standard for locales To: sommer@granitesystems.com Cc: "Mark VanderWiele" From: "Mary Trumble" Date: Tue, 10 Apr 2001 19:14:07 -0400 Message-ID: "SP" is the abbreviation that IBM uses for Serbia. It's appropriate to call it a "territory", in the POSIX-locale sense, but, politically-speaking, there may be a difference of opinion about whether it's a country. "AA" is the IBM generic designation for "Arabic-speaking countries". If you're including only (and all) countries you don't need this. Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/ecef067b/attachment.html From sommer at granitesystems.com Wed Apr 11 13:05:03 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:53 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: <005e01c0c2a2$14feb060$551414ac@hsg.ma.oaktech.com> References: <200104111527.LAA12470@interlock2.lexmark.com> <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> Message-ID: <4.2.0.58.20010411130323.009552a0@mailbox.bellatlantic.net> In addition, slSL should be changed to slSI. Jim At 4/11/01 12:11 PM, Norbert Schade wrote: >Based on the latest comments this is my proposal: >Add enBE, enIN, shYU, srYU. >Change enUK to enGB. >Do not add arAA, shSP, srSP, as they are not based on the Unicode standard. > >Does that work for everybody? >Regards >Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/025d655b/attachment.html From norbertschade at oaktech.com Wed Apr 11 13:07:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> all-in-one media handling Message-ID: <007801c0c2a9$d5567ad0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010411/3061a13e/NorbertSchade.vcf From RonBergman at aol.com Wed Apr 11 16:32:46 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:04:53 2009 Subject: UPD> Media Names Spec Discussion Message-ID: <17.145fdfa3.2806196e@aol.com> We have been getting complaints regarding the multiple postings regarding this subject. Some members only see a single message (such as myself) and others see all. So I am requesting that all future messages on this subject be sent only to the ipp mail list. Also, there have been several requests for new names to be added to the document without any real definition of the name. (For example, requesting the name "foobar" with the definition "this is a foobar type", is not adequate.) If you would like me to add a definition, I will guarantee that it will not be what you expect. So, please provide a definition or no further consideration will be given to the request. Ron Bergman Hitachi Koki Imaging Solutions From norbertschade at mediaone.net Sat Apr 14 17:00:04 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> minimum hardware margins Message-ID: <000c01c0c525$e18dc3c0$f2755b18@ne.mediaone.net> Within UPDF we were working with absolute units of mm/1000 in a number of cases like everything, which had to do with media handling. We commit to implement the new spec for global media handling (Ron's spec) from now on. We want to indicate our full support of this spec in our concept. Current implementations within our protocol will already be based on draft 0.6. We expect the syntax not to be changed drastically any more! We don't have problems with adding or removing some keywords within the well defined lists. But this has to be finished soon (within April) not to let us slip out of our own schedules. As we are finishing our implementation of our mother sample followed directly by a number of sample implementations based on that mother, we are in a critical process. The spec specifies two special values outside the list of keywords used in the lists, which are used for minimum and maximum media sizes. We will use that same syntax for one additional case to let a driver use the same routines all over the place. We leave it to the global media handling spec, where it adds these keywords (as side notes or recommendations) or not. The proposals for the new keywords within UPDF are na-margin-min-left.250 na-margin-min-right.250 na-margin-min-top.250 na-margin-min-bottom.250 Syntax should look familiar to you. 'na' is optional like in definitions for media size. It generally follows the rules of the spec. In this sample the minimum margins are a quarter of an inch. Confirmation requested within the UPDF group. Comment from IPP group and the spec owners appreciated. We may use this syntax, if needed in other places, as well to provide a consistent concept. Thanks to the very good work of Ron Bergman, Tom Hasting and others. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010414/d1a3e39a/attachment.html From norbertschade at mediaone.net Sat Apr 14 17:43:29 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> DTD editing Message-ID: <000d01c0c52b$f1de09a0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7232 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010414/3450aabc/UPDFPrintMediaHandling.obj From norbertschade at oaktech.com Mon Apr 16 11:10:02 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> telecon Message-ID: <001401c0c687$4fdc0dc0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/49408d43/NorbertSchade.vcf From hastings at cp10.es.xerox.com Mon Apr 16 12:33:37 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:53 2009 Subject: UPD> telecon [media, color, and raster graphics] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C600CF@x-crt-es-ms1.cp10.es.xerox.com> Norbert, It wasn't clear to me whether or not you were going to attempt to cover color and raster graphics at this Friday's telecon? Your expression: "On the other hand print media handling is almost done. So there will be little room for other things" could be interpreted either (1) that we will be spending most of the time reviewing the media handling and so there will be "little room for color and raster graphics", or (2) the media is all done, so there will be some time for other things. We have some color experts at Xerox who might be helpful, if you were going to cover that subject. I don't think they are interested in the media part though. So it would be helpful to have time allocations in the agenda for the telecon, so that people could call in when the subject of interest was being discussed. I would be glad to call in for the media part (and stay in for the color and raster graphics, though I am not an expert, if that is also covered). Color and raster graphics are a topic, so it might be more prudent to have the color and raster graphics on a separate telecon and have this Friday's telecon focus on finishing the media topic. What do you think? Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Monday, April 16, 2001 08:10 To: UPD group Subject: UPD> telecon Remember the Tampa meeting notes? Excerpt: Tele conferences We will have a small number of telecons. The first is proposed to be April, 20th, at noon EST. Please indicate your availability in the week before. I will provide an agenda for that one. Sample topics will be color and raster graphics. Depending on progress there are one or two more planned before Toronto. Who will be in? Depending on the participants I will prepare an agenda. I've finished a larger section over the week-end while implementing the global media spec into UPDF. This now gives us the chance to do some cleanup. I still do not have the time - and do not feel to be a color expert on the required level - to do that implementation. This is getting critical. I haven't yet found the time to further specify raster graphics either. On the other hand print media handling is almost done. So there will be little room for other things. Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010416/2e45a8ab/attachment.html From norbertschade at oaktech.com Mon Apr 16 13:19:38 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:53 2009 Subject: UPD> Fw: telecon Message-ID: <004701c0c699$6aa24810$551414ac@hsg.ma.oaktech.com> Should have been more careful. > I haven't yet found the time to further specify raster graphics either. On the other hand print media handling is almost > done. So there will be little room for other things. That means: Yes, we will have room for other things. I want to come to a consensus for most of the media handling this week and then move on to other things. The feedback today make already clear that there is interest in doing the telecon. Hereby decided. I want to wait for more notes from people going to attend, before I distribute an agenda on Wednesday. Recommendation: Have your dtd and XML editor running during the telecon. You don't need to edit, but it's easier talking. Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010416/e9323e0a/attachment.html From norbertschade at oaktech.com Mon Apr 16 15:58:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> Message-ID: <005601c0c6af$8c7c32a0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/af7c4348/NorbertSchade.vcf From norbertschade at oaktech.com Mon Apr 16 15:58:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> Message-ID: <006201c0c6af$99d4a400$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/6e8b772d/NorbertSchade.vcf From norbertschade at mediaone.net Mon Apr 16 21:27:08 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> global media handling implemented Message-ID: <000d01c0c6dd$854f1b40$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7615 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFCommandSequences.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 21423 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 13432 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 870 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1814 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale-deDE-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 2894 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale-enUS-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2614 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFCommandSequences-HPLaserJetPCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDF.obj From norbertschade at mediaone.net Tue Apr 17 21:43:35 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> tonight's changes Message-ID: <001701c0c7a8$fbb2b500$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 13540 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 3319 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFLocale-enUS-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7819 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 22320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml From norbertschade at oaktech.com Wed Apr 18 13:58:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> telecon Friday, April 20th, noon EST Message-ID: <003501c0c831$2774e9a0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010418/89fa9870/NorbertSchade.vcf From markv at us.ibm.com Wed Apr 18 20:07:12 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:54 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Norbert: I will try to get the following information into the desired format. However, I wanted to let you know that the Linux globaization work is tackling the same problem and has another locals list. They have identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in your list of locals. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on 04/18/2001 06:33 PM --------------------------- Akio Kido@IBMJP 04/16/2001 09:13 PM To: Mark VanderWiele/Austin/IBM@IBMUS cc: George Kraft/Austin/IBM@IBMUS From: Akio Kido/Japan/IBM@IBMJP Subject: Re: UPDF open standard for locales (Document link: Mark VanderWiele) Hi, Mark. Sorry for my delaied response. ( I was on business trip on last week and restricted access to IBM network ). Annex B of LI18NUX2000 Globalization specification specified the list of locales that should be supported by LI18NUX2000 confomant distribution. Please refer to http://www.li18nux.org/li18nux2k/ As far as I checked the LI18NUX2000, the following locales are in the LI18NUX2000 but not in the list attached. arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, gvGB, knIN, kwGB, psIN, ruUA, sdIN, shYU, srYU. Best regards, Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) 1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 To: Akio Kido/Japan/IBM@IBMJP cc: George Kraft/Austin/IBM@IBMUS From: Mark VanderWiele/Austin/IBM@IBMUS Subject: Re: UPDF open standard for locales Kido-san: The following list all the way at the bottom of this note is a proposed list to identify translations in the Universal Printer Driver Format standard being worked on by the Printer Working Group (www.pwg.org). Please verify its completeness, Forward to other IBM interested parties, & and or propose a better source. I am told you may be working on an I18N standard for locals. Is this true? Is there another list I should be looking at? Thank you, Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Thu Apr 19 08:56:41 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> Re: UPDF open standard for locales References: Message-ID: <000d01c0c8d0$2e2f04c0$551414ac@hsg.ma.oaktech.com> Mark, I have no problem adding new triples of locale-language-country to our list, as long as the abbreviations, languages and countries are coming from the ISO lists. I'm open to any new combination. How to do it best? Can you provide the new lines with the proper syntax, when you got that final, and I just add it? Regards Norbert ----- Original Message ----- From: "Mark VanderWiele" To: ; Sent: Wednesday, April 18, 2001 8:07 PM Subject: UPD> Re: UPDF open standard for locales > Norbert: I will try to get the following information into the desired > format. However, I wanted to let you know that the Linux globaization work > is tackling the same problem and has another locals list. They have > identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, > esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in > your list of locals. > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678 > MARKV@IBMUS > email: markv@us.ibm.com > ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on > 04/18/2001 06:33 PM --------------------------- > > Akio Kido@IBMJP > 04/16/2001 09:13 PM > > To: Mark VanderWiele/Austin/IBM@IBMUS > cc: George Kraft/Austin/IBM@IBMUS > From: Akio Kido/Japan/IBM@IBMJP > Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > > Hi, Mark. Sorry for my delaied response. ( I was on business trip on last > week and restricted access to IBM network ). > > Annex B of LI18NUX2000 Globalization specification specified the list of > locales that should be supported by > LI18NUX2000 confomant distribution. Please refer to > http://www.li18nux.org/li18nux2k/ > > As far as I checked the LI18NUX2000, the following locales are in the > LI18NUX2000 but not in the list > attached. > > arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, > gvGB, knIN, > kwGB, psIN, ruUA, sdIN, shYU, srYU. > > Best regards, > Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) > 1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) > E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > > From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > > To: Akio Kido/Japan/IBM@IBMJP > cc: George Kraft/Austin/IBM@IBMUS > From: Mark VanderWiele/Austin/IBM@IBMUS > Subject: Re: UPDF open standard for locales > > > > Kido-san: The following list all the way at the bottom of this note is a > proposed list to identify translations in the Universal Printer Driver > Format standard being worked on by the Printer Working Group (www.pwg.org). > Please verify its completeness, Forward to other IBM interested parties, & > and or propose a better source. I am told you may be working on an I18N > standard for locals. Is this true? Is there another list I should be > looking at? > > Thank you, > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678 > MARKV@IBMUS > email: markv@us.ibm.com > From sommer at granitesystems.com Thu Apr 19 09:05:53 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:54 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: Message-ID: <4.2.0.58.20010419082535.0095fe50@mailbox.bellatlantic.net> Here's the translation of the locales that Mark listed: arIN-Arabic-India arSD-Arabic-Sudan deBE-German-Belgium enBE-English-Belgium enBW-English-Botswana enHK-English-Hong_Kong enIN-English-India enSG-English-Singapore enZW-English-Zimbabwe esGT-Spanish-Guatemala (this was in the original list) esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original list) faIN-Farsi-India glES-Galician-Spain (from the Linux web site, not Mark's list) gvGB-Manx_Gaelic-United_Kingdon knIN-Kannada-India (this was in the original list) kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) psIN-Pashto-India ruUA-Russian-Ukraine sdIN-Sindhi-India shYU-Serbo-Croatian-Yugoslavia srYU-Serbian-Yugoslavia I couldn't find the country SU but looking at the Linux web site, I figured it was a typo and supposed to be SD. enZA was in the original list but from the Linux web site I found that enZW was missing. I couldn't find the language fs but found that faIN was missing. I don't think we should include kwGB since Cornish isn't in the ISO language list. Jim At 4/18/01 08:07 PM, Mark VanderWiele wrote: >Norbert: I will try to get the following information into the desired >format. However, I wanted to let you know that the Linux globaization work >is tackling the same problem and has another locals list. They have >identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >your list of locals. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com >---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >04/18/2001 06:33 PM --------------------------- > >Akio Kido@IBMJP >04/16/2001 09:13 PM > >To: Mark VanderWiele/Austin/IBM@IBMUS >cc: George Kraft/Austin/IBM@IBMUS >From: Akio Kido/Japan/IBM@IBMJP >Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > >Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >week and restricted access to IBM network ). > >Annex B of LI18NUX2000 Globalization specification specified the list of >locales that should be supported by >LI18NUX2000 confomant distribution. Please refer to >http://www.li18nux.org/li18nux2k/ > >As far as I checked the LI18NUX2000, the following locales are in the >LI18NUX2000 but not in the list >attached. > >arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >gvGB, knIN, >kwGB, psIN, ruUA, sdIN, shYU, srYU. > >Best regards, >Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > >From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > >To: Akio Kido/Japan/IBM@IBMJP >cc: George Kraft/Austin/IBM@IBMUS >From: Mark VanderWiele/Austin/IBM@IBMUS >Subject: Re: UPDF open standard for locales > > > >Kido-san: The following list all the way at the bottom of this note is a >proposed list to identify translations in the Universal Printer Driver >Format standard being worked on by the Printer Working Group (www.pwg.org). >Please verify its completeness, Forward to other IBM interested parties, & >and or propose a better source. I am told you may be working on an I18N >standard for locals. Is this true? Is there another list I should be >looking at? > >Thank you, > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From markv at us.ibm.com Thu Apr 19 14:57:36 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:54 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Akio: What should we do about kw its not in the ISO languages? Also, was SU really SD. see info below. Jim: Thank You. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com Jim Sommer on 04/19/2001 08:05:53 AM To: Mark VanderWiele/Austin/IBM@IBMUS, norbertschade@oaktech.com, cc: Subject: Re: UPD> Re: UPDF open standard for locales Here's the translation of the locales that Mark listed: arIN-Arabic-India arSD-Arabic-Sudan deBE-German-Belgium enBE-English-Belgium enBW-English-Botswana enHK-English-Hong_Kong enIN-English-India enSG-English-Singapore enZW-English-Zimbabwe esGT-Spanish-Guatemala (this was in the original list) esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original list) faIN-Farsi-India glES-Galician-Spain (from the Linux web site, not Mark's list) gvGB-Manx_Gaelic-United_Kingdon knIN-Kannada-India (this was in the original list) kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) psIN-Pashto-India ruUA-Russian-Ukraine sdIN-Sindhi-India shYU-Serbo-Croatian-Yugoslavia srYU-Serbian-Yugoslavia I couldn't find the country SU but looking at the Linux web site, I figured it was a typo and supposed to be SD. enZA was in the original list but from the Linux web site I found that enZW was missing. I couldn't find the language fs but found that faIN was missing. I don't think we should include kwGB since Cornish isn't in the ISO language list. Jim At 4/18/01 08:07 PM, Mark VanderWiele wrote: >Norbert: I will try to get the following information into the desired >format. However, I wanted to let you know that the Linux globaization work >is tackling the same problem and has another locals list. They have >identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >your list of locals. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com >---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >04/18/2001 06:33 PM --------------------------- > >Akio Kido@IBMJP >04/16/2001 09:13 PM > >To: Mark VanderWiele/Austin/IBM@IBMUS >cc: George Kraft/Austin/IBM@IBMUS >From: Akio Kido/Japan/IBM@IBMJP >Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > >Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >week and restricted access to IBM network ). > >Annex B of LI18NUX2000 Globalization specification specified the list of >locales that should be supported by >LI18NUX2000 confomant distribution. Please refer to >http://www.li18nux.org/li18nux2k/ > >As far as I checked the LI18NUX2000, the following locales are in the >LI18NUX2000 but not in the list >attached. > >arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >gvGB, knIN, >kwGB, psIN, ruUA, sdIN, shYU, srYU. > >Best regards, >Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > >From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > >To: Akio Kido/Japan/IBM@IBMJP >cc: George Kraft/Austin/IBM@IBMUS >From: Mark VanderWiele/Austin/IBM@IBMUS >Subject: Re: UPDF open standard for locales > > > >Kido-san: The following list all the way at the bottom of this note is a >proposed list to identify translations in the Universal Printer Driver >Format standard being worked on by the Printer Working Group (www.pwg.org). >Please verify its completeness, Forward to other IBM interested parties, & >and or propose a better source. I am told you may be working on an I18N >standard for locals. Is this true? Is there another list I should be >looking at? > >Thank you, > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From norbertschade at mediaone.net Mon Apr 23 08:00:08 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> new files Message-ID: <000d01c0cbec$f187c0a0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 10742 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 14400 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 8150.xml Type: text/xml Size: 917 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFDeviceConfiguration-HPLaserJet8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 14089 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDF.obj From norbertschade at mediaone.net Mon Apr 23 09:06:10 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> wrong file Message-ID: <002001c0cbf6$2b21c280$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 15785 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/3096d71b/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml From norbertschade at oaktech.com Mon Apr 23 10:43:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> telecon last Friday Message-ID: <004c01c0cc03$bdf91600$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/2397446a/NorbertSchade.vcf From norbertschade at oaktech.com Mon Apr 23 11:13:31 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> comments on newest editings Message-ID: <005f01c0cc07$f56a84d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/2f62eef4/NorbertSchade.vcf From norbertschade at oaktech.com Mon Apr 23 16:15:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> short cuts Message-ID: <001401c0cc32$242cc9c0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/289a00a8/NorbertSchade.vcf From norbertschade at oaktech.com Tue Apr 24 09:39:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:54 2009 Subject: UPD> UPDF update on web site Message-ID: <001b01c0ccc3$f9158500$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010424/4d2286e1/NorbertSchade.vcf From Jim.Lo at Sun.COM Wed Apr 25 19:31:14 2001 From: Jim.Lo at Sun.COM (Jim Lo) Date: Wed May 6 14:04:54 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: <200104252331.QAA12372@mpk07.Eng.Sun.COM> Hi, Given a database about which popular ISO-639 languages are spoken in those ISO-3166 countries, attached (Locales.jimlo.txt) for your reference please find the following two tables automatically generated by the attached program (LocaleLang.java): Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) The format of the table 2 is intentionally conforming to that used in the http://www.li18nux.org/li18nux2k/ for the ease of comparison. There are 438 predefined locales (compared to 130 in li18nux2k) as a result of simply a real-life country/language combination. Hope it helps. rgds, Jim Lo Internet Appliance Group Sun Microsystems, Inc. ............................. Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) 1: Andorra (AD: fr es) French Spanish 2: United Arab Emirates (AE: ar en) Arabic English 3: Afghanistan (AF: ps) Pashto (Pushto) 4: AG (AG: en) English 5: Anguilla (AI: rn) Kirundi 6: Albania (AL: sq) Albanian 7: Armenia (AM: hy ru) Armenian Russian 8: Netherlands Antilles (AN: nl en) Dutch English 9: Angola (AO: pt) Portuguese 10: AQ (AQ:) 11: Argentina (AR: es) Spanish 12: AS (AS: en sm) English Samoan 13: Austria (AT: de) German 14: Australia (AU: en) English 15: Aruba (AW: nl en) Dutch English 16: Azerbaijan (AZ: az hy ru) Azerbaijani Armenian Russian 17: Bosnia and Herzegovina (BA: sr sh hr sl mk sq) Serbian Serbo-Croatian Croatian Slovenian Macedonian Albanian 18: Barbados (BB: en) English 19: Bangladesh (BD: bn hi bh en) Bengali Hindi Bihari English 20: Belgium (BE: fr nl de) French Dutch German 21: Burkina Faso (BF: fr) French 22: Bulgaria (BG: bg tr) Bulgarian Turkish 23: Bahrain (BH: ar en) Arabic English 24: Burundi (BI: rn fr sw) Kirundi French Swahili 25: Benin (BJ: fr) French 26: Bermuda (BM: en) English 27: Brunei (BN: ms en zh) Malay English Chinese 28: Bolivia (BO: es ay qu) Spanish Aymara Quechua 29: Brazil (BR: pt) Portuguese 30: Bahamas (BS: en) English 31: Bhutan (BT: dz en ne) Bhutani English Nepali 32: BV (BV: no) Norwegian 33: Botswana (BW: en tn) English Setswana 34: Belarus (BY: be ru) Byelorussian Russian 35: Belize (BZ: en es) English Spanish 36: Canada (CA: en fr) English French 37: CC (CC: en) English 38: Central African Republic (CF: fr sg) French Sangho 39: Congo (CG: fr) French 40: Switzerland (CH: fr de it rm) French German Italian Rhaeto-Romance 41: C?te d'Ivoire (CI: fr) French 42: CK (CK: mi en) Maori English 43: Chile (CL: es) Spanish 44: Cameroon (CM: en fr) English French 45: China (CN: zh bo) Chinese Tibetan 46: Colombia (CO: es) Spanish 47: Costa Rica (CR: es) Spanish 48: Cuba (CU: es) Spanish 49: Cape Verde (CV: pt) Portuguese 50: CX (CX: en) English 51: Cyprus (CY: el tr en) Greek Turkish English 52: Czech Republic (CZ: cs sk) Czech Slovak 53: Germany (DE: de) German 54: Djibouti (DJ: ar fr so) Arabic French Somali 55: Denmark (DK: da) Danish 56: Dominica (DM: en fr) English French 57: Dominican Republic (DO: es) Spanish 58: Algeria (DZ: ar fr) Arabic French 59: Ecuador (EC: es qu) Spanish Quechua 60: Estonia (EE: et ru) Estonian Russian 61: Egypt (EG: ar en fr) Arabic English French 62: Western Sahara (EH: ar fr it) Arabic French Italian 63: Eritrea (ER: am ti ar en it) Amharic Tigrinya Arabic English Italian 64: Spain (ES: es eu ca gl) Spanish Basque Catalan Galician 65: Ethiopia (ET: am ar en) Amharic Arabic English 66: Finland (FI: fi sv) Finnish Swedish 67: Fiji (FJ: en fj hi) English Fiji Hindi 68: FK (FK: en) English 69: Micronesia (FM: en) English 70: FO (FO: fo da) Faroese Danish 71: France (FR: fr eu br co) French Basque Breton Corsican 72: FX (FX: fr) French 73: Gabon (GA: fr) French 74: United Kingdom (GB: en gd cy) English Scots Gaelic Welsh 75: GD (GD: en fr) English French 76: Georgia (GE: ka hy ru) Georgian Armenian Russian 77: French Guiana (GF: fr) French 78: Ghana (GH: en) English 79: GI (GI: en es) English Spanish 80: GL (GL: da ik kl) Danish Inupiak Greenlandic 81: Gambia (GM: en wo) English Wolof 82: Guinea (GN: fr) French 83: Guadeloupe (GP: fr en) French English 84: Equatorial Guinea (GQ: es) Spanish 85: Greece (GR: el) Greek 86: GS (GS:) 87: Guatemala (GT: es) Spanish 88: GU (GU: en) English 89: Guinea-Bissau (GW: pt) Portuguese 90: Guyana (GY: en hi ur) English Hindi Urdu 91: Hong Kong (HK: zh en) Chinese English 92: HM (HM:) 93: Honduras (HN: es) Spanish 94: Croatia (HR: hr) Croatian 95: Haiti (HT: fr) French 96: Hungary (HU: hu) Hungarian 97: Indonesia (ID: in en nl) Indonesian English Dutch 98: Ireland (IE: en ga) English Irish 99: Israel (IL: iw ar ji) Hebrew Arabic Yiddish 100: India (IN: hi en gu kn ks ml mr ne or pa sa ta te) Hindi English Gujarati Kannada Kashmiri Malayalam Marathi Nepali Oriya Punjabi Sanskrit Tamil Telugu 101: IO (IO: en) English 102: Iraq (IQ: ar ku tk) Arabic Kurdish Turkmen 103: Iran (IR: fa ar ku) Persian Arabic Kurdish 104: Iceland (IS: is) Icelandic 105: Italy (IT: it fr de) Italian French German 106: Jamaica (JM: en) English 107: Jordan (JO: ar) Arabic 108: Japan (JP: ja) Japanese 109: Kenya (KE: en sw) English Swahili 110: Kyrgyzstan (KG: ky) Kirghiz 111: Cambodia (KH: km) Cambodian 112: Kiribati (KI: en) English 113: Comoros (KM: fr ar) French Arabic 114: KN (KN: en) English 115: North Korea (KP: ko) Korean 116: South Korea (KR: ko) Korean 117: Kuwait (KW: ar en) Arabic English 118: KY (KY: en) English 119: Kazakhstan (KZ: kk ru) Kazakh Russian 120: Laos (LA: lo fr) Laothian French 121: Lebanon (LB: ar en fr) Arabic English French 122: LC (LC: en fr) English French 123: Liechtenstein (LI: de) German 124: Sri Lanka (LK: ta si en) Tamil Sinhalese English 125: Liberia (LR: en) English 126: Lesotho (LS: st en) Sesotho English 127: Lithuania (LT: lt ru pl) Lithuanian Russian Polish 128: Luxembourg (LU: fr de) French German 129: Latvia (LV: lv lt ru) Latvian (Lettish) Lithuanian Russian 130: Libya (LY: ar en it) Arabic English Italian 131: Morocco (MA: ar fr es) Arabic French Spanish 132: Monaco (MC: fr en it) French English Italian 133: Moldova (MD: mo ro bg) Moldavian Romanian Bulgarian 134: Madagascar (MG: mg en fr) Malagasy English French 135: MH (MH:) 136: Macedonia (MK: mk sh tr) Macedonian Serbo-Croatian Turkish 137: Mali (ML: fr) French 138: Myanmar (MM: my) Burmese 139: Mongolia (MN: mn ru) Mongolian Russian 140: MO (MO: zh pt) Chinese Portuguese 141: MP (MP:) 142: Martinique (MQ: fr) French 143: Mauritania (MR: ar fr) Arabic French 144: Montserrat (MS: en) English 145: Malta (MT: mt en it) Maltese English Italian 146: Mauritius (MU: en fr hi) English French Hindi 147: MV (MV:) 148: MW (MW: en) English 149: Mexico (MX: es) Spanish 150: Malaysia (MY: ms en) Malay English 151: Mozambique (MZ: pt) Portuguese 152: Namibia (NA: en af de) English Afrikaans German 153: New Caledonia (NC:) 154: Niger (NE: fr ha) French Hausa 155: NF (NF: en) English 156: Nigeria (NG: en ha yo) English Hausa Yoruba 157: Nicaragua (NI: es) Spanish 158: Netherlands (NL: nl fy) Dutch Frisian 159: Norway (NO: no) Norwegian 160: Nepal (NP: ne) Nepali 161: NR (NR: na en) Nauru English 162: Niue (NU: en) English 163: New Zealand (NZ: en mi) English Maori 164: Oman (OM: ar en) Arabic English 165: Panama (PA: es en) Spanish English 166: Peru (PE: es qu ay) Spanish Quechua Aymara 167: French Polynesia (PF: fr) French 168: Papua New Guinea (PG: en) English 169: Philippines (PH: en tl es) English Tagalog Spanish 170: Pakistan (PK: ur en ps pa sd) Urdu English Pashto (Pushto) Punjabi Sindhi 171: Poland (PL: pl) Polish 172: PM (PM: fr en) French English 173: PN (PN: en) English 174: Puerto Rico (PR: es en) Spanish English 175: Portugal (PT: pt) Portuguese 176: PW (PW: en) English 177: Paraguay (PY: es gn) Spanish Guarani 178: Qatar (QA: ar en) Arabic English 179: RE (RE: fr ta) French Tamil 180: Romania (RO: ro hu) Romanian Hungarian 181: Russia (RU: ru) Russian 182: Rwanda (RW: en fr rw) English French Kinyarwanda 183: Saudi Arabia (SA: ar) Arabic 184: SB (SB: en) English 185: Seychelles (SC: en fr) English French 186: Sudan (SD: ar su) Arabic Sundanese 187: Sweden (SE: sv) Swedish 188: Singapore (SG: zh en ms ta) Chinese English Malay Tamil 189: SH (SH: en) English 190: Slovenia (SI: sl) Slovenian 191: SJ (SJ: no) Norwegian 192: Slovakia (SK: sk hu pl sh) Slovak Hungarian Polish Serbo-Croatian 193: Sierra Leone (SL: en) English 194: SM (SM: it) Italian 195: Senegal (SN: fr) French 196: Somalia (SO: ar en it so) Arabic English Italian Somali 197: Suriname (SR: nl en es hi) Dutch English Spanish Hindi 198: ST (ST: pt) Portuguese 199: El Salvador (SV: es) Spanish 200: Syria (SY: ar) Arabic 201: Swaziland (SZ: en ss) English Siswati 202: TC (TC: en) English 203: Chad (TD: fr ar) French Arabic 204: French Southern Territories (TF: fr) French 205: Togo (TG: fr) French 206: Thailand (TH: th) Thai 207: Tajikistan (TJ: tg ru uz) Tajik Russian Uzbek 208: Tokelau (TK: en mi) English Maori 209: Turkmenistan (TM: tk ru) Turkmen Russian 210: Tunisia (TN: ar) Arabic 211: Tonga (TO: en to) English Tonga 212: East Timor (TP:) 213: Turkey (TR: tr ku) Turkish Kurdish 214: Trinidad and Tobago (TT: en) English 215: TV (TV: en) English 216: Taiwan (TW: zh) Chinese 217: Tanzania (TZ: en sw) English Swahili 218: Ukraine (UA: uk ru) Ukrainian Russian 219: Uganda (UG: en sw) English Swahili 220: UM (UM: en) English 221: United States (US: en es) English Spanish 222: Uruguay (UY: es) Spanish 223: Uzbekistan (UZ: uz ru) Uzbek Russian 224: Vatican (VA: la it) Latin Italian 225: VC (VC: en) English 226: Venezuela (VE: es) Spanish 227: British Virgin Islands (VG: en) English 228: U.S. Virgin Islands (VI: en) English 229: Vietnam (VN: vi zh fr) Vietnamese Chinese French 230: Vanuatu (VU: en fr bi) English French Bislama 231: WF (WF: fr) French 232: WS (WS: en sm) English Samoan 233: Yemen (YE: ar) Arabic 234: Mayotte (YT: fr mg sw) French Malagasy Swahili 235: Yugoslavia (YU: sr sh mk hu) Serbian Serbo-Croatian Macedonian Hungarian 236: South Africa (ZA: af en) Afrikaans English 237: Zambia (ZM: en) English 238: Zaire (ZR: fr sw) French Swahili 239: Zimbabwe (ZW: en sn) English Shona aa Afar ab Abkhazian Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) 1: af_NA Afrikaans Namibia 2: af_ZA South Africa 3: am_ER Amharic Eritrea 4: am_ET Ethiopia 5: ar_AE Arabic United Arab Emirates 6: ar_BH Bahrain 7: ar_DJ Djibouti 8: ar_DZ Algeria 9: ar_EG Egypt 10: ar_EH Western Sahara 11: ar_ER Eritrea 12: ar_ET Ethiopia 13: ar_IL Israel 14: ar_IQ Iraq 15: ar_IR Iran 16: ar_JO Jordan 17: ar_KM Comoros 18: ar_KW Kuwait 19: ar_LB Lebanon 20: ar_LY Libya 21: ar_MA Morocco 22: ar_MR Mauritania 23: ar_OM Oman 24: ar_QA Qatar 25: ar_SA Saudi Arabia 26: ar_SD Sudan 27: ar_SO Somalia 28: ar_SY Syria 29: ar_TD Chad 30: ar_TN Tunisia 31: ar_YE Yemen as Assamese 32: ay_BO Aymara Bolivia 33: ay_PE Peru 34: az_AZ Azerbaijani Azerbaijan ba Bashkir 35: be_BY Byelorussian Belarus 36: bg_BG Bulgarian Bulgaria 37: bg_MD Moldova 38: bh_BD Bihari Bangladesh 39: bi_VU Bislama Vanuatu 40: bn_BD Bengali Bangladesh 41: bo_CN Tibetan China 42: br_FR Breton France 43: ca_ES Catalan Spain 44: co_FR Corsican France 45: cs_CZ Czech Czech Republic 46: cy_GB Welsh United Kingdom 47: da_DK Danish Denmark 48: da_FO FO 49: da_GL GL 50: de_AT German Austria 51: de_BE Belgium 52: de_CH Switzerland 53: de_DE Germany 54: de_IT Italy 55: de_LI Liechtenstein 56: de_LU Luxembourg 57: de_NA Namibia 58: dz_BT Bhutani Bhutan 59: el_CY Greek Cyprus 60: el_GR Greece 61: en_AE English United Arab Emirates 62: en_AG AG 63: en_AN Netherlands Antilles 64: en_AS AS 65: en_AU Australia 66: en_AW Aruba 67: en_BB Barbados 68: en_BD Bangladesh 69: en_BH Bahrain 70: en_BM Bermuda 71: en_BN Brunei 72: en_BS Bahamas 73: en_BT Bhutan 74: en_BW Botswana 75: en_BZ Belize 76: en_CA Canada 77: en_CC CC 78: en_CK CK 79: en_CM Cameroon 80: en_CX CX 81: en_CY Cyprus 82: en_DM Dominica 83: en_EG Egypt 84: en_ER Eritrea 85: en_ET Ethiopia 86: en_FJ Fiji 87: en_FK FK 88: en_FM Micronesia 89: en_GB United Kingdom 90: en_GD GD 91: en_GH Ghana 92: en_GI GI 93: en_GM Gambia 94: en_GP Guadeloupe 95: en_GU GU 96: en_GY Guyana 97: en_HK Hong Kong 98: en_ID Indonesia 99: en_IE Ireland 100: en_IN India 101: en_IO IO 102: en_JM Jamaica 103: en_KE Kenya 104: en_KI Kiribati 105: en_KN KN 106: en_KW Kuwait 107: en_KY KY 108: en_LB Lebanon 109: en_LC LC 110: en_LK Sri Lanka 111: en_LR Liberia 112: en_LS Lesotho 113: en_LY Libya 114: en_MC Monaco 115: en_MG Madagascar 116: en_MS Montserrat 117: en_MT Malta 118: en_MU Mauritius 119: en_MW MW 120: en_MY Malaysia 121: en_NA Namibia 122: en_NF NF 123: en_NG Nigeria 124: en_NR NR 125: en_NU Niue 126: en_NZ New Zealand 127: en_OM Oman 128: en_PA Panama 129: en_PG Papua New Guinea 130: en_PH Philippines 131: en_PK Pakistan 132: en_PM PM 133: en_PN PN 134: en_PR Puerto Rico 135: en_PW PW 136: en_QA Qatar 137: en_RW Rwanda 138: en_SB SB 139: en_SC Seychelles 140: en_SG Singapore 141: en_SH SH 142: en_SL Sierra Leone 143: en_SO Somalia 144: en_SR Suriname 145: en_SZ Swaziland 146: en_TC TC 147: en_TK Tokelau 148: en_TO Tonga 149: en_TT Trinidad and Tobago 150: en_TV TV 151: en_TZ Tanzania 152: en_UG Uganda 153: en_UM UM 154: en_US United States 155: en_VC VC 156: en_VG British Virgin Islands 157: en_VI U.S. Virgin Islands 158: en_VU Vanuatu 159: en_WS WS 160: en_ZA South Africa 161: en_ZM Zambia 162: en_ZW Zimbabwe eo Esperanto 163: es_AD Spanish Andorra 164: es_AR Argentina 165: es_BO Bolivia 166: es_BZ Belize 167: es_CL Chile 168: es_CO Colombia 169: es_CR Costa Rica 170: es_CU Cuba 171: es_DO Dominican Republic 172: es_EC Ecuador 173: es_ES Spain 174: es_GI GI 175: es_GQ Equatorial Guinea 176: es_GT Guatemala 177: es_HN Honduras 178: es_MA Morocco 179: es_MX Mexico 180: es_NI Nicaragua 181: es_PA Panama 182: es_PE Peru 183: es_PH Philippines 184: es_PR Puerto Rico 185: es_PY Paraguay 186: es_SR Suriname 187: es_SV El Salvador 188: es_US United States 189: es_UY Uruguay 190: es_VE Venezuela 191: et_EE Estonian Estonia 192: eu_ES Basque Spain 193: eu_FR France 194: fa_IR Persian Iran 195: fi_FI Finnish Finland 196: fj_FJ Fiji Fiji 197: fo_FO Faroese FO 198: fr_AD French Andorra 199: fr_BE Belgium 200: fr_BF Burkina Faso 201: fr_BI Burundi 202: fr_BJ Benin 203: fr_CA Canada 204: fr_CF Central African Republic 205: fr_CG Congo 206: fr_CH Switzerland 207: fr_CI C?te d'Ivoire 208: fr_CM Cameroon 209: fr_DJ Djibouti 210: fr_DM Dominica 211: fr_DZ Algeria 212: fr_EG Egypt 213: fr_EH Western Sahara 214: fr_FR France 215: fr_FX FX 216: fr_GA Gabon 217: fr_GD GD 218: fr_GF French Guiana 219: fr_GN Guinea 220: fr_GP Guadeloupe 221: fr_HT Haiti 222: fr_IT Italy 223: fr_KM Comoros 224: fr_LA Laos 225: fr_LB Lebanon 226: fr_LC LC 227: fr_LU Luxembourg 228: fr_MA Morocco 229: fr_MC Monaco 230: fr_MG Madagascar 231: fr_ML Mali 232: fr_MQ Martinique 233: fr_MR Mauritania 234: fr_MU Mauritius 235: fr_NE Niger 236: fr_PF French Polynesia 237: fr_PM PM 238: fr_RE RE 239: fr_RW Rwanda 240: fr_SC Seychelles 241: fr_SN Senegal 242: fr_TD Chad 243: fr_TF French Southern Territories 244: fr_TG Togo 245: fr_VN Vietnam 246: fr_VU Vanuatu 247: fr_WF WF 248: fr_YT Mayotte 249: fr_ZR Zaire 250: fy_NL Frisian Netherlands 251: ga_IE Irish Ireland 252: gd_GB Scots Gaelic United Kingdom 253: gl_ES Galician Spain 254: gn_PY Guarani Paraguay 255: gu_IN Gujarati India 256: ha_NE Hausa Niger 257: ha_NG Nigeria he Hebrew 258: hi_BD Hindi Bangladesh 259: hi_FJ Fiji 260: hi_GY Guyana 261: hi_IN India 262: hi_MU Mauritius 263: hi_SR Suriname 264: hr_BA Croatian Bosnia and Herzegovina 265: hr_HR Croatia 266: hu_HU Hungarian Hungary 267: hu_RO Romania 268: hu_SK Slovakia 269: hu_YU Yugoslavia 270: hy_AM Armenian Armenia 271: hy_AZ Azerbaijan 272: hy_GE Georgia ia Interlingua id Indonesian ie Interlingue 273: ik_GL Inupiak GL 274: in_ID Indonesian Indonesia 275: is_IS Icelandic Iceland 276: it_CH Italian Switzerland 277: it_EH Western Sahara 278: it_ER Eritrea 279: it_IT Italy 280: it_LY Libya 281: it_MC Monaco 282: it_MT Malta 283: it_SM SM 284: it_SO Somalia 285: it_VA Vatican iu Inuktitut 286: iw_IL Hebrew Israel 287: ja_JP Japanese Japan 288: ji_IL Yiddish Israel jw Javanese 289: ka_GE Georgian Georgia 290: kk_KZ Kazakh Kazakhstan 291: kl_GL Greenlandic GL 292: km_KH Cambodian Cambodia 293: kn_IN Kannada India 294: ko_KP Korean North Korea 295: ko_KR South Korea 296: ks_IN Kashmiri India 297: ku_IQ Kurdish Iraq 298: ku_IR Iran 299: ku_TR Turkey 300: ky_KG Kirghiz Kyrgyzstan 301: la_VA Latin Vatican ln Lingala 302: lo_LA Laothian Laos 303: lt_LT Lithuanian Lithuania 304: lt_LV Latvia 305: lv_LV Latvian (Lettish) Latvia 306: mg_MG Malagasy Madagascar 307: mg_YT Mayotte 308: mi_CK Maori CK 309: mi_NZ New Zealand 310: mi_TK Tokelau 311: mk_BA Macedonian Bosnia and Herzegovina 312: mk_MK Macedonia 313: mk_YU Yugoslavia 314: ml_IN Malayalam India 315: mn_MN Mongolian Mongolia 316: mo_MD Moldavian Moldova 317: mr_IN Marathi India 318: ms_BN Malay Brunei 319: ms_MY Malaysia 320: ms_SG Singapore 321: mt_MT Maltese Malta 322: my_MM Burmese Myanmar 323: na_NR Nauru NR 324: ne_BT Nepali Bhutan 325: ne_IN India 326: ne_NP Nepal 327: nl_AN Dutch Netherlands Antilles 328: nl_AW Aruba 329: nl_BE Belgium 330: nl_ID Indonesia 331: nl_NL Netherlands 332: nl_SR Suriname 333: no_BV Norwegian BV 334: no_NO Norway 335: no_SJ SJ oc Occitan om Oromo (Afan) 336: or_IN Oriya India 337: pa_IN Punjabi India 338: pa_PK Pakistan 339: pl_LT Polish Lithuania 340: pl_PL Poland 341: pl_SK Slovakia 342: ps_AF Pashto (Pushto) Afghanistan 343: ps_PK Pakistan 344: pt_AO Portuguese Angola 345: pt_BR Brazil 346: pt_CV Cape Verde 347: pt_GW Guinea-Bissau 348: pt_MO MO 349: pt_MZ Mozambique 350: pt_PT Portugal 351: pt_ST ST 352: qu_BO Quechua Bolivia 353: qu_EC Ecuador 354: qu_PE Peru 355: rm_CH Rhaeto-Romance Switzerland 356: rn_AI Kirundi Anguilla 357: rn_BI Burundi 358: ro_MD Romanian Moldova 359: ro_RO Romania 360: ru_AM Russian Armenia 361: ru_AZ Azerbaijan 362: ru_BY Belarus 363: ru_EE Estonia 364: ru_GE Georgia 365: ru_KZ Kazakhstan 366: ru_LT Lithuania 367: ru_LV Latvia 368: ru_MN Mongolia 369: ru_RU Russia 370: ru_TJ Tajikistan 371: ru_TM Turkmenistan 372: ru_UA Ukraine 373: ru_UZ Uzbekistan 374: rw_RW Kinyarwanda Rwanda 375: sa_IN Sanskrit India 376: sd_PK Sindhi Pakistan 377: sg_CF Sangho Central African Republic 378: sh_BA Serbo-Croatian Bosnia and Herzegovina 379: sh_MK Macedonia 380: sh_SK Slovakia 381: sh_YU Yugoslavia 382: si_LK Sinhalese Sri Lanka 383: sk_CZ Slovak Czech Republic 384: sk_SK Slovakia 385: sl_BA Slovenian Bosnia and Herzegovina 386: sl_SI Slovenia 387: sm_AS Samoan AS 388: sm_WS WS 389: sn_ZW Shona Zimbabwe 390: so_DJ Somali Djibouti 391: so_SO Somalia 392: sq_AL Albanian Albania 393: sq_BA Bosnia and Herzegovina 394: sr_BA Serbian Bosnia and Herzegovina 395: sr_YU Yugoslavia 396: ss_SZ Siswati Swaziland 397: st_LS Sesotho Lesotho 398: su_SD Sundanese Sudan 399: sv_FI Swedish Finland 400: sv_SE Sweden 401: sw_BI Swahili Burundi 402: sw_KE Kenya 403: sw_TZ Tanzania 404: sw_UG Uganda 405: sw_YT Mayotte 406: sw_ZR Zaire 407: ta_IN Tamil India 408: ta_LK Sri Lanka 409: ta_RE RE 410: ta_SG Singapore 411: te_IN Telugu India 412: tg_TJ Tajik Tajikistan 413: th_TH Thai Thailand 414: ti_ER Tigrinya Eritrea 415: tk_IQ Turkmen Iraq 416: tk_TM Turkmenistan 417: tl_PH Tagalog Philippines 418: tn_BW Setswana Botswana 419: to_TO Tonga Tonga 420: tr_BG Turkish Bulgaria 421: tr_CY Cyprus 422: tr_MK Macedonia 423: tr_TR Turkey ts Tsonga tt Tatar tw Twi ug Uighur 424: uk_UA Ukrainian Ukraine 425: ur_GY Urdu Guyana 426: ur_PK Pakistan 427: uz_TJ Uzbek Tajikistan 428: uz_UZ Uzbekistan 429: vi_VN Vietnamese Vietnam vo Volapuk 430: wo_GM Wolof Gambia xh Xhosa yi Yiddish 431: yo_NG Yoruba Nigeria za Zhuang 432: zh_BN Chinese Brunei 433: zh_CN China 434: zh_HK Hong Kong 435: zh_MO MO 436: zh_SG Singapore 437: zh_TW Taiwan 438: zh_VN Vietnam zu Zulu --------------------------------------------------------- >Importance: Normal >Subject: Re: UPD> Re: UPDF open standard for locales >To: "Akio Kido" >Cc: norbertschade@oaktech.com, , Jim Sommer >From: "Mark VanderWiele" >Date: Thu, 19 Apr 2001 13:57:36 -0500 >X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/19/2001 02:56:03 PM >MIME-Version: 1.0 > > >Akio: What should we do about kw its not in the ISO languages? Also, was >SU really SD. see info below. > >Jim: Thank You. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com > > >Jim Sommer on 04/19/2001 08:05:53 AM > >To: Mark VanderWiele/Austin/IBM@IBMUS, norbertschade@oaktech.com, > >cc: >Subject: Re: UPD> Re: UPDF open standard for locales > > > >Here's the translation of the locales that Mark listed: > >arIN-Arabic-India >arSD-Arabic-Sudan >deBE-German-Belgium >enBE-English-Belgium >enBW-English-Botswana >enHK-English-Hong_Kong >enIN-English-India >enSG-English-Singapore >enZW-English-Zimbabwe >esGT-Spanish-Guatemala (this was in the original list) >esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original >list) >faIN-Farsi-India >glES-Galician-Spain (from the Linux web site, not Mark's list) >gvGB-Manx_Gaelic-United_Kingdon >knIN-Kannada-India (this was in the original list) >kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) >psIN-Pashto-India >ruUA-Russian-Ukraine >sdIN-Sindhi-India >shYU-Serbo-Croatian-Yugoslavia >srYU-Serbian-Yugoslavia > >I couldn't find the country SU but looking at the Linux web site, I figured >it was a typo and supposed to be SD. > >enZA was in the original list but from the Linux web site I found that enZW >was missing. > >I couldn't find the language fs but found that faIN was missing. > >I don't think we should include kwGB since Cornish isn't in the ISO >language list. > >Jim > >At 4/18/01 08:07 PM, Mark VanderWiele wrote: >>Norbert: I will try to get the following information into the desired >>format. However, I wanted to let you know that the Linux globaization >work >>is tackling the same problem and has another locals list. They have >>identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >>esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >>your list of locals. >> >>Regards, >>Mark VanderWiele >>IBM, Linux Technology Center >>512-838-4779, t/l 678 >>MARKV@IBMUS >>email: markv@us.ibm.com >>---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >>04/18/2001 06:33 PM --------------------------- >> >>Akio Kido@IBMJP >>04/16/2001 09:13 PM >> >>To: Mark VanderWiele/Austin/IBM@IBMUS >>cc: George Kraft/Austin/IBM@IBMUS >>From: Akio Kido/Japan/IBM@IBMJP >>Subject: Re: UPDF open standard for locales (Document link: Mark >> VanderWiele) >> >>Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >>week and restricted access to IBM network ). >> >>Annex B of LI18NUX2000 Globalization specification specified the list of >>locales that should be supported by >>LI18NUX2000 confomant distribution. Please refer to >>http://www.li18nux.org/li18nux2k/ >> >>As far as I checked the LI18NUX2000, the following locales are in the >>LI18NUX2000 but not in the list >>attached. >> >>arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >>gvGB, knIN, >>kwGB, psIN, ruUA, sdIN, shYU, srYU. >> >>Best regards, >>Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >>1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >>E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 >> >> >>From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 >> >>To: Akio Kido/Japan/IBM@IBMJP >>cc: George Kraft/Austin/IBM@IBMUS >>From: Mark VanderWiele/Austin/IBM@IBMUS >>Subject: Re: UPDF open standard for locales >> >> >> >>Kido-san: The following list all the way at the bottom of this note is a >>proposed list to identify translations in the Universal Printer Driver >>Format standard being worked on by the Printer Working Group >(www.pwg.org). >>Please verify its completeness, Forward to other IBM interested parties, & >>and or propose a better source. I am told you may be working on an I18N >>standard for locals. Is this true? Is there another list I should be >>looking at? >> >>Thank you, >> >>Regards, >>Mark VanderWiele >>IBM, Linux Technology Center >>512-838-4779, t/l 678 >>MARKV@IBMUS >>email: markv@us.ibm.com > > > -------------- next part -------------- Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) 1: Andorra (AD: fr es) French Spanish 2: United Arab Emirates (AE: ar en) Arabic English 3: Afghanistan (AF: ps) Pashto (Pushto) 4: AG (AG: en) English 5: Anguilla (AI: rn) Kirundi 6: Albania (AL: sq) Albanian 7: Armenia (AM: hy ru) Armenian Russian 8: Netherlands Antilles (AN: nl en) Dutch English 9: Angola (AO: pt) Portuguese 10: AQ (AQ:) 11: Argentina (AR: es) Spanish 12: AS (AS: en sm) English Samoan 13: Austria (AT: de) German 14: Australia (AU: en) English 15: Aruba (AW: nl en) Dutch English 16: Azerbaijan (AZ: az hy ru) Azerbaijani Armenian Russian 17: Bosnia and Herzegovina (BA: sr sh hr sl mk sq) Serbian Serbo-Croatian Croatian Slovenian Macedonian Albanian 18: Barbados (BB: en) English 19: Bangladesh (BD: bn hi bh en) Bengali Hindi Bihari English 20: Belgium (BE: fr nl de) French Dutch German 21: Burkina Faso (BF: fr) French 22: Bulgaria (BG: bg tr) Bulgarian Turkish 23: Bahrain (BH: ar en) Arabic English 24: Burundi (BI: rn fr sw) Kirundi French Swahili 25: Benin (BJ: fr) French 26: Bermuda (BM: en) English 27: Brunei (BN: ms en zh) Malay English Chinese 28: Bolivia (BO: es ay qu) Spanish Aymara Quechua 29: Brazil (BR: pt) Portuguese 30: Bahamas (BS: en) English 31: Bhutan (BT: dz en ne) Bhutani English Nepali 32: BV (BV: no) Norwegian 33: Botswana (BW: en tn) English Setswana 34: Belarus (BY: be ru) Byelorussian Russian 35: Belize (BZ: en es) English Spanish 36: Canada (CA: en fr) English French 37: CC (CC: en) English 38: Central African Republic (CF: fr sg) French Sangho 39: Congo (CG: fr) French 40: Switzerland (CH: fr de it rm) French German Italian Rhaeto-Romance 41: C?te d'Ivoire (CI: fr) French 42: CK (CK: mi en) Maori English 43: Chile (CL: es) Spanish 44: Cameroon (CM: en fr) English French 45: China (CN: zh bo) Chinese Tibetan 46: Colombia (CO: es) Spanish 47: Costa Rica (CR: es) Spanish 48: Cuba (CU: es) Spanish 49: Cape Verde (CV: pt) Portuguese 50: CX (CX: en) English 51: Cyprus (CY: el tr en) Greek Turkish English 52: Czech Republic (CZ: cs sk) Czech Slovak 53: Germany (DE: de) German 54: Djibouti (DJ: ar fr so) Arabic French Somali 55: Denmark (DK: da) Danish 56: Dominica (DM: en fr) English French 57: Dominican Republic (DO: es) Spanish 58: Algeria (DZ: ar fr) Arabic French 59: Ecuador (EC: es qu) Spanish Quechua 60: Estonia (EE: et ru) Estonian Russian 61: Egypt (EG: ar en fr) Arabic English French 62: Western Sahara (EH: ar fr it) Arabic French Italian 63: Eritrea (ER: am ti ar en it) Amharic Tigrinya Arabic English Italian 64: Spain (ES: es eu ca gl) Spanish Basque Catalan Galician 65: Ethiopia (ET: am ar en) Amharic Arabic English 66: Finland (FI: fi sv) Finnish Swedish 67: Fiji (FJ: en fj hi) English Fiji Hindi 68: FK (FK: en) English 69: Micronesia (FM: en) English 70: FO (FO: fo da) Faroese Danish 71: France (FR: fr eu br co) French Basque Breton Corsican 72: FX (FX: fr) French 73: Gabon (GA: fr) French 74: United Kingdom (GB: en gd cy) English Scots Gaelic Welsh 75: GD (GD: en fr) English French 76: Georgia (GE: ka hy ru) Georgian Armenian Russian 77: French Guiana (GF: fr) French 78: Ghana (GH: en) English 79: GI (GI: en es) English Spanish 80: GL (GL: da ik kl) Danish Inupiak Greenlandic 81: Gambia (GM: en wo) English Wolof 82: Guinea (GN: fr) French 83: Guadeloupe (GP: fr en) French English 84: Equatorial Guinea (GQ: es) Spanish 85: Greece (GR: el) Greek 86: GS (GS:) 87: Guatemala (GT: es) Spanish 88: GU (GU: en) English 89: Guinea-Bissau (GW: pt) Portuguese 90: Guyana (GY: en hi ur) English Hindi Urdu 91: Hong Kong (HK: zh en) Chinese English 92: HM (HM:) 93: Honduras (HN: es) Spanish 94: Croatia (HR: hr) Croatian 95: Haiti (HT: fr) French 96: Hungary (HU: hu) Hungarian 97: Indonesia (ID: in en nl) Indonesian English Dutch 98: Ireland (IE: en ga) English Irish 99: Israel (IL: iw ar ji) Hebrew Arabic Yiddish 100: India (IN: hi en gu kn ks ml mr ne or pa sa ta te) Hindi English Gujarati Kannada Kashmiri Malayalam Marathi Nepali Oriya Punjabi Sanskrit Tamil Telugu 101: IO (IO: en) English 102: Iraq (IQ: ar ku tk) Arabic Kurdish Turkmen 103: Iran (IR: fa ar ku) Persian Arabic Kurdish 104: Iceland (IS: is) Icelandic 105: Italy (IT: it fr de) Italian French German 106: Jamaica (JM: en) English 107: Jordan (JO: ar) Arabic 108: Japan (JP: ja) Japanese 109: Kenya (KE: en sw) English Swahili 110: Kyrgyzstan (KG: ky) Kirghiz 111: Cambodia (KH: km) Cambodian 112: Kiribati (KI: en) English 113: Comoros (KM: fr ar) French Arabic 114: KN (KN: en) English 115: North Korea (KP: ko) Korean 116: South Korea (KR: ko) Korean 117: Kuwait (KW: ar en) Arabic English 118: KY (KY: en) English 119: Kazakhstan (KZ: kk ru) Kazakh Russian 120: Laos (LA: lo fr) Laothian French 121: Lebanon (LB: ar en fr) Arabic English French 122: LC (LC: en fr) English French 123: Liechtenstein (LI: de) German 124: Sri Lanka (LK: ta si en) Tamil Sinhalese English 125: Liberia (LR: en) English 126: Lesotho (LS: st en) Sesotho English 127: Lithuania (LT: lt ru pl) Lithuanian Russian Polish 128: Luxembourg (LU: fr de) French German 129: Latvia (LV: lv lt ru) Latvian (Lettish) Lithuanian Russian 130: Libya (LY: ar en it) Arabic English Italian 131: Morocco (MA: ar fr es) Arabic French Spanish 132: Monaco (MC: fr en it) French English Italian 133: Moldova (MD: mo ro bg) Moldavian Romanian Bulgarian 134: Madagascar (MG: mg en fr) Malagasy English French 135: MH (MH:) 136: Macedonia (MK: mk sh tr) Macedonian Serbo-Croatian Turkish 137: Mali (ML: fr) French 138: Myanmar (MM: my) Burmese 139: Mongolia (MN: mn ru) Mongolian Russian 140: MO (MO: zh pt) Chinese Portuguese 141: MP (MP:) 142: Martinique (MQ: fr) French 143: Mauritania (MR: ar fr) Arabic French 144: Montserrat (MS: en) English 145: Malta (MT: mt en it) Maltese English Italian 146: Mauritius (MU: en fr hi) English French Hindi 147: MV (MV:) 148: MW (MW: en) English 149: Mexico (MX: es) Spanish 150: Malaysia (MY: ms en) Malay English 151: Mozambique (MZ: pt) Portuguese 152: Namibia (NA: en af de) English Afrikaans German 153: New Caledonia (NC:) 154: Niger (NE: fr ha) French Hausa 155: NF (NF: en) English 156: Nigeria (NG: en ha yo) English Hausa Yoruba 157: Nicaragua (NI: es) Spanish 158: Netherlands (NL: nl fy) Dutch Frisian 159: Norway (NO: no) Norwegian 160: Nepal (NP: ne) Nepali 161: NR (NR: na en) Nauru English 162: Niue (NU: en) English 163: New Zealand (NZ: en mi) English Maori 164: Oman (OM: ar en) Arabic English 165: Panama (PA: es en) Spanish English 166: Peru (PE: es qu ay) Spanish Quechua Aymara 167: French Polynesia (PF: fr) French 168: Papua New Guinea (PG: en) English 169: Philippines (PH: en tl es) English Tagalog Spanish 170: Pakistan (PK: ur en ps pa sd) Urdu English Pashto (Pushto) Punjabi Sindhi 171: Poland (PL: pl) Polish 172: PM (PM: fr en) French English 173: PN (PN: en) English 174: Puerto Rico (PR: es en) Spanish English 175: Portugal (PT: pt) Portuguese 176: PW (PW: en) English 177: Paraguay (PY: es gn) Spanish Guarani 178: Qatar (QA: ar en) Arabic English 179: RE (RE: fr ta) French Tamil 180: Romania (RO: ro hu) Romanian Hungarian 181: Russia (RU: ru) Russian 182: Rwanda (RW: en fr rw) English French Kinyarwanda 183: Saudi Arabia (SA: ar) Arabic 184: SB (SB: en) English 185: Seychelles (SC: en fr) English French 186: Sudan (SD: ar su) Arabic Sundanese 187: Sweden (SE: sv) Swedish 188: Singapore (SG: zh en ms ta) Chinese English Malay Tamil 189: SH (SH: en) English 190: Slovenia (SI: sl) Slovenian 191: SJ (SJ: no) Norwegian 192: Slovakia (SK: sk hu pl sh) Slovak Hungarian Polish Serbo-Croatian 193: Sierra Leone (SL: en) English 194: SM (SM: it) Italian 195: Senegal (SN: fr) French 196: Somalia (SO: ar en it so) Arabic English Italian Somali 197: Suriname (SR: nl en es hi) Dutch English Spanish Hindi 198: ST (ST: pt) Portuguese 199: El Salvador (SV: es) Spanish 200: Syria (SY: ar) Arabic 201: Swaziland (SZ: en ss) English Siswati 202: TC (TC: en) English 203: Chad (TD: fr ar) French Arabic 204: French Southern Territories (TF: fr) French 205: Togo (TG: fr) French 206: Thailand (TH: th) Thai 207: Tajikistan (TJ: tg ru uz) Tajik Russian Uzbek 208: Tokelau (TK: en mi) English Maori 209: Turkmenistan (TM: tk ru) Turkmen Russian 210: Tunisia (TN: ar) Arabic 211: Tonga (TO: en to) English Tonga 212: East Timor (TP:) 213: Turkey (TR: tr ku) Turkish Kurdish 214: Trinidad and Tobago (TT: en) English 215: TV (TV: en) English 216: Taiwan (TW: zh) Chinese 217: Tanzania (TZ: en sw) English Swahili 218: Ukraine (UA: uk ru) Ukrainian Russian 219: Uganda (UG: en sw) English Swahili 220: UM (UM: en) English 221: United States (US: en es) English Spanish 222: Uruguay (UY: es) Spanish 223: Uzbekistan (UZ: uz ru) Uzbek Russian 224: Vatican (VA: la it) Latin Italian 225: VC (VC: en) English 226: Venezuela (VE: es) Spanish 227: British Virgin Islands (VG: en) English 228: U.S. Virgin Islands (VI: en) English 229: Vietnam (VN: vi zh fr) Vietnamese Chinese French 230: Vanuatu (VU: en fr bi) English French Bislama 231: WF (WF: fr) French 232: WS (WS: en sm) English Samoan 233: Yemen (YE: ar) Arabic 234: Mayotte (YT: fr mg sw) French Malagasy Swahili 235: Yugoslavia (YU: sr sh mk hu) Serbian Serbo-Croatian Macedonian Hungarian 236: South Africa (ZA: af en) Afrikaans English 237: Zambia (ZM: en) English 238: Zaire (ZR: fr sw) French Swahili 239: Zimbabwe (ZW: en sn) English Shona aa Afar ab Abkhazian Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) 1: af_NA Afrikaans Namibia 2: af_ZA South Africa 3: am_ER Amharic Eritrea 4: am_ET Ethiopia 5: ar_AE Arabic United Arab Emirates 6: ar_BH Bahrain 7: ar_DJ Djibouti 8: ar_DZ Algeria 9: ar_EG Egypt 10: ar_EH Western Sahara 11: ar_ER Eritrea 12: ar_ET Ethiopia 13: ar_IL Israel 14: ar_IQ Iraq 15: ar_IR Iran 16: ar_JO Jordan 17: ar_KM Comoros 18: ar_KW Kuwait 19: ar_LB Lebanon 20: ar_LY Libya 21: ar_MA Morocco 22: ar_MR Mauritania 23: ar_OM Oman 24: ar_QA Qatar 25: ar_SA Saudi Arabia 26: ar_SD Sudan 27: ar_SO Somalia 28: ar_SY Syria 29: ar_TD Chad 30: ar_TN Tunisia 31: ar_YE Yemen as Assamese 32: ay_BO Aymara Bolivia 33: ay_PE Peru 34: az_AZ Azerbaijani Azerbaijan ba Bashkir 35: be_BY Byelorussian Belarus 36: bg_BG Bulgarian Bulgaria 37: bg_MD Moldova 38: bh_BD Bihari Bangladesh 39: bi_VU Bislama Vanuatu 40: bn_BD Bengali Bangladesh 41: bo_CN Tibetan China 42: br_FR Breton France 43: ca_ES Catalan Spain 44: co_FR Corsican France 45: cs_CZ Czech Czech Republic 46: cy_GB Welsh United Kingdom 47: da_DK Danish Denmark 48: da_FO FO 49: da_GL GL 50: de_AT German Austria 51: de_BE Belgium 52: de_CH Switzerland 53: de_DE Germany 54: de_IT Italy 55: de_LI Liechtenstein 56: de_LU Luxembourg 57: de_NA Namibia 58: dz_BT Bhutani Bhutan 59: el_CY Greek Cyprus 60: el_GR Greece 61: en_AE English United Arab Emirates 62: en_AG AG 63: en_AN Netherlands Antilles 64: en_AS AS 65: en_AU Australia 66: en_AW Aruba 67: en_BB Barbados 68: en_BD Bangladesh 69: en_BH Bahrain 70: en_BM Bermuda 71: en_BN Brunei 72: en_BS Bahamas 73: en_BT Bhutan 74: en_BW Botswana 75: en_BZ Belize 76: en_CA Canada 77: en_CC CC 78: en_CK CK 79: en_CM Cameroon 80: en_CX CX 81: en_CY Cyprus 82: en_DM Dominica 83: en_EG Egypt 84: en_ER Eritrea 85: en_ET Ethiopia 86: en_FJ Fiji 87: en_FK FK 88: en_FM Micronesia 89: en_GB United Kingdom 90: en_GD GD 91: en_GH Ghana 92: en_GI GI 93: en_GM Gambia 94: en_GP Guadeloupe 95: en_GU GU 96: en_GY Guyana 97: en_HK Hong Kong 98: en_ID Indonesia 99: en_IE Ireland 100: en_IN India 101: en_IO IO 102: en_JM Jamaica 103: en_KE Kenya 104: en_KI Kiribati 105: en_KN KN 106: en_KW Kuwait 107: en_KY KY 108: en_LB Lebanon 109: en_LC LC 110: en_LK Sri Lanka 111: en_LR Liberia 112: en_LS Lesotho 113: en_LY Libya 114: en_MC Monaco 115: en_MG Madagascar 116: en_MS Montserrat 117: en_MT Malta 118: en_MU Mauritius 119: en_MW MW 120: en_MY Malaysia 121: en_NA Namibia 122: en_NF NF 123: en_NG Nigeria 124: en_NR NR 125: en_NU Niue 126: en_NZ New Zealand 127: en_OM Oman 128: en_PA Panama 129: en_PG Papua New Guinea 130: en_PH Philippines 131: en_PK Pakistan 132: en_PM PM 133: en_PN PN 134: en_PR Puerto Rico 135: en_PW PW 136: en_QA Qatar 137: en_RW Rwanda 138: en_SB SB 139: en_SC Seychelles 140: en_SG Singapore 141: en_SH SH 142: en_SL Sierra Leone 143: en_SO Somalia 144: en_SR Suriname 145: en_SZ Swaziland 146: en_TC TC 147: en_TK Tokelau 148: en_TO Tonga 149: en_TT Trinidad and Tobago 150: en_TV TV 151: en_TZ Tanzania 152: en_UG Uganda 153: en_UM UM 154: en_US United States 155: en_VC VC 156: en_VG British Virgin Islands 157: en_VI U.S. Virgin Islands 158: en_VU Vanuatu 159: en_WS WS 160: en_ZA South Africa 161: en_ZM Zambia 162: en_ZW Zimbabwe eo Esperanto 163: es_AD Spanish Andorra 164: es_AR Argentina 165: es_BO Bolivia 166: es_BZ Belize 167: es_CL Chile 168: es_CO Colombia 169: es_CR Costa Rica 170: es_CU Cuba 171: es_DO Dominican Republic 172: es_EC Ecuador 173: es_ES Spain 174: es_GI GI 175: es_GQ Equatorial Guinea 176: es_GT Guatemala 177: es_HN Honduras 178: es_MA Morocco 179: es_MX Mexico 180: es_NI Nicaragua 181: es_PA Panama 182: es_PE Peru 183: es_PH Philippines 184: es_PR Puerto Rico 185: es_PY Paraguay 186: es_SR Suriname 187: es_SV El Salvador 188: es_US United States 189: es_UY Uruguay 190: es_VE Venezuela 191: et_EE Estonian Estonia 192: eu_ES Basque Spain 193: eu_FR France 194: fa_IR Persian Iran 195: fi_FI Finnish Finland 196: fj_FJ Fiji Fiji 197: fo_FO Faroese FO 198: fr_AD French Andorra 199: fr_BE Belgium 200: fr_BF Burkina Faso 201: fr_BI Burundi 202: fr_BJ Benin 203: fr_CA Canada 204: fr_CF Central African Republic 205: fr_CG Congo 206: fr_CH Switzerland 207: fr_CI C?te d'Ivoire 208: fr_CM Cameroon 209: fr_DJ Djibouti 210: fr_DM Dominica 211: fr_DZ Algeria 212: fr_EG Egypt 213: fr_EH Western Sahara 214: fr_FR France 215: fr_FX FX 216: fr_GA Gabon 217: fr_GD GD 218: fr_GF French Guiana 219: fr_GN Guinea 220: fr_GP Guadeloupe 221: fr_HT Haiti 222: fr_IT Italy 223: fr_KM Comoros 224: fr_LA Laos 225: fr_LB Lebanon 226: fr_LC LC 227: fr_LU Luxembourg 228: fr_MA Morocco 229: fr_MC Monaco 230: fr_MG Madagascar 231: fr_ML Mali 232: fr_MQ Martinique 233: fr_MR Mauritania 234: fr_MU Mauritius 235: fr_NE Niger 236: fr_PF French Polynesia 237: fr_PM PM 238: fr_RE RE 239: fr_RW Rwanda 240: fr_SC Seychelles 241: fr_SN Senegal 242: fr_TD Chad 243: fr_TF French Southern Territories 244: fr_TG Togo 245: fr_VN Vietnam 246: fr_VU Vanuatu 247: fr_WF WF 248: fr_YT Mayotte 249: fr_ZR Zaire 250: fy_NL Frisian Netherlands 251: ga_IE Irish Ireland 252: gd_GB Scots Gaelic United Kingdom 253: gl_ES Galician Spain 254: gn_PY Guarani Paraguay 255: gu_IN Gujarati India 256: ha_NE Hausa Niger 257: ha_NG Nigeria he Hebrew 258: hi_BD Hindi Bangladesh 259: hi_FJ Fiji 260: hi_GY Guyana 261: hi_IN India 262: hi_MU Mauritius 263: hi_SR Suriname 264: hr_BA Croatian Bosnia and Herzegovina 265: hr_HR Croatia 266: hu_HU Hungarian Hungary 267: hu_RO Romania 268: hu_SK Slovakia 269: hu_YU Yugoslavia 270: hy_AM Armenian Armenia 271: hy_AZ Azerbaijan 272: hy_GE Georgia ia Interlingua id Indonesian ie Interlingue 273: ik_GL Inupiak GL 274: in_ID Indonesian Indonesia 275: is_IS Icelandic Iceland 276: it_CH Italian Switzerland 277: it_EH Western Sahara 278: it_ER Eritrea 279: it_IT Italy 280: it_LY Libya 281: it_MC Monaco 282: it_MT Malta 283: it_SM SM 284: it_SO Somalia 285: it_VA Vatican iu Inuktitut 286: iw_IL Hebrew Israel 287: ja_JP Japanese Japan 288: ji_IL Yiddish Israel jw Javanese 289: ka_GE Georgian Georgia 290: kk_KZ Kazakh Kazakhstan 291: kl_GL Greenlandic GL 292: km_KH Cambodian Cambodia 293: kn_IN Kannada India 294: ko_KP Korean North Korea 295: ko_KR South Korea 296: ks_IN Kashmiri India 297: ku_IQ Kurdish Iraq 298: ku_IR Iran 299: ku_TR Turkey 300: ky_KG Kirghiz Kyrgyzstan 301: la_VA Latin Vatican ln Lingala 302: lo_LA Laothian Laos 303: lt_LT Lithuanian Lithuania 304: lt_LV Latvia 305: lv_LV Latvian (Lettish) Latvia 306: mg_MG Malagasy Madagascar 307: mg_YT Mayotte 308: mi_CK Maori CK 309: mi_NZ New Zealand 310: mi_TK Tokelau 311: mk_BA Macedonian Bosnia and Herzegovina 312: mk_MK Macedonia 313: mk_YU Yugoslavia 314: ml_IN Malayalam India 315: mn_MN Mongolian Mongolia 316: mo_MD Moldavian Moldova 317: mr_IN Marathi India 318: ms_BN Malay Brunei 319: ms_MY Malaysia 320: ms_SG Singapore 321: mt_MT Maltese Malta 322: my_MM Burmese Myanmar 323: na_NR Nauru NR 324: ne_BT Nepali Bhutan 325: ne_IN India 326: ne_NP Nepal 327: nl_AN Dutch Netherlands Antilles 328: nl_AW Aruba 329: nl_BE Belgium 330: nl_ID Indonesia 331: nl_NL Netherlands 332: nl_SR Suriname 333: no_BV Norwegian BV 334: no_NO Norway 335: no_SJ SJ oc Occitan om Oromo (Afan) 336: or_IN Oriya India 337: pa_IN Punjabi India 338: pa_PK Pakistan 339: pl_LT Polish Lithuania 340: pl_PL Poland 341: pl_SK Slovakia 342: ps_AF Pashto (Pushto) Afghanistan 343: ps_PK Pakistan 344: pt_AO Portuguese Angola 345: pt_BR Brazil 346: pt_CV Cape Verde 347: pt_GW Guinea-Bissau 348: pt_MO MO 349: pt_MZ Mozambique 350: pt_PT Portugal 351: pt_ST ST 352: qu_BO Quechua Bolivia 353: qu_EC Ecuador 354: qu_PE Peru 355: rm_CH Rhaeto-Romance Switzerland 356: rn_AI Kirundi Anguilla 357: rn_BI Burundi 358: ro_MD Romanian Moldova 359: ro_RO Romania 360: ru_AM Russian Armenia 361: ru_AZ Azerbaijan 362: ru_BY Belarus 363: ru_EE Estonia 364: ru_GE Georgia 365: ru_KZ Kazakhstan 366: ru_LT Lithuania 367: ru_LV Latvia 368: ru_MN Mongolia 369: ru_RU Russia 370: ru_TJ Tajikistan 371: ru_TM Turkmenistan 372: ru_UA Ukraine 373: ru_UZ Uzbekistan 374: rw_RW Kinyarwanda Rwanda 375: sa_IN Sanskrit India 376: sd_PK Sindhi Pakistan 377: sg_CF Sangho Central African Republic 378: sh_BA Serbo-Croatian Bosnia and Herzegovina 379: sh_MK Macedonia 380: sh_SK Slovakia 381: sh_YU Yugoslavia 382: si_LK Sinhalese Sri Lanka 383: sk_CZ Slovak Czech Republic 384: sk_SK Slovakia 385: sl_BA Slovenian Bosnia and Herzegovina 386: sl_SI Slovenia 387: sm_AS Samoan AS 388: sm_WS WS 389: sn_ZW Shona Zimbabwe 390: so_DJ Somali Djibouti 391: so_SO Somalia 392: sq_AL Albanian Albania 393: sq_BA Bosnia and Herzegovina 394: sr_BA Serbian Bosnia and Herzegovina 395: sr_YU Yugoslavia 396: ss_SZ Siswati Swaziland 397: st_LS Sesotho Lesotho 398: su_SD Sundanese Sudan 399: sv_FI Swedish Finland 400: sv_SE Sweden 401: sw_BI Swahili Burundi 402: sw_KE Kenya 403: sw_TZ Tanzania 404: sw_UG Uganda 405: sw_YT Mayotte 406: sw_ZR Zaire 407: ta_IN Tamil India 408: ta_LK Sri Lanka 409: ta_RE RE 410: ta_SG Singapore 411: te_IN Telugu India 412: tg_TJ Tajik Tajikistan 413: th_TH Thai Thailand 414: ti_ER Tigrinya Eritrea 415: tk_IQ Turkmen Iraq 416: tk_TM Turkmenistan 417: tl_PH Tagalog Philippines 418: tn_BW Setswana Botswana 419: to_TO Tonga Tonga 420: tr_BG Turkish Bulgaria 421: tr_CY Cyprus 422: tr_MK Macedonia 423: tr_TR Turkey ts Tsonga tt Tatar tw Twi ug Uighur 424: uk_UA Ukrainian Ukraine 425: ur_GY Urdu Guyana 426: ur_PK Pakistan 427: uz_TJ Uzbek Tajikistan 428: uz_UZ Uzbekistan 429: vi_VN Vietnamese Vietnam vo Volapuk 430: wo_GM Wolof Gambia xh Xhosa yi Yiddish 431: yo_NG Yoruba Nigeria za Zhuang 432: zh_BN Chinese Brunei 433: zh_CN China 434: zh_HK Hong Kong 435: zh_MO MO 436: zh_SG Singapore 437: zh_TW Taiwan 438: zh_VN Vietnam zu Zulu -------------- next part -------------- -------------- next part -------------- import java.util.*; public class LocaleLang { public static void main(String[] args) { String[] isoCountries = Locale.getISOCountries(); String[] isoLanguages = Locale.getISOLanguages(); Hashtable lang2ctryMapping = new Hashtable(isoLanguages.length); StringBuffer[] ctry2LangLists = new StringBuffer[isoCountries.length]; //(country: {language}+) in ISO for (int i = 0; i < isoCountries.length; ++i) { ctry2LangLists[i] = new StringBuffer(); String country = isoCountries[i]; ctry2LangLists[i].append(country + ":" ); String[] languages = Locale_getLanguagesForCountry(country); for (int j = 0; j < languages.length; ++j) { String language = languages[j]; ctry2LangLists[i].append(" " + language); } } //DisplayCountry (country: {language}+) // {DisplayLanguage}+ for (int i = 0; i < isoCountries.length; ++i) { String country = isoCountries[i]; System.out.print(rightJustified(""+(i+1), 3) + ": "); System.out.print(new Locale("", country).getDisplayCountry()); System.out.println(" (" + ctry2LangLists[i] + ")"); String[] languages = Locale_getLanguagesForCountry(country); for (int j = 0; j < languages.length; ++j) { String language = languages[j]; System.out.println(" " + new Locale(language, country).getDisplayLanguage()); Vector lang2CtryVec = (Vector) lang2ctryMapping.get(language); if (lang2CtryVec == null) { lang2CtryVec = new Vector(); } lang2CtryVec.addElement(country); lang2ctryMapping.put(language, lang2CtryVec); } System.out.println(); } //language1_country1 DisplayLanguage1 DisplayCountry1 //language1_country2 DisplayCountry2 //... int cnt = 0; for (int i = 0; i < isoLanguages.length; ++i) { String lang = isoLanguages[i]; Vector lang2CtryVec = (Vector) lang2ctryMapping.get(lang); if (lang2CtryVec == null) { System.out.print(" " + lang + " "); String dispLang = new Locale(lang, "").getDisplayLanguage(); System.out.println(dispLang); System.out.println(); } else { for (int j = 0; j < lang2CtryVec.size(); ++j) { System.out.print(rightJustified(""+(++cnt), 3) + ": "); String ctry = (String) lang2CtryVec.elementAt(j); System.out.print(lang + "_" + ctry + " "); String dispLang = ""; if (j == 0) { dispLang = new Locale(lang, ctry).getDisplayLanguage(); } System.out.print(leftJustified(dispLang, 15) + " "); System.out.println(new Locale(lang, ctry).getDisplayCountry()); } System.out.println(); } } } //main private static String leftJustified(String str, final int len) { return justified(str, len, true); } private static String rightJustified(String str, final int len) { return justified(str, len, false); } private static String justified(String str, final int len, boolean left) { StringBuffer sb = new StringBuffer(str); final int size = str.length(); for (int i = 0; i < (len - size); ++i) { if (left) { sb.append(" "); } else { sb.insert(0, " "); } } return sb.toString(); } private static Hashtable ctry2LangMapping = null; private static final String compressedCtry2LangMapping = "ADfresAEarenAFpsAGenAIrnALsqAMhyruANnlenAOptAResASensmATdeAUenAWnlenAZazhyru" + "BAsrshhrslmksqBBenBDbnhibhenBEfrnldeBFfrBGbgtrBHarenBIrnfrswBJfrBMenBNmsenzh" + "BOesayquBRptBSenBTdzenneBVnoBWentnBYberuBZenesCAenfrCCenCFfrsgCGfrCHfrdeitrm" + "CIfrCKmienCLesCMenfrCNzhboCOesCResCUesCVptCXenCYeltrenCZcsskDEdeDJarfrsoDKda" + "DMenfrDOesDZarfrECesquEEetruEGarenfrEHarfritERamtiarenitESeseucaglETamaren" + "FIfisvFJenfjhiFKenFMenFOfodaFRfreubrcoFXfrGAfrGBengdcyGDenfrGEkahyruGFfrGHen" + "GIenesGLdaikklGMenwoGNfrGPfrenGQesGRelGTesGUenGWptGYenhiurHKzhenHNesHRhrHTfr" + "HUhuIDinennlIEengaILiwarjiINhienguknksmlmrneorpasatateIOenIQarkutkIRfaarku" + "ISisITitfrdeJMenJOarJPjaKEenswKGkyKHkmKIenKMfrarKNenKPkoKRkoKWarenKYenKZkkru" + "LAlofrLBarenfrLCenfrLIdeLKtasienLRenLSstenLTltruplLUfrdeLVlvltruLYarenit" + "MAarfresMCfrenitMDmorobgMGmgenfrMKmkshtrMLfrMMmyMNmnruMOzhptMQfrMRarfrMSen" + "MTmtenitMUenfrhiMWenMXesMYmsenMZptNAenafdeNEfrhaNFenNGenhayoNIesNLnlfyNOno" + "NPneNRnaenNUenNZenmiOMarenPAesenPEesquayPFfrPGenPHentlesPKurenpspasdPLplPMfren" + "PNenPResenPTptPWenPYesgnQAarenREfrtaROrohuRUruRWenfrrwSAarSBenSCenfrSDarsu" + "SEsvSGzhenmstaSHenSIslSJnoSKskhuplshSLenSMitSNfrSOarenitsoSRnleneshiSTptSVes" + "SYarSZenssTCenTDfrarTFfrTGfrTHthTJtgruuzTKenmiTMtkruTNarTOentoTRtrkuTTenTVen" + "TWzhTZenswUAukruUGenswUMenUSenesUYesUZuzruVAlaitVCenVEesVGenVIenVNvizhfr" + "VUenfrbiWFfrWSensmYEarYTfrmgswYUsrshmkhuZAafenZMenZRfrswZWensn"; private static String[] Locale_getLanguagesForCountry(String country) { // To save on the size of a static array in the .class file, we keep the // data around encoded into a String. The first time this function is called, // the String s parsed to produce a Hashtable, which is then used for all // lookups. if (ctry2LangMapping == null) { ctry2LangMapping = new Hashtable(); int i = 0; int j; while (i < compressedCtry2LangMapping.length()) { String key = compressedCtry2LangMapping.substring(i, i + 2); i += 2; for (j = i; j < compressedCtry2LangMapping.length(); j += 2) if (Character.isUpperCase(compressedCtry2LangMapping.charAt(j))) break; String compressedValues = compressedCtry2LangMapping.substring(i, j); String[] values = new String[compressedValues.length() / 2]; for (int k = 0; k < values.length; k++) values[k] = compressedValues.substring(k * 2, (k * 2) + 2); ctry2LangMapping.put(key, values); i = j; } } String[] result = (String[])ctry2LangMapping.get(country); if (result == null) result = new String[0]; return result; } } From norbertschade at oaktech.com Thu Apr 26 10:15:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> color brainstorming Message-ID: <009f01c0ce5b$68eecc40$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010426/f5296f6e/NorbertSchade.vcf From Dale.Hubbard at AgfaMonotype.com Thu Apr 26 13:03:08 2001 From: Dale.Hubbard at AgfaMonotype.com (Hubbard, Dale) Date: Wed May 6 14:04:55 2009 Subject: UPD> color brainstorming Message-ID: In an ICC work flow the profile should say it all, but all data which identifies the specific situation in which the profile was made is welcome. Indeed stuff like dithering style, gamma, resolution, etc. Also I think it would be nice to add a ID (like a checksum) in both profile and data, so that a check is possible whether the profile matches its use. This may also be used as an ID to find the profile. ____________________________________________________ Dale Hubbard Director of OEM Product Development and Support Agfa Monotype Corporation 200 Ballardvale Street Wilmington, MA 01887-1069 Tel: 978-284-7091 Fax: 978-657-8268 e-mail: dale.hubbard@agfamonotype.com -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, April 26, 2001 10:16 AM To: UPD group Subject: UPD> color brainstorming I have started cleaning our current dtd for better preparation of color support. We need to do some more investigation, what kind of information we want to save and what information an IHV would make public anyhow, as everybody can read an XML file easily. So I intend a two-days brainstorming (today and tomorrow). Please contribute what you would like to see for color support and get your experts involved. I am looking for a simple, informal list of features (dithering matrixes, gamma correction formula, ICC file support and things like that). Hoping to get some feedback, I may do a sample implementation in our dtd structure over the week-end, which then can be discussed by some better experts than I am. But then they have something to start from. Just start throwing simple, short emails in with the subject 'color ideas'. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010426/dc8d7dda/attachment.html From norbertschade at oaktech.com Mon Apr 30 15:20:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> manual duplex Message-ID: <001101c0d1aa$ac18b600$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010430/abc40c99/NorbertSchade.vcf From norbertschade at oaktech.com Mon Apr 30 15:31:01 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> watermarks Message-ID: <000d01c0d1ac$16da9de0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010430/f85db863/NorbertSchade.vcf From sommer at granitesystems.com Mon Apr 30 19:53:50 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:55 2009 Subject: UPD> driver features In-Reply-To: <001101c0d1aa$ac18b600$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010430195011.0095c570@mailbox.bellatlantic.net> I agree that manual duplex and watermarks are driver features so they probably don't need to be specified in the UPDF. I would put N-Up in this category too. You can argue that some printers implement N-Up with a command, but some printers may do watermarks with a command as well. If a printer did implement watermarks or N-Up it would probably be with a PJL (or some other job language) command and therefore could probably be specified using one of the generic job language controls. Jim At 4/30/01 03:20 PM, Norbert Schade wrote: >Do we all agree that this is a pure driver feature, which we do not >describe in our format? >It's not as trivial, as it looks, as this feature has a number of >constraints and quite some user interface issues. But I'd like to stay >away from it, unless that is a real showstopper for somebody. > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010430/31f21125/attachment.html From norbertschade at oaktech.com Tue May 1 10:39:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> locales Message-ID: <007401c0d24c$820b25d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/5de73cf4/NorbertSchade.vcf From norbertschade at oaktech.com Tue May 1 11:19:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> duplex Message-ID: <001101c0d252$2dc54c70$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/c9ddaff1/NorbertSchade.vcf From hastings at cp10.es.xerox.com Tue May 1 14:46:58 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:55 2009 Subject: UPD> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Message-ID: <918C79AB552BD211A2BD00805F15CE8504F78EA7@x-crt-es-ms1.cp10.es.xerox.com> Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From norbertschade at mediaone.net Tue May 1 19:29:51 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> Print Media Handling 010501 Message-ID: <001901c0d296$9f298680$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15105 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/516c9bc7/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 14775 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/516c9bc7/UPDFEntities.obj From hastings at cp10.es.xerox.com Wed May 2 01:11:50 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:55 2009 Subject: UPD> RE: MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10-12 PDT (1-3 EDT) Message-ID: <918C79AB552BD211A2BD00805F15CE8504F78EF1@x-crt-es-ms1.cp10.es.xerox.com> I've received a number of private rankings for these 5 methods, so if any of you would prefer to just reply (NOT REPLY ALL) and send your preferences to me, instead of sending to the IPP DL, I'll combine all that I receive for the telecon. Thanks, Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, May 01, 2001 11:47 To: ipp (E-mail) Cc: UPDF WG (E-mail); UPnP Print and Imaging WG (E-mail); Melinda Grant (E-mail) Subject: MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10-12 PDT (1-3 EDT) Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From don at lexmark.com Wed May 2 01:04:01 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:55 2009 Subject: UPD> Re: IPP> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Message-ID: <200105020510.BAA10334@interlock2.lexmark.com> We don't need any more alternatives. We need to close this NOW! ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances and Standards * * Lexmark International * * 740 New Circle Rd C14/082-3 * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Hastings, Tom N" on 05/01/2001 02:46:58 PM To: "ipp (E-mail)" cc: "UPDF WG (E-mail)" , "UPnP Print and Imaging WG (E-mail)" , "Melinda Grant (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From mail2 at pcpostal.com Thu May 10 12:14:50 2001 From: mail2 at pcpostal.com (Mitchell) Date: Wed May 6 14:04:55 2009 Subject: UPD> Business/Employment Opportunity Message-ID: <81842001541016145010@pavilion> Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Mitchell P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From norbertschade at oaktech.com Fri May 11 12:48:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> Fw: short cuts/ hot keys Message-ID: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> We need a little more input for that. Do we want it done as an attribute of a Locale_Element, which would be the right place? Do we want to specify a position within a UI string or do we want to enter the character for the hot key? If we specify hot keys, we certainly will not do it within the UI string (like adding a '&'). Please make a simple statement. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Monday, April 23, 2001 4:15 PM Subject: short cuts Do we want to support the definition of short cuts in the UI (e.g. select orientation control by pressing Alt+o)? Some may say that's historic, some may insist it's mandatory, some may say it's not up to UPDF to tell. I tend to belong to the first group, as everybody has a mouse by now. In some cases I work with the keyboard to be faster. But then I use tab and arrow keys. But I don't think it would be much of a deal to implement it. It would be part of a LocaleElement in the locale dtd. Comments? Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/842053d5/attachment.html From norbertschade at oaktech.com Fri May 11 12:55:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> Parameter converter in UI strings Message-ID: <002501c0da3b$2ba0fbb0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/24073506/NorbertSchade.vcf From norbertschade at oaktech.com Fri May 11 13:15:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> new device description Message-ID: <004301c0da3d$fd49b420$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/a277cc6d/NorbertSchade.vcf -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 16902 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/a277cc6d/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml From norbertschade at oaktech.com Fri May 11 14:42:48 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> latest new device description Message-ID: <003101c0da4a$2ce64f20$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/97771594/NorbertSchade.vcf From sommer at granitesystems.com Fri May 11 14:52:15 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:55 2009 Subject: UPD> Parameter converter in UI strings In-Reply-To: <002501c0da3b$2ba0fbb0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511144935.00967100@mailbox.bellatlantic.net> I have concerns about the performance impact of having to scan for dynamic changes every time something in the UI changes. The UI code could build tables to keep track of where dynamic strings exist but this seems like a lot of work just so someone doesn't have to create a few more UPDF localized strings. Jim At 5/11/01 12:55 PM, Norbert Schade wrote: >The Name_ID in the technical description is providing the reference to the >Locale_Element in the locale file. >In many cases the Locale_Element shows a term, which is to be shown >unproved in the UI. >Especially when there is a chance to specify only one record with a >formula for a feature instead of many records with single entries, it >seems very useful to be able to have the Parameter Converter (in case you >are not too familiar with it: the Parameter Converter helps converting >formulas to real entries) help to build the UI string. >Samples could be copies, zooming percentage, resolution, etc. >We are a little concerned about performance, as this has to happen >dynamically every time. >Let's discuss that on the distributor. Send your opinion to the group. > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/c38c791d/attachment.html From sommer at granitesystems.com Fri May 11 14:54:57 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:55 2009 Subject: UPD> Fw: short cuts/ hot keys In-Reply-To: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511145225.00964320@mailbox.bellatlantic.net> I think each locale element should have an optional attribute for the keyboard short cut key. In the Windows world this is a standard feature and it shouldn't be up to the UI code to figure it out. I vote for an element that specifies the character that is to be the keyboard short cut. This allows the string writer to see which keys are being used as short cuts and avoid duplicates. Jim At 5/11/01 12:48 PM, you wrote: >We need a little more input for that. >Do we want it done as an attribute of a Locale_Element, which would be the >right place? >Do we want to specify a position within a UI string or do we want to enter >the character for the hot key? >If we specify hot keys, we certainly will not do it within the UI string >(like adding a '&'). >Please make a simple statement. >Regards >Norbert Schade > >----- Original Message ----- >From: Norbert Schade >To: UPD group >Sent: Monday, April 23, 2001 4:15 PM >Subject: short cuts > >Do we want to support the definition of short cuts in the UI (e.g. select >orientation control by pressing Alt+o)? >Some may say that's historic, some may insist it's mandatory, some may say >it's not up to UPDF to tell. > >I tend to belong to the first group, as everybody has a mouse by now. In >some cases I work with the keyboard to be faster. But then I use tab and >arrow keys. >But I don't think it would be much of a deal to implement it. >It would be part of a LocaleElement in the locale dtd. > >Comments? > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/13c468a7/attachment.html From sommer at granitesystems.com Fri May 11 15:02:06 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:55 2009 Subject: UPD> Fw: short cuts/ hot keys In-Reply-To: <4.2.0.58.20010511145225.00964320@mailbox.bellatlantic.net> References: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511150109.0095e8f0@mailbox.bellatlantic.net> I meant an attribute, not an element, that specifies the keyboard short cut. Jim At 5/11/01 02:54 PM, Jim Sommer wrote: >I think each locale element should have an optional attribute for the >keyboard short cut key. In the Windows world this is a standard feature >and it shouldn't be up to the UI code to figure it out. > >I vote for an element that specifies the character that is to be the >keyboard short cut. This allows the string writer to see which keys are >being used as short cuts and avoid duplicates. > >Jim From norbertschade at mediaone.net Mon May 14 12:04:23 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> new dtd version Message-ID: <000d01c0dc8f$8b2ba020$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15532 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 17187 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 15063 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDF.obj From norbertschade at oaktech.com Tue May 15 10:41:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> device resolution Message-ID: <001d01c0dd4d$12e4aad0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/37b6e295/NorbertSchade.vcf From norbertschade at mediaone.net Tue May 15 19:59:21 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> positioning Message-ID: <000d01c0dd9b$10298600$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 15902 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 15041 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 17210 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDFDeviceDescription-HPLaserJet8150PCL5e.xml From hamzy at us.ibm.com Tue May 22 14:37:10 2001 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:04:55 2009 Subject: UPD> Ledger vs Tabloid Message-ID: Hello, The developer of apsfilter noticed a problem with Ledger and Tabloid forms. The UPDF document says that Ledger is 11x17. I have searched the web and noticed that there are three sets of beliefs. - Ledger is 11x17 - Ledger is 17x11 - Ledger is the same as Tabloid. and vice versa for Tabloid. There seems to be a lot of confusion. Ghostscript defines Ledger as 17x11 while Omni defines it as 11x17. Do any of you have any history on Ledger or Tabloid? Please reply directly as I am not subscribed to the mailing list. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at oaktech.com Thu May 31 14:26:21 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> start of UPDF sample implementation Message-ID: <001f01c0e9ff$315091f0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/8073df36/NorbertSchade.vcf From norbertschade at oaktech.com Thu May 31 17:56:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> changes in latest version from today Message-ID: <010901c0ea1c$9da08320$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/71303a2e/NorbertSchade.vcf From norbertschade at mediaone.net Thu May 31 21:03:34 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:55 2009 Subject: UPD> latest version of dtd and xml files Message-ID: <001f01c0ea36$af05cb60$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 13078 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDF.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFCommandSequences.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: application/octet-stream Size: 2112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFConstraints.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 9000.xml Type: text/xml Size: 913 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceConfiguration-HPLaserJet9000.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 15975 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceDescription-HPLaserJet9000PCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 1339 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceConfiguration.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 17153 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFEntities.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF FontHandling.dtd Type: application/octet-stream Size: 11480 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFFontHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 1139 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1858 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale-deDE-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 4861 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale-enUS-HPLaserJet.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Option Configuration-HP Duplexing Unit PCL5e.xml Type: text/xml Size: 758 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFOptionConfiguration-HPDuplexingUnitPCL5e.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF OptionConfiguration.dtd Type: application/octet-stream Size: 1283 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFOptionConfiguration.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15027 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFPrintMediaHandling.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2614 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFCommandSequences-HPLaserJetPCL5e.xml From hastings at cp10.es.xerox.com Mon Jun 4 16:20:08 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:55 2009 Subject: UPD> Ledger vs Tabloid Message-ID: <918C79AB552BD211A2BD00805F15CE8504F799E9@x-crt-es-ms1.cp10.es.xerox.com> Mark, I'm guessing that Ledger is a landscape oriented medium, since a ledger is typically viewed landscape, while a tabloid (newspaper) is viewed portrait. I've also seen the conventions on boxes of paper in which the difference between 11x17 and 17x11 is significant: when it has fanfold tear off tractor feed holes. The 17x11 is landscape paper, with the fanfold separations being along the long (17 inch side). Note: in our PWG Media Size standard, we are NOT making a distinction between portrait and landscape media sizes, but are depending on something else to include the orientation when it is significant. Tom -----Original Message----- From: Mark Hamzy [mailto:hamzy@us.ibm.com] Sent: Tuesday, May 22, 2001 11:37 To: upd@pwg.org Subject: UPD> Ledger vs Tabloid Hello, The developer of apsfilter noticed a problem with Ledger and Tabloid forms. The UPDF document says that Ledger is 11x17. I have searched the web and noticed that there are three sets of beliefs. - Ledger is 11x17 - Ledger is 17x11 - Ledger is the same as Tabloid. and vice versa for Tabloid. There seems to be a lot of confusion. Ghostscript defines Ledger as 17x11 while Omni defines it as 11x17. Do any of you have any history on Ledger or Tabloid? Please reply directly as I am not subscribed to the mailing list. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From hastings at cp10.es.xerox.com Mon Jun 4 17:07:58 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:56 2009 Subject: UPD> changes in latest version from today Message-ID: <918C79AB552BD211A2BD00805F15CE8504F799ED@x-crt-es-ms1.cp10.es.xerox.com> Norbert, It took me quite a while to find out what you meant by "The UPDF version I put to the web today"? So I'm writing this note. First I went to the PWG web page: http://www.pwg.org/ which sent me to: http://www.pwg.org/updf/index.html The Documents link goes to version 0.51, which is two years old. Then I tried the Related Links URLs and did find the DTDs and Sample XML files. Perhaps, they could be given more prominence on the web page or renamed from "Related Links" to Current DTDs and Sample XML files", since they are the focus of the work, as I understand it. However, I'm still unable to bring up the XML files using Outlook. I get: The XML page cannot be displayed Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later. _____ Access is denied. Then I looked at ftp://ftp.pwg.org/pub/pwg/upd/ and saw no files in that directory, but did find three folders: Archive Current_Version minutes Under Current_Version I found two folders: DTD XML_Samples by the dates on those files, I suspect that they are the ones that you also attached below. However, sending out such a long list of attachments is a problem for at least two reasons: a. its a lot of data for the poor traveling folks who pick up email over hotel phone lines b. its a pain for those of us with fast connections to extract each of 15 files from our mail agents (I use Outlook). A more user friendly approach would be to simply send out the two urls: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/ ftp://ftp.pwg.org /pub/pwg/upd/Current_Version/XML_Samples/ Also if you could also put them into a single .zip file in the parent directory with a date in the file name, say: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/ current-version-010531.zip and also send that URL. Then all of the files could be picked up in a single trip. Also XML files compress by large factors with ZIP and its easy to extract one or a bunch of files from the ZIP archive. What do others think? Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, May 31, 2001 14:57 To: UPD group Subject: UPD> changes in latest version from today The UPDF version I put to the web today has a number of improvements. We made the naming more consistent. A dot is no more allowed within a name of an element or an attribute. The dot will work as a separator when an element has to be specified by its complete or at least partial path like PrintCapabilities.Print_Features.DeviceResolutionList.DeviceResolution.Horiz ontalResolution. Some elements have got a prefix 'TBD_'. this indicates that the feature is not completely solved, under construction or it is just a reminder not to forget to work on that later. Your feedback on those features is appreciated, but it may change or even disappear during further development. We have split the locale identifier in the locale dtd now. There is a language and a separate country entry now. This allows almost every dreamable combination for the last polar bear living in the jungle. You will find that the sample data is much more consistent now, where we previously just threw in just something to show an entry. You may check the 'UI_String_xxx' references in name id attributes and the English locale as a sample. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010604/b988b877/attachment.html From norbertschade at oaktech.com Wed Jun 6 14:03:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> heads up, XML experts Message-ID: <000d01c0eeb2$f21ba020$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010606/9536f3f8/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jun 6 14:22:37 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Ampercent Message-ID: <003701c0eeb5$a9f12ba0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010606/051331fa/NorbertSchade.vcf From norbertschade at oaktech.com Fri Jun 8 15:18:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Note 4: proper content changes after duplicating files Message-ID: <002501c0f04f$beea1b70$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010608/7900faf4/NorbertSchade.vcf From norbertschade at oaktech.com Mon Jun 11 14:44:43 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Note 4 of last Friday Message-ID: <001601c0f2a6$94631bf0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010611/613d6286/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jun 13 18:22:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: Fw: UPD> heads up, XML experts Message-ID: <001301c0f457$4fece070$551414ac@hsg.ma.oaktech.com> Friendly reminder. Can anybody help? This is important. ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:03 PM Subject: UPD> heads up, XML experts It looks as if some browsers (I use Internet Explorer) do not like XML declarations ( line starts: versions Message-ID: <000d01c0f4df$7d1a3dd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010614/c794bb50/NorbertSchade.vcf From markv at us.ibm.com Thu Jun 14 19:57:11 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:04:56 2009 Subject: Fw: UPD> heads up, XML experts Message-ID: Norbert: Linux's (GNOME)LibXML does not like lines that start with (@pwg.org on 06/13/2001 05:22:20 PM Sent by: owner-upd@pwg.org To: "UPD group" cc: Subject: Fw: UPD> heads up, XML experts Friendly reminder. Can anybody help? This is important. ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:03 PM Subject: UPD> heads up, XML experts It looks as if some browsers (I use Internet Explorer) do not like XML declarations ( line starts: Fw: Ampercent Message-ID: <001901c0f5bc$fbdf5c30$551414ac@hsg.ma.oaktech.com> additional note: it has to be '&' or %H1(38). My XML Pro can read '&' as an ampercent, but insists on writing '&' when I save the command sequence file. So be careful. I'm not sure whether that is an application bug. Have mercy when I forget to change it from time to time, when I replace the files on the web page. I promise to concentrate as much as possible. Regards Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:22 PM Subject: Ampercent If possible stay away from the ampercent! This limitation is due to XML. If you can't, use '&'. In the parameter converter you still could work with something like %H1(38). Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010615/51792c9c/attachment.html From norbertschade at oaktech.com Fri Jun 15 13:52:28 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> driver features Message-ID: <000d01c0f5c3$f15a03d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010615/47c260e7/NorbertSchade.vcf From sommer at granitesystems.com Fri Jun 15 15:56:21 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:56 2009 Subject: UPD> driver features In-Reply-To: <000d01c0f5c3$f15a03d0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010615151332.009642d0@mailbox.bellatlantic.net> I would not group "Scale Patterns" and "Print Text as Black" with "Edge to Edge". Edge to edge (or full bleed) printing can not be added to a driver unless it is supported by the printer. Scale patterns, text as black, and render mode are functions implemented totally in the driver without any printer functionality. I don't think they belong in UPDF until we start addressing UI issues. Jim At 6/15/01 01:52 PM, Norbert Schade wrote: >Many drivers do not only show features, which cause any kind of command >sequence (JCL or PDL) to be sent to the printer, but provide some >settings, which change the behavior of the driver while rendering. The >driver must understand the setting, while for the generic features it just >can rely on information where to send what. >This group of features include items like 'Scale Patterns', 'Print Text as >Black', 'Edge to Edge Printing' (at the moment specified as a generic >feature - may change), 'Rendering Mode', etc. There may be more. Any >request to treat them as a group or list them at specific places? > >Another group includes entries for 'Width' or 'Height' like used in a >custom size dialog. Proposals here? > >The last group on my list includes pure UI elements like group boxes (may >be with titles), buttons to open another dialog, etc. We will ignore that >for now, probably completely in UPDF, level 1. Your opinion? > > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010615/6f03cbd1/attachment.html From norbertschade at oaktech.com Fri Jun 15 15:59:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> summer schedule Message-ID: <005401c0f5d5$c1045660$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010615/079570b3/NorbertSchade.vcf From norbertschade at oaktech.com Mon Jun 18 11:14:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> connectors and extensible configuration Message-ID: <004e01c0f809$691a0180$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010618/d31c02e7/NorbertSchade.vcf From norbertschade at oaktech.com Tue Jun 19 17:04:39 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> UPDF Functional Specification on UPDF web site Message-ID: <001101c0f903$74626f00$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010619/c00e7e55/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jun 20 13:08:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> UPDF Functional Specification Message-ID: <000d01c0f9ab$a3ad6eb0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010620/d7d6b97a/NorbertSchade.vcf From norbertschade at oaktech.com Thu Jun 21 10:25:24 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> EventHandlers Message-ID: <001201c0fa5e$026b2520$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010621/9b07699e/NorbertSchade.vcf From norbertschade at oaktech.com Fri Jun 22 10:18:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> merged ID list names, documentation style Message-ID: <003301c0fb26$44780820$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010622/471d68d6/NorbertSchade.vcf From norbertschade at oaktech.com Fri Jun 22 17:37:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> keeping up appearances Message-ID: <001101c0fb63$9724cf80$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010622/f39b00d5/NorbertSchade.vcf From norbertschade at oaktech.com Tue Jun 26 16:09:42 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Movement from DTD to Schema Message-ID: <002301c0fe7b$f02ff080$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010626/3993a2d8/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jun 27 12:13:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> schema formats Message-ID: <006a01c0ff24$23d8a500$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010627/72d3f910/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jun 27 14:03:28 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> will schemas be implemented soon? Message-ID: <001701c0ff33$781e4ac0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010627/5fafc421/NorbertSchade.vcf From norbertschade at oaktech.com Thu Jun 28 13:54:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Connectors Message-ID: <007901c0fffb$63f245b0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010628/c1253e8a/NorbertSchade.vcf From norbertschade at oaktech.com Fri Jun 29 14:31:51 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Toronto: preliminary agenda Message-ID: <000d01c100c9$c3d160f0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010629/df426471/NorbertSchade.vcf From upd at pwg.org Mon Jul 2 01:18:43 2001 From: upd at pwg.org (upd@pwg.org) Date: Wed May 6 14:04:56 2009 Subject: UPD> hi Message-ID: <20010701151347.1ADB11D2E18C4@smtp4.163.com> An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010702/834042e4/attachment.html From VSalmons at zebra.com Sun Jul 1 12:11:50 2001 From: VSalmons at zebra.com (Salmons, Victor) Date: Wed May 6 14:04:56 2009 Subject: Out of Office AutoReply: UPD> hi Message-ID: I will be out of the office June 29 - July 6, returning to the office July 9. I will have no access to e-mail. From Karen.Behringer at AgfaMonotype.com Sun Jul 1 12:15:17 2001 From: Karen.Behringer at AgfaMonotype.com (Behringer, Karen) Date: Wed May 6 14:04:56 2009 Subject: Out of Office AutoReply: UPD> hi Message-ID: I am out of the office until Monday July 9th. I will be back in touch with you when I return. If you have any urgent issues please contact Jim Doolittle (jim_doolittle@agfamonotype.com) in my absence. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 1698 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010701/485e4682/attachment.bin From Michel_Aarssen at epson-europe.com Sun Jul 1 12:19:25 2001 From: Michel_Aarssen at epson-europe.com (Aarssen, Michel) Date: Wed May 6 14:04:56 2009 Subject: Out of Office AutoReply: UPD> hi Message-ID: <16F06575312BD4119FCB0008C7E6DAD2054486@EHQEXCH1A> I will continue my network support activities at Monday 2 July Best regards, Michel Aarssen From robert_b_taylor at hp.com Sun Jul 1 12:25:30 2001 From: robert_b_taylor at hp.com (TAYLOR,BOB (HP-Vancouver,ex1)) Date: Wed May 6 14:04:56 2009 Subject: Out of Office AutoReply: UPD> hi Message-ID: <6D805D4C4567D411AF32009027B6835165D7FD@xvan02.vcd.hp.com> Hello, This mail message has been sent to you by my automated email script. This should be the only copy you see unless you send me mail from a different system. I will be away from the office until July 12, 2001 and will have no access to email until then. I will reply to your message, if appropriate, as soon as possible. If you have something that can't wait until then, please contact Evan Smouse (evan_smouse@hp.com). Thank you, Bob Taylor robertt@vcd.hp.com From peter.mcgregor at okiuk.co.uk Sun Jul 1 20:01:33 2001 From: peter.mcgregor at okiuk.co.uk (peter.mcgregor@okiuk.co.uk) Date: Wed May 6 14:04:56 2009 Subject: UPD> Peter McGregor/OEL/OKI_DATA_CORP/OKI_ELECTRIC/US is out of the office. Message-ID: <000357A5.N22183@okiuk.co.uk> I will be out of the office from 26/06/2001 until 18/07/2001. I will review all email on my return. From norbertschade at oaktech.com Fri Jul 6 17:57:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> Font specification Message-ID: <004201c10666$9ca78660$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010706/cf8625b6/NorbertSchade.vcf From norbertschade at oaktech.com Thu Jul 12 16:51:44 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:56 2009 Subject: UPD> constraints -> interdependencies Message-ID: <001d01c10b14$75f81a90$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010712/d0af50ed/NorbertSchade.vcf From hastings at cp10.es.xerox.com Mon Jul 16 13:29:15 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:57 2009 Subject: UPD> constraints -> interdependencies Message-ID: <918C79AB552BD211A2BD00805F15CE850532CCF1@x-crt-es-ms1.cp10.es.xerox.com> I like the terminology change from "constraints" to "interdependencies". The new term is much clearer what is meant, since the concept is about the relationship between the values of several attributes, not the list of possible values for a single attribute. Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, July 12, 2001 13:52 To: UPD group Subject: UPD> constraints -> interdependencies In the sample implementation group we are close to constraints handling. That is the right time to make a simple change I've in mind for quite a while. We will change the wording in the whole constraints area. To speak of 'constraints' the way we do it is not correct. Constraints are describing the available entries of a list or so. See some of the XML tools. The term is exactly used in that way. So other than the fact we are doing it wrong, it is also confusing. >From now on we speak of interdependencies between features and mean the same as before. This will require some renaming of files, elements and attributes, not to speak of the documentation. In ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/ you can find a temporary documentation document 'UPDF Constraints.doc'. This is supposed to disappear soon, while the content is moving to the 'UPDF Functional Specification' (the big document growing these days step by step). In this final document it will be referred to as interdependencies only. We are not changing any structure nor any other design rules because of this. It's only a name change! I will start with the changes on Monday, 7/16/01. If you have any concern, let me know before. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010716/2a6903f8/attachment.html From norbertschade at oaktech.com Tue Jul 17 14:20:50 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> Interdependencies Message-ID: <013001c10eed$356fc540$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010717/ebd5e7dd/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jul 18 12:53:51 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> Parameters in command sequences Message-ID: <00f001c10faa$38d1e020$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/c73bb2c1/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jul 18 17:14:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> color planes Message-ID: <006001c10fce$a00fe380$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/7713bc4e/NorbertSchade.vcf From norbertschade at oaktech.com Wed Jul 18 18:14:49 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> generic features and generic PDL output Message-ID: <00ac01c10fd7$0f5b6e00$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/caa99b68/NorbertSchade.vcf From norbertschade at oaktech.com Mon Jul 23 12:29:02 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> update of web site: Interdependencies, device fonts, docu Message-ID: <002b01c11394$95357280$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010723/bc9c04b6/NorbertSchade.vcf From norbertschade at mediaone.net Tue Jul 24 20:34:13 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> Fw: UPDF introduction in 10 minutes Message-ID: <001401c114a1$8b2f2f20$f2755b18@ne.mediaone.net> Some time ago I proposed five additional marketing documents, which might be added to the UPDF web site. Candidates are: 1. The idea of UPDF. I have a small rough document available, which is not exactly on the level I'd like to see it and has to be reviewed. I'll bring with me to Toronto. I asking for help to do this. 2. UPDF introduction in 10 minutes. Find a proposal below. Except some typos I think this is my final proposal. I am asking for comments and editor's review from the field. 3. Comparison between GPD and UPDF. I am asking for help here. 4. Comparison between PPD and UPDF. I am asking for help here. 5. How to build your own UPDF description from an existing sample. Perhaps someone from the sample implementation group could do that, so that we have some different view how to do the task. All documents are supposed to be short (like two to four pages). We do not want to provide indepth information for every detail, but give a newcomer a chance to get the required information as compressed as possible. All documents have to be final before the fall conference. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: Norbert Schade Sent: Tuesday, July 24, 2001 8:00 PM Subject: UPDF introduction in 10 minutes UPDF (Universal Printer Description Format) is a data driven concept, which provides input parameters drivers need to render and output printer data. Q.: Is UPDF is new idea? A.: No, there are a other concepts, which try to accomplish a similar target. 1. There is PPD. This is a PostScript specific concept. In the view of many printer manufacturers and driver developers it has not evolved to nowadays needs. PPD are not based on XML. PPD do not support Unicode. Font handling is described outside the format. 2. GPD This is a Microsoft specific concept, which is dedicated to Microsoft platforms. GPD are not based on XML. GPD do not support Unicode. Font handling is described outside the format. 3. Proprietary formats. There are a number of company proprietary formats, which are all dedicated to a specific platform or driver system. Q.: So why UPDF? A.: UPDF describes all data a generic driver for enterprise printers needs. 1. The concept is based on XML. 2. It supports Unicode. 3. It is platform independent. Q.: What makes UPDF outstanding against other concepts? A.: It provides some core architecture, which allows the required complexity and flexibility. 1. There are the four pillars of UPDF. 1.1. The Parameter Converter. To be able to describe text based printer data as well as binary one, it needs a special syntax. The Parameter Converter is the solution for that, as it can describe text based and binary data, the reference to driver keywords, the reference to UPDF keywords and even conditional output. This functionality is not only used to specify PDL data, but is used all over the place in UPDF attributes. 1.2. Interdependencies. Interdependencies can easily be converted from other data concepts. The UPDF functionality is exceeding, as it allows more complex conditions by support of 'AND' and 'OR' combinations. It also allows other actions than just filtering like specifying conditional user interface messages. 1.3. Event handlers. The order of command sequences in different PDL differs. Event handlers allow specifying a large number of print events including Job start/end, PDL start/end as well as some feature specific events like the description of a raster graphic print sequence. 1.4. Composite features. Basic features like media size, media source, device resolution, etc. can be arbitrarily be assembled to composite features to allow the specification of high level features. Samples include predefined settings for subdialogs or driver defaults. 2. A driver default per locale is supported. 3. Device fonts are supported. 4. Localized user interface strings as well as messages are supported. 5. Extensible configuration. UPDF is prepared to describe devices and installable options known at the time the device is going to be launched as well as installable options, which will be launched at a later date. The device description can grow with the availability of installable options without the need of changing the original device description. 6. User group policies. Supervisors and system administrators are always looking for chances to specify user or user group specific descriptions on top of the device description. This includes driver settings different from driver defaults as well as additional features (based on the composite features functionality) to determine the appearance of driver features. This functionality allows presetting certain features or hiding certain features completely for certain users. Q.: Where will UPDF device description be available? A.: Because of its platform independency the description can be provide on storage media like CD or on web site and even in the device itself. Q.: When will UPDF be available to the public? A.: UPDF, level 1, is supposed to be introduced to the public in late fall 2001. Q.: Where can I get information about the current level of UPDF? A.: People interested in the current level can always look at the UPDF web site. The UPDF standard is embraced by the PWG (Printer Working Group) and can be accessed from www.pwg.org in the Internet. 1. UPDF is currently based on DTD (Document Type Definitions). That may change to schemas in the near future. The current level of dtd files can be accessed from ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/ 2. A UPDF reference sample with a XML description can be accessed from ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML_Samples/ 3. A functional specification documentation is growing these days. The current level can always be accessed from the UPDF web site. A direct link is ftp://ftp.pwg.org/pub/pwg/www/updf/UPDF_Functional_Specification.pdf Q.: What is the simplified architecture of UPDF? A.: The basic architecture is determined by a small number of XML files. 1. The unit configurations. 1.1. The device unit configuration. One file per device. This is the driver's data entry point! A driver will find references to the device description file, the command sequence file as well as to all locale files plus a few attributes. 1.1. The optional unit configuration. One file per optional unit. Similar structure to the device configuration. The driver will find the references specific to an optional unit plus a few attributes. During installation this information may be moved into the device configuration or a platform specific reference may maintain this information. 2. The device description. One file per device. This is the core UPDF file providing the overall device description. You will find a number of references to command sequences and localized user interface strings. It was a learning effect for the group that it might be better to separate the real PDL command sequences from the device description as well as the localization of user interface strings and messages. This leverages the work for PDL experts and translators, as they are not confronted with an overwhelming amount of information they are not interested in when doing there job. 3. Command sequences. One file per device description. This XML file holds all the PDL command sequences. A command sequence file may hold more than the command sequences used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description. 4. Localized user interface strings. One file per locale per device description. This XML file holds all the user interface strings for features and messages. A locale file may hold more than the user interface strings used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description. Q.: Is an UPDF description supposed to be used in its original XML form? A.: This is left to the actual implementation. By watching the ongoing implementations it looks more that the XML information is converted into some platform specific format. That provides some significant performance advantages and seems to help with platform specific implementations. This may happen during installation. Q.: How would a developer create device font data? A.: This is left to the UPDF developer. Basically someone could do that manually by filling out the proper attributes. But we are assuming that conversion tools will be written to convert data already available for device fonts supported in other data concepts. We are also in touch with the major font vendors like AGFA and Bitstream to have them develop concerters for their own databases. Q.: Are there limitations in an UPDF description? A.: Yes, there are. To be able to finish a the current level we have limited ourselves not to support certain features, as there are: 1. Palette handling. It is currently discussed, whether this is required to be supported in level 1. 2. Raster compression. This is likely not supported in level 1, but is a candidate for the next level. 3. Vector graphic. UPDF describes raster graphic for every PDL supported. A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it. 4. Font download format. UPDF may support the specification of certain download command sequences, but it is not described the structure of a download format. A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it. 5. Application flags. As applications may work differently under different platforms, this is not considered a feature of UPDF. Q.: Are there certain assumptions UPDF makes? A.: Yes, there are. The current format of UPDF includes the support of JCL (Job Control Language). The format provides a list of keywords of a JCL like PJL, but it is not specifying the syntax of that JCL. There is supposed to be a JCL specific library available on the platform, which converts the keywords into proper JCL language. This concept has been chosen, as there are platform specific components available in a number of cases, which are designed to do exactly that task, and as some newer JCL (Bluetooth, JDF) are described in XML as well. And we don't want to describe that a second time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010724/6c590090/attachment.html From norbertschade at oaktech.com Thu Aug 9 15:50:18 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> UPDF dtd to XML schema conversion Message-ID: <006501c1210c$842b9f20$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010809/393cb082/NorbertSchade.vcf From norbertschade at oaktech.com Thu Aug 9 16:17:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> changes during schema conversion Message-ID: <007101c12110$43cd5cd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010809/99619267/NorbertSchade.vcf From norbertschade at oaktech.com Fri Aug 10 15:32:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> XML schema definitions Message-ID: <000f01c121d3$43ab9960$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010810/631add46/NorbertSchade.vcf From norbertschade at oaktech.com Wed Aug 15 16:39:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> XML schema definition the selected format Message-ID: <001d01c125ca$734110b0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010815/eb512a3a/NorbertSchade.vcf From norbertschade at oaktech.com Thu Aug 16 13:23:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> upcoming conferences Message-ID: <001301c12678$3af96b40$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010816/34f7d2b1/NorbertSchade.vcf From don at lexmark.com Thu Aug 16 13:34:35 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:57 2009 Subject: UPD> upcoming conferences Message-ID: <200108161734.NAA13573@interlock2.lexmark.com> Currently there are no plans to have a December meeting in LA. That was tentatively cancelled several meetings ago and there have been no efforts to revive it. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * Member, IEEE SA Board of Governors * * Member, IEEE-ISTO Board of Directors * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Norbert Schade" on 08/16/2001 01:23:56 PM To: "UPD group" cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> upcoming conferences I'd like to get an overview what meetings the UPDF may have in the medium-term future. It looks, as if this is the draft plan of PWG (schedule and locations may change): October 2001 (could be Seattle) December 2001 (Los Angeles) January 2002 ( could be Hawaii) March 2002 (could be Florida) Seeing the current level of the spec and the ongoing development it seems very reasonable to me to meet in October 2001. It is not planned to meet in Los Angeles. This could change on request or if we see more companies working on host implementations. The UPDF group will not be in Hawaii. We may have one or two teleconferences in the December/January time frame instead. We'll most likely will meet in March 2002. Any comments? I'd like to give Don Wright some indications late today for his scheduling work. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010816/c82ac283/att1.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: application/octet-stream Size: 458 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010816/c82ac283/NorbertSchade.obj From norbertschade at oaktech.com Wed Aug 22 11:11:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> next steps Message-ID: <000d01c12b1c$bba05490$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010822/46802a52/NorbertSchade.vcf From norbertschade at oaktech.com Thu Aug 23 11:05:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> enumerations and IDs Message-ID: <000f01c12be5$1b3f1a30$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010823/535d7eb4/NorbertSchade.vcf From norbertschade at oaktech.com Thu Aug 23 11:24:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> web design Message-ID: <002101c12be7$bd510d90$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010823/d7d1d542/NorbertSchade.vcf From vortex3 at cardtown.com Fri Aug 31 00:54:15 2001 From: vortex3 at cardtown.com (vortex3@cardtown.com) Date: Wed May 6 14:04:57 2009 Subject: UPD> toner cartridges Message-ID: <7.464817.105891@cardtown.com> **** VORTEX SUPPLIES **** YOUR LASER PRINTER TONER CARTRIDGE, COPIER AND FAX CARTRIDGE CONNECTION SAVE UP TO 30% FROM RETAIL ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) HP DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) CANON BUBBLE JET CARTRIDGES 4) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)------------------------$44 ITEM #2 LASERJET SERIES 1100 (92A)-------------------------$44 ITEM #3 LASERJET SERIES 2 (95A)----------------------------$39 ITEM #4 LASERJET SERIES 2P (75A)---------------------------$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)---------- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)--------------------$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)-------------------$74 ITEM #8 LASERJET SERIES 8100 (82X)------------------------$145 ITEM #9 LASERJET SERIES 5L/6L (3906A)----------------------$35 ITEM #10 LASERJET SERIES 4V---------------------------------$95 ITEM #11 LASERJET SERIES 4000 (27X)--------------------------$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)-----------------------$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-------------------------$49 ITEM #13A LASERJET SERIES 5000 (29X)-------------------------$125 ITEM #13B LASERJET SERIES 1200--------------------------------$59 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)----------$49 ITEM #15 LASERFAX 5000,7000 (FX2)--------$54 ITEM #16 LASERFAX (FX3)------------------$59 ITEM #17 LASERFAX (FX4)------------------$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---------------$89 OPTRA R, 4039, 4049 HIGH YIELD-----------$105 OPTRA E310.312 HIGH YIELD----------------$79 OPTRA E-----------------------------------$59 OPTRA N----------------------------------$115 OPTRA S----------------------------------$165 OPTRA T----------------------------------$195 EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000----------$105 ACTION LASER 1000,1500--------------------$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95----------$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600------------------$49 LASER WRITER SELECT 300,320,360-----------------$74 LASER WRITER 300 AND 320------------------------$54 LASER WRITER NT, 2NT----------------------------$54 LASER WRITER 12/640-----------------------------$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---------------------------$59 LASERCLASS 5000,6000,7000 (FX2)-----------------$54 LASERFAX 5000,7000 (FX2)------------------------$54 LASERFAX 8500,9000 (FX4)------------------------$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)---------------------$69 PC 300,320,700,720,760,900,910,920(E-40)------$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. From vortex3 at cardtown.com Sat Sep 1 21:28:07 2001 From: vortex3 at cardtown.com (vortex3@cardtown.com) Date: Wed May 6 14:04:57 2009 Subject: UPD> toner supplies Message-ID: <621.893024.118994@cardtown.com> **** VORTEX SUPPLIES **** YOUR LASER PRINTER TONER CARTRIDGE, COPIER AND FAX CARTRIDGE CONNECTION SAVE UP TO 30% FROM RETAIL ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) HP DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) CANON BUBBLE JET CARTRIDGES 4) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)------------------------$44 ITEM #2 LASERJET SERIES 1100 (92A)-------------------------$44 ITEM #3 LASERJET SERIES 2 (95A)----------------------------$39 ITEM #4 LASERJET SERIES 2P (75A)---------------------------$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)---------- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)--------------------$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)-------------------$74 ITEM #8 LASERJET SERIES 8100 (82X)------------------------$145 ITEM #9 LASERJET SERIES 5L/6L (3906A)----------------------$35 ITEM #10 LASERJET SERIES 4V---------------------------------$95 ITEM #11 LASERJET SERIES 4000 (27X)--------------------------$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)-----------------------$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-------------------------$49 ITEM #13A LASERJET SERIES 5000 (29X)-------------------------$125 ITEM #13B LASERJET SERIES 1200--------------------------------$59 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)----------$49 ITEM #15 LASERFAX 5000,7000 (FX2)--------$54 ITEM #16 LASERFAX (FX3)------------------$59 ITEM #17 LASERFAX (FX4)------------------$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---------------$89 OPTRA R, 4039, 4049 HIGH YIELD-----------$105 OPTRA E310.312 HIGH YIELD----------------$79 OPTRA E-----------------------------------$59 OPTRA N----------------------------------$115 OPTRA S----------------------------------$165 OPTRA T----------------------------------$195 EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000----------$105 ACTION LASER 1000,1500--------------------$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95----------$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600------------------$49 LASER WRITER SELECT 300,320,360-----------------$74 LASER WRITER 300 AND 320------------------------$54 LASER WRITER NT, 2NT----------------------------$54 LASER WRITER 12/640-----------------------------$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---------------------------$59 LASERCLASS 5000,6000,7000 (FX2)-----------------$54 LASERFAX 5000,7000 (FX2)------------------------$54 LASERFAX 8500,9000 (FX4)------------------------$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)---------------------$69 PC 300,320,700,720,760,900,910,920(E-40)------$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. From vortex4 at cardtown.com Thu Aug 30 04:07:35 2001 From: vortex4 at cardtown.com (vortex4@cardtown.com) Date: Wed May 6 14:04:57 2009 Subject: UPD> toner cartridges Message-ID: <569.68994.89657@cardtown.com> **** VORTEX SUPPLIES **** YOUR LASER PRINTER TONER CARTRIDGE, COPIER AND FAX CARTRIDGE CONNECTION SAVE UP TO 30% FROM RETAIL ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) HP DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) CANON BUBBLE JET CARTRIDGES 4) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)------------------------$44 ITEM #2 LASERJET SERIES 1100 (92A)-------------------------$44 ITEM #3 LASERJET SERIES 2 (95A)----------------------------$39 ITEM #4 LASERJET SERIES 2P (75A)---------------------------$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)---------- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)--------------------$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)-------------------$74 ITEM #8 LASERJET SERIES 8100 (82X)------------------------$145 ITEM #9 LASERJET SERIES 5L/6L (3906A)----------------------$35 ITEM #10 LASERJET SERIES 4V---------------------------------$95 ITEM #11 LASERJET SERIES 4000 (27X)--------------------------$72 ITEM #12 LASERJET SERIES 3SI/4SI (91A)-----------------------$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-------------------------$49 ITEM #13A LASERJET SERIES 5000 (29X)-------------------------$125 ITEM #13B LASERJET SERIES 1200--------------------------------$59 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)----------$49 ITEM #15 LASERFAX 5000,7000 (FX2)--------$54 ITEM #16 LASERFAX (FX3)------------------$59 ITEM #17 LASERFAX (FX4)------------------$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---------------$89 OPTRA R, 4039, 4049 HIGH YIELD-----------$105 OPTRA E310.312 HIGH YIELD----------------$79 OPTRA E-----------------------------------$59 OPTRA N----------------------------------$115 OPTRA S----------------------------------$165 OPTRA T----------------------------------$195 EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000----------$105 ACTION LASER 1000,1500--------------------$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95----------$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600------------------$49 LASER WRITER SELECT 300,320,360-----------------$74 LASER WRITER 300 AND 320------------------------$54 LASER WRITER NT, 2NT----------------------------$54 LASER WRITER 12/640-----------------------------$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---------------------------$59 LASERCLASS 5000,6000,7000 (FX2)-----------------$54 LASERFAX 5000,7000 (FX2)------------------------$54 LASERFAX 8500,9000 (FX4)------------------------$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)---------------------$69 PC 300,320,700,720,760,900,910,920(E-40)------$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. From deptsales18 at mail.com Thu Sep 6 15:56:08 2001 From: deptsales18 at mail.com (deptsales18@mail.com) Date: Wed May 6 14:04:57 2009 Subject: UPD> Not getting sex? Get .Sex domains! 22460 Message-ID: <200109061956.PAA16230@pwg.org> The latest domain name extension is here .SEX!!! It's the fresh ,new, exciting web address that is taking the world by storm. Who wants to be .com when you can now be .SEX Register your .SEX domain name today exclusively at: http://www.dotsex.com ------------------------------------------------------------------------- To be taken off the mailing list please click below: http://195.178.213.33/unsubscribe.phtml From hamzy at us.ibm.com Mon Sep 10 17:17:49 2001 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:04:57 2009 Subject: UPD> Point Of Sale printers. Message-ID: Hello, Have you considered Point Of Sale (POS) printers in UPDF? I am looking at a technical reference for one right now and it has an interesting feature. There are two rolls of paper in this printer and you can print to them in the following ways: - Print only on the left roll. This is torn off and given to the customer. - Print on the left roll and print a duplicate to the right roll. This roll is called a "journal" roll. - Image the form size to be twice the size of the roll. Any print data that does not fit onto the left roll is overflowed and printed on the right roll. This way you can print two different things at one time. Also, the roll paper is 228 pels wide at 90 dpi. This translates into a form size of 2.5333333333333333333333333333333... inches. The length of the form can be between 1/72 of an inch to an infinite length. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at oaktech.com Mon Sep 10 18:23:30 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> Point Of Sale printers. References: Message-ID: <000b01c13a47$38974010$551414ac@hsg.ma.oaktech.com> Mark, it's some time ago that I dealt with POS printers. But some problems sound familiar. No, we haven't thought about those printers in UPDF in detail. I guess we could more or less solve the media size. Assuming we only print on the left roll, I propose a width of 2.534 inch (x 90 = 228.06 pixel), as that would provide 228 pixel after any correct rounding. 2.54 inch may result in 229 pixels after rounding. Any value below 2.534 inch (like 2.5334 or 2.53334, etc.) would be correct as well, but not result in a different number of pixels. With the length it's the old problem with rolls. Operating systems like MS Windows like to know the length upfront. So my feeling is that the only way to go is to define quite a long size (be sure that traditional solutions used in OS's or apps can report it with 16 bit; 15 bit would even be safer). But with that narrow width you should be on the safe side with 12 inch length (one of the guidelines I used was to be able to print any character size on one page, where the width kind of limits the height. You'd come to a virtual but reasonable size of custom_pos_2.534x12in . You'd need something to find out if a page is the last page - as you would need for any kind of roll handling in these OS's. And then you'd need a flag to tell to stop after printing the last line of data on the last page and not feed until page end. We do not have such a flag yet. That would be a media source specific attribute I guess. The resolution values of 90 x 72 dpi work even fine with virtual units of 7200. Not a problem. Now the real problem might be the journal. I'd expect a special application to position everything properly for the double-size paper (you wouldn't print your letter here). Being afraid that the journal is not printed by a simple copy command, the driver would have to print every data twice (please confirm). That's certainly something we haven't thought about - and will not in short-term. That's my two cents. Perhaps somebody else has a better idea. Regards Norbert Schade ----- Original Message ----- From: "Mark Hamzy" To: Sent: Monday, September 10, 2001 5:17 PM Subject: UPD> Point Of Sale printers. > Hello, > > Have you considered Point Of Sale (POS) printers in UPDF? > I am looking at a technical reference for one right now and it has an > interesting feature. > There are two rolls of paper in this printer and you can print to them in > the following > ways: > - Print only on the left roll. This is torn off and given to the > customer. > - Print on the left roll and print a duplicate to the right roll. > This roll is called a "journal" roll. > - Image the form size to be twice the size of the roll. Any print > data that does not fit onto > the left roll is overflowed and printed on the right roll. This > way you can print two > different things at one time. > > Also, the roll paper is 228 pels wide at 90 dpi. This translates into a > form size of 2.5333333333333333333333333333333... inches. The length of > the form can be between 1/72 of an inch to an infinite length. > > Mark > > Take a look at the Linux Omni printer driver at > http://www.ibm.com/linux/ltc/projects/omni/ > From norbertschade at oaktech.com Wed Sep 12 17:49:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> some editing Message-ID: <001b01c13bd4$d6c42990$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010912/5c580b39/NorbertSchade.vcf From norbertschade at oaktech.com Thu Sep 13 09:50:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> compatibility, appearance Message-ID: <002f01c13c5b$0aff5280$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010913/04cba41a/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 11:27:14 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> changes done so far Message-ID: <000d01c13d31$bb614350$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/78046e44/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 12:56:33 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> item 9 Message-ID: <001d01c13d3e$3537a370$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/25e91974/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 13:14:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> item 15 Message-ID: <000f01c13d40$b68cb300$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/303beb97/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 14:36:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> item 11 Message-ID: <002301c13d4c$21495f30$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/61cb1c57/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 16:11:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> item 5 Message-ID: <005301c13d59$7b7a4980$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/bfd00258/NorbertSchade.vcf From norbertschade at oaktech.com Fri Sep 14 16:23:21 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> web site updated Message-ID: <003701c13d5b$19462430$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/dd120ea7/NorbertSchade.vcf From norbertschade at oaktech.com Thu Sep 20 09:26:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:57 2009 Subject: UPD> file update Message-ID: <001501c141d7$e5f690c0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010920/ba92d0d5/NorbertSchade.vcf From jsommer at bellatlantic.net Thu Sep 20 09:28:17 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:57 2009 Subject: UPD> Items 5 and 11 Message-ID: <4.3.2.7.2.20010920092331.00a90c70@mailbox.bellatlantic.net> I want to throw in my 2 cents on these. Item 5 - Parameter Converter and UI Strings It would make my life easier if we didn't use the parameter converter for UI strings but I can see the usefulness of this function. If we do allow it, I think the place for it is in the Name_ID and not the string itself. My main reason it that this keeps our locale files clean for easy translation which was the whole point of moving the UI strings to separate files in the first place Item 11 - IDs Though I appreciate the concept behind making the classifying attributes unique, I think it creates two problems. 1) The UPDF becomes less readable. For instance, media sizes and margins would be separate items and you'd have to go to a third place to find how they are related. 2) Composite Features or Interdependencies would be required to do just a simple printer description. These are powerful and very useful features and, I imagine, every printer description will use at least one of them. However, in the course of creating a printer description or driver, it will be much easier to do the device description first and verify it. After that is complete, the user interface (composite features and interdependencies) can be considered. By separating margins from media sizes, they must be connected by either a composite feature or interdependencies. So, just to get something to print correctly, these functions would have to be implemented. Also, since either function could be used, there would be no common method of relating media size with margins. I think we'd create more problems than we'd fix by eliminating the unique IDs. Jim mailto:sommer@granitesystems.com 978-486-3068 From norbertschade at oaktech.com Thu Sep 27 17:51:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> Decision: items 11, 12 Message-ID: <001101c1479e$83f83050$551414ac@hsg.ma.oaktech.com> The decision is that we will keep it as it is. That means we will go on with a unique attribute called 'ID' plus one or more classifying attribute with other names like 'Predefined_ID' or 'Proprietary_ID' per feature. The defaults are decided as well. We will not save classifying attribute settings, but the unique ID of a feature. I have edited the current sample and added many more defaults. No generic features yet, as that is another open item. No generic PDL output features yet, as that is another open item. All files are on our web site. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Friday, September 14, 2001 2:36 PM Subject: UPD> item 11 This is a very controversary item and probably the one with the most confusion about. 1. The attribute ID currently is the attribute uniquely identifying a certain record of an element like a feature, e.g. media size or device resolution. ID has to be unique per UPDF description, but can have any form (ID_5, Norbert_s_size, 234, size80, etc.). Generally it's useless to try to interpret ID. 2. Additionally to ID we have a number of classifying attributes with technical meaning. The entries in most if not all cases follow certain rules. They can be interpreted. Samples for classifying attributes are Predefined_ID/Proprietary_ID, KB, HorizontalResolution, etc. Excerpt for Predefined_ID/Proprietary_ID I tried to explain this a number of times. I'll try again. We need a way to sometimes select from a list of predefined keywords (like coming from the standardized media names specification or from our own UPDF specification), but still be able to enter another value. This requires an editable combo box. That's not possible under the XML applications I know of. So we built a work-around by specifying one attribute Predefined_ID, where all the predefined keywords are listed, plus another attribute Proprietary_ID, where somebody can enter an arbitrary value (if we haven't defined a list of keywords, you may only see the one attribute Proprietary_ID). If a feature uses both attributes, we understand them as one merged list. To do that we add one more predefined keyword to the list called 'proprietary-media-size' (or similar). The rule is to look for the keyword in Predefined_ID, but in case that attribute shows 'proprietary-media-size' (or similar) look in Proprietary_ID. By that mechanism we have created something like an editable combo box. That's why I show the two attributes together in most cases separated by a slash. I hope you're with me so far. In my world (and believe me I know it may not represent the whole world) I would save the unique ID in my driver, whenever I save the current setting of a feature. Under Windows that's done mainly in the registry, but another mechanism wouldn't make a difference for me. To the operating system or application I would always announce classifying attributes like I'd find in Predefined_ID/Proprietary_ID for media size or in HorizontalResolution and VerticalResolution for device resolution, etc. In interdependencies I would be allowed to work with the unique ID as well as with some classifying attributes (could be discussed). Classifying attributes may make some interdependencies shorter. Classifying attributes in my view are not necessarily (but often) unique. You may have a device resolution record for a true 600 dpi and another for a FastRes (600 dpi with another PJL command). Other cases with other features can be composed. That would mean the classifying attribute the driver/client announces to the application is not necessarily unique - for me not a problem. One of the discussions is to make the classifying attributes unique (and therefore perhaps be able to let the attribute ID go completely, as it would not be needed any more as an additional identifyer). I think the key statement of this email is that I'd save and work with the unique ID in my driver, but communicate classifying ID's with the OS/application. I said earlier that this item affects item 12. We have to decide whether we want to save defaults with the unique ID or differently. Regards Norbert Schade Principal Software Engineer Advanced Development / Connectivity Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010927/640dbdb1/attachment.html From norbertschade at oaktech.com Fri Sep 28 09:59:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> variable entries in attributes Message-ID: <002301c14825$dac30bd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010928/30646bc6/NorbertSchade.vcf From jsommer at bellatlantic.net Fri Sep 28 12:02:16 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> variable entries in attributes In-Reply-To: <002301c14825$dac30bd0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.3.2.7.2.20010928105917.00aa6bc0@mailbox.bellatlantic.net> We've done a great job of making elements and attributes consistent. As I write my UPDF parser, I've found it very easy to generalize all the print media handling selections except for copies and zooming. These two are just different so we might as well just deal with them differently and in the clearest way we can. I think we should add the elements MinimumValue, MaximumValue, IncrementValue, and CommandSequence_ID to MediaCopiesList and MediaZoomingByPercentageList. We can then delete the elements MediaCopy and MediaPercentage. Finally, MediaCopiesList should be renamed MediaCopies and MediaZoomingByPercentageList should be renamed MediaZoomingByPercentage. I agree that we should change all enums so that they use the same predefined value ("proprietary-value") to indicate that a proprietary value is provided. This is another good step towards constistency. I think defaults should be done by unique ID except for copies and zooming. A unique ID just doesn't make sense so lets just specify the integer value. Finally, I propose that we create unique names for all values we want to use with defaults and interdependencies instead of using the dot syntax we previously discussed. It accomplishes the same thing but in a much more readable format. For instance lets just say that COPIES is used to specify the default value for copies in addition to being the name used in interdependencies when checking or setting values. This list makes it clear to both the UPDF creator and the UPDF driver what can be controlled. Since I've started talking about interdependencies, I'd also like to propose that our conditions be limited to "equal" and "not equal". I believe that all conditions can still be covered this way and it will make processing the interdependencies much easier. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010928/e84150ea/attachment.html From norbertschade at oaktech.com Mon Oct 1 12:50:42 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> latest discussions Message-ID: <003e01c14a99$356d45d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/7ae55567/NorbertSchade.vcf From norbertschade at oaktech.com Mon Oct 1 13:01:03 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> legal info Message-ID: <002701c14a9a$a740b7e0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/b7ed4922/NorbertSchade.vcf From norbertschade at oaktech.com Mon Oct 1 15:17:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> item 13 Message-ID: <001101c14aad$c542ede0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/238afd43/NorbertSchade.vcf From norbertschade at oaktech.com Mon Oct 1 15:31:14 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> item 5 Message-ID: <003d01c14aaf$a25cd690$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/b40e8f0e/NorbertSchade.vcf From don at lexmark.com Wed Oct 3 14:49:14 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:58 2009 Subject: UPD> test Message-ID: <200110031849.OAA17227@interlock2.lexmark.com> test... ignore ********************************************** * Don Wright don@lexmark.com * * * * Chair, IEEE MSC * * Member, IEEE SA Board of Governors * * Member, IEEE-ISTO Board of Directors * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** From jsommer at bellatlantic.net Thu Oct 4 11:52:13 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> Unique ID: String->Integer Message-ID: <4.3.2.7.2.20011004113947.00aa5860@mailbox.bellatlantic.net> I had been just assigning consecutive integer values to each unique ID. This worked fine but I ran into some situations (installing/uninstalling options) where the integer ID changed for a specific unique ID string. This meant that any integer ID that I had saved in the driver was no longer valid. I was looking for an algorithm to convert the unique ID strings into unique ID integers. I don't really need all ID integers to be unique, just all those in the same list (MediaSizeList, MediaTypeList, etc) need to be unique. I also need them to be consistent even if new ID's are added or some disappear. Norbert suggested the algorithm used to generate the LPTENUM checksum. I hunted down the algorithm and found that it generates unique ID integers for all the ID strings in the sample implementation. I would be a little happier if it generated 32-bit ID integers, but so far it works fine. Here's the code: WORD wCRC16a[16]={ 0000000, 0140301, 0140601, 0000500, 0141401, 0001700, 0001200, 0141101, 0143001, 0003300, 0003600, 0143501, 0002400, 0142701, 0142201, 0002100, }; WORD wCRC16b[16]={ 0000000, 0146001, 0154001, 0012000, 0170001, 0036000, 0024000, 0162001, 0120001, 0066000, 0074000, 0132001, 0050000, 0116001, 0104001, 0043000, }; short Get_CRC_CheckSum(void *pBuffer, ULONG ulSize) { BYTE *pb; BYTE bTmp; ULONG ulSeed=0; for (pb=(BYTE *)pBuffer; ulSize; ulSize--, pb++) { bTmp=(BYTE)(((WORD)*pb)^((WORD)ulSeed)); // Xor CRC with new char ulSeed=((ulSeed)>>8) ^ wCRC16a[bTmp&0x0F] ^ wCRC16b[bTmp>>4]; } return (short)ulSeed; } The seed is set to 0 each time so that the ID will always be the same for a given string. If anyone has any comments or suggestions for a 32-bit CRC, I'd be happy hear. Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Thu Oct 4 15:12:35 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> item 10 Message-ID: <4.3.2.7.2.20011004151205.00aa1d10@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Monday, October 01, 2001 5:36 PM >Subject: item 10 > >last change for today. >Like for GenericPDLOutput features we wanted to get rid of the enumerated >feature list (generic feature 1, generic feature 2, etc.). Does not look >smart, blows it up unnecessarily, you do all the same a number of times >just under slightly different names. >So we added a Feature_ID to any GenericFeatureList (corresponds to any >other feature list like MediaSizeList), which identifies the feature. Now >we can name all the lists the same, as this Feature_ID gives us the chance >to differenciate between them. >This settles item 10. Of the long list of open items we have left numbers >8, 9, 14 and 15. Looks good to me for the last days. > >Please check it out. The mother sample has been changed accordingly. >You'll find all files on the web site in some minutes. > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/e4ba0f42/attachment.html From jsommer at bellatlantic.net Thu Oct 4 15:12:55 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> item 15 Message-ID: <4.3.2.7.2.20011004151241.00aa7da0@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 9:38 AM >Subject: item 15 > >I have added an attribute CompatibleUPDF to all features on the level of >the xxxList. >That means somebody can declare a complete feature compatible to another >model. >It is not possible to declare single records of a feature compatible. >It is open where this attribute should refer to. Until further notice it >holds references to other device description files (no file extension). >Feedback appreciated. > >Purpose of this attribute: >1. Printer manufacturers may build a number of UPDF descriptions, where >especially within model families features are indentical. This reference >may save some testing and QA time. >2. If a developer connects to an internal database for printer data, this >reference can be used to avoid duplicating records. > >This settles item 15 until further input on the reference. > >Item 9 is considered more or less settled, as we haven't heard anything >since Toronto though I asked a number of times. I will keep that open >until Friday this week. >That leaves us with item 8 (group licence), where we have some proposal >from IBM, and item 14 (raster graphic and event handlers). >these are anyhow issues under current development. So I will not further >refer to the item list any more. It is considered done (with the exception >of current development for items 8 and 14). > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/609913b4/attachment.html From jsommer at bellatlantic.net Thu Oct 4 15:13:19 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> consistent Predefined_ID, Proprietary_ID Message-ID: <4.3.2.7.2.20011004151302.00aa0c80@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 10:26 AM >Subject: consistent Predefined_ID, Proprietary_ID > >I wonder whether it would further help us, if we'd equip all features with >Predefined_ID/Proprietary_ID. >One reason we didn't so far is that some features need to classifying >attributes for a proper description. Samples are all features, which are >mainly described depending on horizontal and vertical resolution. >There is a solution, if we want. >We could specify some simple syntax, which we can more or less borrow from >the Media Standardized Names spec. >Checking device resolution the keywords could look like 'resolution_12x12' >(still related to the virtual units like 7200). So this would represent a >600 dpi resolution. >Haven't thought about it thoroughly, but just an idea. >Eventually we could end up with classifying Predefined_ID/Proprietary_ID >attributes in all features. > >any feeling? > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/a2f25420/attachment.html From jsommer at bellatlantic.net Thu Oct 4 15:13:39 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> user group policies Message-ID: <4.3.2.7.2.20011004151323.00aa71d0@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 12:51 PM >Subject: user group policies > >Now that we have solved some bugging items, we can concentrate on the >future design again. >I'd like to do an outlook on user group policies that we all together >become a bit more familiar with it. >Assuming that normally a developer of the printer manufacturer would write >the complete set of an UPDF description, the result is a neutral >description of one specific model. >A number of users, especially large enterprises, like to go a step further >and specify some needs for themselves. >These specifications are normally set by supervisors or administrators. >They create sets for single users or user groups. >1. They may like to set user specific defaults differing from the original >IHV defaults. >These defaults should become active right during installation of the >driver/client and should not need any extra step by the user. He/she >should not even notice it. >2. Another nice-to-have feature might be to manipulate the complete user >interface. That could mean either hide certain entries of a UI control, >hide some controls completely or even create new controls. > >This is the area we call user group policies. >I'm going to make some statements as the first input. Please feel free to >contradict, change and add. So far we have not specified in detail, which >of the features we will be able to accomplish in UPDF, and especially in >UPDF level 1. > >Required features >1. Special defaults. >2. UI manipulation. >2.1. Manipulate entries of UI controls. >2.2. Manipulate the appearance of UI controls. >2.3. Add new UI controls. > >The first question is where do these users get their UPDF description >from. Normally it may be stored on a storage medium (CD, etc.), on a web >site or even in the printing device. Only on a storage medium there would >be the chance for a supervisor to edit files like the device configuration >xml file to add user group policies. >So for now we make the assumption that the supervisor will create >directories per user or user group to hold all files necessary for >installation. >We further assume that the supervisor has good to excellent knowledge >about UPDF and will be responsible for the intended changes. We only can >provide the structures. > >Feature 1 >There is a rather simple solution. When all files are copied somewhere, a >supervisor can change the locale files and especially the LocaleDefault >elements. No technical problem. >Though technically possible we may not recommend to add/remove complete >locales and make the proper changes in the configuration file. >As I hate somebody changing the original UPDF files, I'd could imagine >another approach. The only modifications to the original files should be >done to the unit configuration xml files (we could prepare that in the >schemas by adding an optional element, which we and the IHV normally would >never use). If the optional element for user group policies is present, it >holds all information the driver needs. May need some thinking. But now >the supervisor is able to add his own locale references, which hopefully >have been copied from the original ones first, and refer to anything else >he/she needs. We need common rules for that. > >Feature 2.1 >Hmmm. I'm a little hesitant here. The interdependencies would be the tool >to allow something like 'if this record of this feature is selected, >select that record of another feature'. 'hide this record' might be >something else a supervisor wants to do. We do have an Appearance >attribute on the feature level, but not one on the record level. >Add a new record for a feature seems difficult as well. I only can imagine >this to work with certain composite features like a global driver setting >control feature. Would be very difficult to specify. >Additionally I guess that all original interdependencies should still >work. So a new one should not interfer with any original. That needs some >concentration, if possible at all in any case. > >Feature 2.2 >Making certain UI controls disappear completely from the UI does not seem >to be such a technical problem. >I guess the UI dimensions would still be the same. There would just be >some holes. >As every feature has a default, they all have an active setting. That rule >is not broken, when the setting would change in the background by some >interdependency. > >Feature 2.3 >New controls can only be composite features! That's the only instance >where the driver might be prepared to face controls, which meaning it does >not understand - and need not. >The only reasonable control I can think of is a 'User Specific Setting' >control, set on top of all other controls as a composite feature. >All entries would have to be handled by the supervisor, of course. We >would not interfer with any original control. >There are still a number of questions like the default for this (or these) >control(s). And should it or they be localized? > >Anyhow, whatever UI manipulation we may have in mind, my point is it has >to be done outside the original UPDF description. > >Ok, I wanted to initiate that discussion before San Antonio and show that >I have some thoughts about it. >But that's not enough to get it going. > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/252ce502/attachment.html From jsommer at bellatlantic.net Fri Oct 5 11:37:51 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> Orientation/Rotation Message-ID: <4.3.2.7.2.20011005113010.00a9e380@mailbox.bellatlantic.net> We currently have one element for orientation that has the possible values of: 1) Portrait 2) Landscape 3) Rotated Portrait 4) Rotated Landscape In my mind we have really created a composite feature of orientation (portrait/landscape) and rotation (off/on). Generally, orientation is a setting that an application controls and cares about so that it formats data properly. Rotation is something that the driver cares about so that the image is put on to the paper properly. If a user has a media (like 3 hole punch) that must be loaded in the printer in the rotated direction to prevent jamming, then the user will want to select rotate regardless of the orientation that may be selected within an application. I propose that we split the current orientation selection into two - orientation and rotation. Comments? Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Fri Oct 5 15:58:05 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:04:58 2009 Subject: UPD> legal info Message-ID: <4.3.2.7.2.20011005155725.00aaf3d0@mailbox.bellatlantic.net> >I've asked a number of times for statements on the Toronto request for >additional attributes for specifying strings for legal info. >There was no feedback so far. >So this is off the table, until I get a carefully prepared request with >samples again. >That settles item 9. > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011005/1b3a0859/attachment.html From norbertschade at mediaone.net Mon Oct 15 10:42:58 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> test 10.15.01 Message-ID: <000c01c15587$afdfa4e0$f2755b18@ne.mediaone.net> please ignore Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011015/45c31b91/attachment.html From rvandekimmenade at nl.ibm.com Tue Oct 30 05:30:49 2001 From: rvandekimmenade at nl.ibm.com (Roger J van de Kimmenade) Date: Wed May 6 14:04:58 2009 Subject: UPD> UPDF Message-ID: Hello, My name is Roger van de Kimmenade and i am currently involved in a project making a controller for print and scan engines. I want to describe the printer characteristics and resources in a generic way, using XML. I looked onto internet and came to your site. My question: Do you already have some code, to read an XML file, using the UPDF.dtd file ? Met vriendelijke groet/with kind regards, Roger van de Kimmenade BIS/EBI Regional Development Center Eindhoven IBM Global Services Beukenlaan 149, 5616 VD, Eindhoven The Netherlands Tel: (+31)(0) 20 513 1739 Email: RvandeKimmenade@nl.ibm.com From norbertschade at mediaone.net Tue Oct 30 08:14:38 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:04:58 2009 Subject: UPD> composite features Message-ID: <001201c16144$d4538bc0$60765b18@ne.mediaone.net> We have added an attribute UserExtensible to the CompositeFeature element. Default of this boolean is true. If a composite feature is user extensible the user can assemble a new ComponentSet and those can be deleted again. ComponentSet elements created by the printer manufacturer can never be deleted. I have created one small sample for 'Media' so far, just to have something to show and discuss. Two predefined media records plus one for discussion purpose. Here I mainly assign a UI string for a new media created by the end user. Where else would we get that string from? Do we need that string (and therefore the record) at all? To keep everything consistent not only generic features get an ID to identify the feature, but all predefined features as well (fixed attribute) as composite features. Regards Norbert Schade Principal Software Engineer Advanced Development / Connectivity Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011030/6408b715/attachment.html From hastings at cp10.es.xerox.com Wed Jan 17 12:57:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:07 2009 Subject: UPD> PWG media size name mini-project Message-ID: <918C79AB552BD211A2BD00805F15CE85045E1003@x-crt-es-ms1.cp10.es.xerox.com> To: Ron and others interested in the PWG mini-project to compile an open list of standard media size names for use in IPP "media" attribute, UPnP, Bluetooth, Printer MIB, IPP FAX, Internet FAX, etc. At the December UPnP Imaging WG meeting, the they requested that the PWG compile a list of standard media size names, rather than inventing its own set for UPnP. Other protocols have the same requirements and slightly different sets of lists. Having a single set of media size names will help a lot. There may need to be alias names for a few sizes where there are different names for the same media size. At the December PWG meeting, Ron Bergman volunteered to start making a list. Mike Shepherd from Xerox is willing to work with Ron on this. Please take a look at the compilation that Jim Lo from Sun compiled (see attached email fragment) and sent to the IPP and UPD DLs in November. He researched the IPP, GPD, and PPD (and others) for media size names and compiled a list that he sorted by size name, by size, and by source. I've converted his .html to LANDSCAPE .doc and .pdf so that it prints without truncation. I've copied it to a new sub-directory: new_MEDIA (which we can use for the media object in the future as well). I've also copied two RFCs that have media sizes for Internet FAX (see email attached from Lloyd McIntyre). ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/papersizes-ipp-gpd-ppd.htm ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/rfc2534.txt ftp://ftp.pwg.org/pub/pwg/ipp/new_MEDIA/rfc2879.txt Thanks, Tom -----Original Message----- From: Jim Lo [mailto:Jim.Lo@eng.sun.com] Sent: Tuesday, November 14, 2000 12:37 To: upd@pwg.org; ipp@pwg.org Subject: IPP> Re: UPD> registered parameters Hi, Just in case it may be of any help, attached please find the collection of all predefined paper sizes from many standards (number of entries -- all:175 / IPP:73 / GPD:117 / PPD:151) Best regards ................... Table of Content ---------------- A. PaperSizes (all/GPD/PPD/IPP/TIPSI/ISO/JIS) Sorted By Name/Size B. Feature/Option Display Names For en_US Locale Outline ------- A. PaperSizes (all/GPD/PPD/IPP/TIPSI/ISO/JIS) Sorted By Name/Size 1. All PaperSizes (Sorted By Name) 2. All PaperSizes (Sorted By Size) 3. IPP PaperSizes (Sorted By Size) 4. PPD PaperSizes (Sorted By Size) 5. GPD PaperSizes (Sorted By Size) //The table contains the option keywords currently registered for all (version 1.0) PaperSize feature, //which designates a given physical paper size on a printing device. Most of those predefined options //are from the following standards: // // IPP: Internet Printing Protocol (PWG) // // ISO: International Standard Organization // // JIS: Japanese Industry Standard // // TIPSI: Transport Independent Print System Interface (Lexmark) // // PPD: PostScript Printer Description format (Adobe) // // GPD: Generic Printer Description format (Microsoft) -----Original Message----- From: McIntyre, Lloyd Sent: Tuesday, November 21, 2000 17:41 To: Hastings, Tom N; McIntyre, Lloyd; Hastings, Tom N Cc: McDonald, Ira; Herriot, Robert; Buckley, Robert R Subject: RE: IANA registry of media size names [where's the beef?] Tom, The beef [media size names for Internet FAX] is in the two RFC references, RFC 2534 (Section 2: Media Feature Registrations) and 2879 (Appendix A: Feature registrations). This list no where as exhaustive as that you have provided. It is, however, open for expansion. Lloyd From norbertschade at oaktech.com Fri Feb 23 14:48:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> UPDF 2001 schedule Message-ID: <004701c09dd1$8e7b60f0$500714ac@NSCHADEW1> One item on the upcoming agenda for Tampa will be discussing the future of the UPDF group, especially concerning the lead and conferences. I propose two other conferences in 2001: the one in Toronto and the one in Texas. Targets for Toronto are to discuss some real device descriptions based on our format, work out the difficulties while creating them and solve remaining issues. I hope that we get three to five samples from printer manufacturers, even if they are incomplete in some sections. Group 1 of candidates include Oak, Lexmark, Canon, Xerox and Hitachi. Among others Sun will be another contact. We should get to a more detailed plan in Tampa. Second target for Toronto would be discussing the chances for driver implementation of the format to be able to test and find weaknesses. Group 1 of candidates include IBM and Granite Systems. I will check inhouse. Target for Texas would be presenting level 1 of the format to the public. This certainly needs a lot more work done on the documentation side. As we all (myself included heavily) are facing serious budget cuts, to accomplish these targets would need some extra work other than f2f meetings. I'd like to have a tele con on Monday of the April PWG instead of a f2f meeting. Some more tele cons would be necessary, probably once a month until Texas. We need some people dedicating themselves to certain jobs. I consider two to three days per month per company (until Texas). Above statements tell about the tasks. As I would like to create a detailed plan and schedule in Tampa, I am soliciting feedback. For those, who attend the Tampa meeting, please give a general impression. Do you think it's doable? Counter proposals? Improvements? For those, who cannot attend Tampa, please provide a detailed statement. Check on what tasks you and your company can work. Provide your feedback during next week, before Tampa, so that we'll have it on the table. A more detailed agenda for Tampa will follow. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010223/8d00393f/attachment-0001.html From richNOgSPAM at plustechnologies.com Mon Feb 26 10:45:41 2001 From: richNOgSPAM at plustechnologies.com (Rich Gray) Date: Wed May 6 14:05:07 2009 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! **VIRUS ALERT** Message-ID: <3A9A7A25.2AA5F8CA@plustechnologies.com> This e-mail tripped our virus scanner: Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: undisclosed-recipients From: Hahaha Sent: 444700810,29401015 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! Attachment Details:- Attachment Name: sexy virgin.scr File: sexyvirg.scr Infected? Yes Repaired? No Virus Name: W32/Hybris.gen@MM -- Richard B. Gray, Sr. Software Egr. Plus Technologies division of Digital Controls Corp. mailto:richNOgSPAM@plustechnologies.com (remove NO SPAM to reply) http://www.plustechnologies.com From lombardiv at earthlink.net Mon Feb 26 10:46:13 2001 From: lombardiv at earthlink.net (Victor J. Lombardi) Date: Wed May 6 14:05:08 2009 Subject: UPD> Snowhite and the Seven Dwarfs - The REAL story! **VIRUS ALERT** References: <3A9A7A25.2AA5F8CA@plustechnologies.com> Message-ID: <3A9A7A45.C0853B7C@earthlink.net> This guy should be shot!!! Rich Gray wrote: > This e-mail tripped our virus scanner: > > Action Taken: > An attempt to disinfect the attachment was unsuccessful, > so the attachment was quarantined from the message and replaced with > a text file informing the recipient of the action taken. The infected > attachment > has been placed in the designated quarantine folder. > Please exercise extreme caution when handling the quarantined attachment > > To: > undisclosed-recipients > > From: > Hahaha > > Sent: > 444700810,29401015 > > Subject: > UPD> Snowhite and the Seven Dwarfs - The REAL story! > > Attachment Details:- > > Attachment Name: sexy virgin.scr > File: sexyvirg.scr > Infected? Yes > Repaired? No > Virus Name: W32/Hybris.gen@MM > > > > -- > Richard B. Gray, Sr. Software Egr. > Plus Technologies division of Digital Controls Corp. > > mailto:richNOgSPAM@plustechnologies.com (remove NO SPAM to reply) > http://www.plustechnologies.com From norbertschade at oaktech.com Mon Feb 26 11:59:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> Tampa agenda Message-ID: <009701c0a015$85d7be80$500714ac@NSCHADEW1> I propose the following agenda: 1. UPDF schedule and directions in 2001 What meetings should we have and what will the milestones be, until we can represent level 1 of the format? Who will provide sample UPDF descriptions for some real printers and work on some sample implementation on the driver side? 2. Global paper size list That's Ron Bergman's list. 3. Command sequences in a separate module This should especially help easing the creation of font modules, but would generally make it easier to transfer a printer's description from one PDL to another. 4. Color One of the last open sections. 5. File structure and file names. We have to settle down this section more in detail. Here it comes to questions how installable options will be handled and what sections of a description are separate modules. If you have additional requirements please let me know. Regards Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010226/f98ef950/attachment-0001.html From norbertschade at oaktech.com Tue Feb 27 16:57:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> command sequences Message-ID: <002001c0a108$3b158410$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 6884 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 686 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFCommandSequences-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 663 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 4833 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150.xml Type: text/xml Size: 19206 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__Locale en_us.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150__Localeen_us-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__CommandSequences.xml Type: text/xml Size: 2336 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010227/9b5fb14e/HPLaserJet8150__CommandSequences-0001.xml From norbertschade at oaktech.com Wed Feb 28 11:54:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> command sequences Message-ID: <000d01c0a1a7$2f71ee60$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: HP LaserJet 8150__CommandSequences.xml Type: text/xml Size: 2786 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/e9c0d657/HPLaserJet8150__CommandSequences-0001.xml From norbertschade at oaktech.com Wed Feb 28 13:52:50 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> media sizes Message-ID: <000c01c0a1b7$a6260310$500714ac@NSCHADEW1> In the files I spread around yesterday I created a temporary test size, which I will remove again in the public files. It is very similar to the normal Letter size. This was to demonstrate the chance of having two media sizes with the same MediaSize_Global_ID and/or MediaSize_Name_ID. In this case the value for x and y are identical as well. In case these values are switched, I would expect the RotatedFormat field to be set to TRUE the same time. The ID field should always be unique, as it is in this case. The major difference is the field FeedingMethod. A sample in the real world could be that a Letter has to be fed shortedge from the manual tray, but longedge from other trays. In this case the CommandSequence_ID is different, which is not necessarily the case. Another case where you would want to create a second Letter size with even all fields set to the same values would be, if you have different minimum hardware margins for it in different trays. These are just some usability studies how to work with the fields. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010228/b508296e/attachment-0001.html From norbertschade at oaktech.com Wed Feb 28 15:28:49 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> installable options Message-ID: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> We need more discussion on that issue. this is part of item 5 of the Tampa agenda. We have agreed so far that the same set of dtd files would be used for any installable option, so you would have a new set of XML files for any installable option. that will make it easy to remove it again at any time. Definition I consider any piece of hardware, which can be physically removed from the peripheral device, an option. This may include RAM cards, input options, output options, duplexers or anything else. Rule 1: Do not specify any option in the master description. Options may come with the device - as part of the original shipment. Or they can be bought and added later. Newer options may even replace older ones. Required features Any driver should provide some functionality to ensure that at least one element is available for certain features. For printers these features include input and output features (to be discussed). RAM? So in most descriptions a master description would include an input feature, but in theory it doesn't need to. The printer could be shipped with one or more default options. Same with RAM. Now how do we specify that in detail? I see three chances to do that. 1. We could do something with the file names. Primitive sample: Printer ABC Master.xml, Printer ABC Option 2 Input Trays.xml, Printer ABC Option Duplexer, etc. Looks doable. Advantage would be to have an easy search for options when you have the master description. Sounds a bit artificially constructed and wooden. 2. We could provide some fields internally. We could create a field "Master Unit". In case this fields entry matches the unit name of the description, it must be the master. Otherwise this field would list the unit name of the master description. The master field would be repeatable to be able to tell that a certain unit can be added to a number of master descriptions. Sounds a little more sophisticated, but I'm not sure about searching performance and confusions at run time. 3. We could work with a config file. I think this requires either the implementation of option 2 or an additional install file for docking information per installable option. Then the config file is the real data entry point for the driver. It has to hold an entry for the master unit plus a more or less infinite number of optional units. All listed units are active. Deactivated units have to be removed from the config file. Adding an installable option would mean searching for an XML file, where the first entry is "Docking Information" (so called docking files), and then read whether the current master unit is listed in the list. Then add it to the XML file, where the first entry is "Configuration Information" (so called config files). This would not require any file naming conventions. I must admit that version 3 is my favovite. I will write some primitive sample docking and config files for demonstration later today and send them around. Any other proposal? What is your favorite? In all versions we agree that the description of the optional unit is based on the same set of dtd files as the master unit. Typically the master unit is the biggest description. That gives us the chance for all times to add an installable option with any feature. Unsolved challenges 1. I am concerned about the UI representation of it. In many drivers this part is shown on a config tab. In case a driver shows any optional unit as a separate check box, no problem. In case a driver shows all optional unit in a multiselect list box, no problem. Anything else gets difficult. We haven't created something like categories for installable options (input options, output options, etc.). The danger with categories is to anticipate the future. Do all options fit into the categories? Will there be additional categories in future? Free for discussion. 2. Constraints is a heavy duty. There are two questions. First is how to solve the problem that certain units cannot be attached the same time? Second is how to specify feature constraints (duplex may not work for all trays) with installable options in mind, which are yet unknown. Anyhow I think it is important to know about limitations, even if we don't solve them all. Ok, now it's up to you to think about it. As in many cases I develop some basic ideas and ask for improvement and polishing. I'm always trying to keep a concept as open as possible for future extensions. Regards Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010228/d5b8c439/attachment-0001.html From norbertschade at oaktech.com Wed Feb 28 17:10:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> installable options, part 2 Message-ID: <002701c0a1d3$42ea32f0$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Docking Info HP Duplexing Unit.xml Type: text/xml Size: 400 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInfoHPDuplexingUnit-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Configuration HP LaserJet 8150.xml Type: text/xml Size: 410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFConfigurationHPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Description HP LaserJet 8150.xml Type: text/xml Size: 18745 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDescriptionHPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Docking Info HP 2000 Sheet Input Tray.xml Type: text/xml Size: 338 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInfoHP2000SheetInputTray-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences HP LaserJet 8150.xml Type: text/xml Size: 2606 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFCommandSequencesHPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale en_us HP LaserJet 8150.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFLocaleen_usHPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DockingInformation.dtd Type: application/octet-stream Size: 387 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDockingInformation-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 388 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010228/686059b6/UPDFDeviceConfiguration-0001.obj From sommer at granitesystems.com Wed Feb 28 17:25:31 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:08 2009 Subject: UPD> installable options In-Reply-To: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010228172353.00966a40@mailbox.bellatlantic.net> Norbert, What is you reason for not specifying the options in the master description file? If you have to make a configuration file then why don't you just put the information in the master file and eliminate the configuration file? Jim From norbertschade at oaktech.com Wed Feb 28 18:41:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> installable options References: <4.2.0.58.20010228172353.00966a40@mailbox.bellatlantic.net> Message-ID: <004b01c0a1e0$03c25eb0$500714ac@NSCHADEW1> Jim, thought about it some time before. If you'd add options with all their stuff into the master description, I am convinced that we only get that running for options known at the time of the master description editing. There is no chance to add/remove options later, which is the idea (especially for third parties). At least if you'd add some later, you'll have to do some serious merging of information at many different places. I consider this missing extensibility a lack of the GPD concept. Adding the configuration stuff to the master description is a fair request. We will talk it over in the meeting. There was no other reason for me than not touching a finished description after having shipped it. And I would have to add/remove references to options later. No other reason. One may have the same thinking about the docking info. I'm open in that area as well. Norbert ----- Original Message ----- From: "Jim Sommer" To: "UPD group" Sent: Wednesday, February 28, 2001 5:25 PM Subject: Re: UPD> installable options > Norbert, > > What is you reason for not specifying the options in the master description > file? If you have to make a configuration file then why don't you just put > the information in the master file and eliminate the configuration file? > > Jim > > > From norbertschade at oaktech.com Thu Mar 1 14:26:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> UPDF fonts Message-ID: <000c01c0a285$758403f0$500714ac@NSCHADEW1> I'm taking the time to review font handling in preparation to the conference. Some time ago we already agreed on a number of tasks to be done in a second step after the first definition of the font structure. Targets of this phase: 1. Move command sequences from the font handling dtd to the command sequence dtd. 2. Edit field names to have more MS Windows independent naming conventions. 3. Get a better understanding, which fields are more font technology specific and which are more device implementation specific. 4. Think about an as easy as possible job for font companies to create font descriptions. 5. Create two sample fonts. Courier and Arial with characters from 0020 to 007E and from 00A0 to 00FF only. As in many cases I am willing to do the initial work, but would appreciate some help when settling it down. Who is willing to help me some time tomorrow considering my results as it could be done in this short time? Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010301/afdf1bc2/attachment-0001.html From hastings at cp10.es.xerox.com Mon Mar 5 00:58:13 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> PWG Media Size Standardized Names ISSUE: media type of "envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE85049977BE@x-crt-es-ms1.cp10.es.xerox.com> For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From kugler at us.ibm.com Mon Mar 5 11:20:10 2001 From: kugler at us.ibm.com (Carl Kugler) Date: Wed May 6 14:05:08 2009 Subject: UPD> Re: [Lpr-discuss] Re: PPD file for Epson Stylus Color 600 and GPr Message-ID: Some discussion about UPD-like topics is occuring on lpr-discuss. ---------------------- Forwarded by Carl Kugler/Boulder/IBM on 03/05/2001 09:16 AM --------------------------- Robert L Krawitz @lists.sourceforge.net on 03/02/2001 06:36:38 PM Sent by: lpr-discuss-admin@lists.sourceforge.net To: thubbell@compumetric.com cc: mpruett@valinux.com, lpr-discuss@lists.sourceforge.net Subject: Re: [Lpr-discuss] Re: PPD file for Epson Stylus Color 600 and GPr Date: Fri, 02 Mar 2001 11:57:55 -0600 From: Thomas Hubbell Mark Pruett wrote: > > It looks like gpr is segfaulting when it attempts to return from > the fill_option_menus() routine. This usually indicates that > some statement within fill_option_menus() has trashed the > stack (and the function's return address). I'm trying to discover > exactly where this is happening now. I figured out what the problem is. I've actually seen this before, to tell you the truth. The problem is that gpr has a static array for the number of menu items in the Paper size menu. It's set at 45, but the ppd has 52 or so entries for page size. I doubt that the printer actually supports this many paper sizes "officially", but the gs/stp driver may have other capabilities. Epson printers are quite happy to take any size you give it, as long as it's within bounds. We went and scrounged just about everything we could find, and wound up with over 100 defined sizes. So, a quick fix to increase the array size will solve this problem. But, I wonder when we'll encounter another printer that supports 75 media sizes! Any of the large format printers probably do. Now, the foomatic PPDs may work perfectly well, but they may not necessarily be what you (or HP) want. It seems to me that these PPDs all contain UIOptions that conform directly to what the gs driver supports. Therefore, they will contain a variety of "esoteric" entries that some users may not know how to handle (Floyd-Steinberg dithering, for example). HP may prefer to create a PPD that has entries that are much closer to the windows drivers (i.e., "Best", "Normal", and "Draft" versus "1,200 x 1,200 dpi", "600 x 600 dpi", "300 x 300 dpi"). The PPD structure would allow you to combine several of the driver options into one setpagedevice command, creating something equivalent to a "Normal" mode, for instance. In this case, vendor-supplied PPDs would probably be desirable, as they (or one of their contractors) could best determine what constitutes these various modes. Again, like I said earlier -- be careful. A vendor supplied PPD with a vendor supplied driver is fine, but generally you want the PPD to match up with what whoever wrote the driver intended. That said, stp has a huge variety of options, and that's only going to get more so over time, but a lot of these options will be really obscure and only intended for people who really want to experiment -- Robert Krawitz http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton _______________________________________________ Lpr-discuss mailing list Lpr-discuss@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/lpr-discuss From hastings at cp10.es.xerox.com Mon Mar 5 13:18:35 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE85049977E1@x-crt-es-ms1.cp10.es.xerox.com> Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From imcdonald at sharplabs.com Mon Mar 5 13:34:07 2001 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ED09D@mailsrvnt02.enet.sharplabs.com> Hi Tom et al, Yes, we should use ABNF to specify what's rapidly becoming a complicated syntax. I'm neutral on your alternatives for allowing or removing media-type in the syntax. Cheers, - Ira McDonald -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 10:19 AM To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From don at lexmark.com Mon Mar 5 17:36:19 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <200103052237.RAA08382@interlock2.lexmark.com> All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 5 18:18:52 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE8504997838@x-crt-es-ms1.cp10.es.xerox.com> Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 5 19:03:26 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> Editorial comments on the "PWG Media Size Standardized Names" Dra ft D0.3 Message-ID: <918C79AB552BD211A2BD00805F15CE8504997841@x-crt-es-ms1.cp10.es.xerox.com> Ron, Great job at producing this draft! Its very readable and short. A number of us reviewed it at Xerox and we like the table organization as well (but see separate comment about '-envelope' and MediaType exception which I won't repeat in these editorial comments). Here are some editorial comments. They probably don't need to be covered at the meeting, unless some reviewer wants to being up something in particular (or disagree with my suggestions). 1. It would help to produce a line numbered .pdf version for ease of making comments. 2. Do you want to down load the .doc file too. Then the meeting could make changes if they wanted to. I created a /media-sizes sub-directory under /pwg. 3. First line of Abstract is: This document specifies standard names to be used to indicate media sizes in other PWG standards. The next sentences say that this PWG standard will be used by other standards as well, such as the Printer MIB, IPP, IPP FAX, UPnP, and wireless standards. Therefore, replace "other PWG standards" with "other standards". 4. Since many of these other standards are already published, they cannot contain references to this PWG Standard. Therefore, it would also help to identify the attributes in these other standards in which these Media Size names are intended to be used, such as: Printer MIB (RFC 1759) and Printer MIB v2, Appendix B, Media Size Names ... IPP/1.1 Model and Semantics (RFC 2911), "media" Job Template attribute The standards that are still under development can contain a reference to this PWG standard in their definitions, such as: UPnP BasicPrint Template, MediaSize parameter UPnP EnhancedLayoutPrint Template, MediaSize parameter 5. Page 4, section 1, Introduction: We should also reference existing practice as specified in the PPD and GPD specifications. 6. Page 5, section 2, Terminology: The current definition of ASCII is: ASCII American Standards Code for Information Exchange. A character set encoding with printable characters defined in the range 0x21 to 0x7E. Normally refers to a US character set, but variants are defined for many national languages. Equivalent to ISO 8859-1 character set encoding. The term ASCII should always and only mean the ANS X3.4-1988 standard, same as in all IETF standards. ASCII does NOT mean the national character sets and does not mean ISO 8859-1. In an 8-bit environment, the 8th bit MUST be 0 for ASCII. I suggest using the definition from the IPP References section: [ASCII] Coded Character Set - 7-bit American Standard Code for Information Interchange (ASCII), ANSI X3.4-1986. This standard is the specification of the US-ASCII charset. 7. Page 5, section 2, Terminology: I suggest adding the term Media Size Self Describing Name. Then add a shorter form, say, Media Size Name, so we can distinguish these names from Media Name and Media Type Name. Perhaps even add these latter two terms as well. 8. Then consistently use first letter capitalization for terms to clearly indicate that they are intended to be the specialized terms in the Terminology section. 9. Page 5, section 3, need to explain the "Alias (common) names" column. 10. Page 5, section 3.1, 1st paragraph reads: This new format has the media size embedded within the string and allows a device to operate without a media name to media size table. I find it clearer to use the terms "dimension" to mean something that has a number, rather than the vaguer word "size", since this document uses size to be a name. The above paragraph with the above editorial suggestions would read: This new format has the media dimensions embedded within the string and allows a device to operate without a media size name to media dimensions table. 11. Page 5, section 3.1, we need to use ABNF. We also need to limit the characters in this standard to a much smaller subset of ASCII: Only lower case a-z, 10 decimal digits, ".", "-", and maybe "_". This is the set allowed in IPP keywords. Of course we need to be clear that the other standards that use this standard may also require all lower case, allow upper and lower case (as being equivalent), or require all upper case. Here is a crack at the ABNF: media_size_name = [na-] name "." short_dim "-" long_dim name = lowalpha *( lowalpha | digit | "-" | "_" ) short_dim = *digit long_dim = *digit lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" I specifically chose "short" and "long", not "width" and "length" so that there is absolutely no connation of orientation in the two numeric fields. I also chose "name", since I wanted to use the shorter Media Size Name for the whole thing, not just the component before the ".". This ABNF will then remove the need to describe the syntax in words, i.e., delete the following sentences: The prefix string shall be separated from the mediaName by a hyphen (0x2D). The mediaName can consist of multiple words, with each word separated by a hyphen (0x2D). The mediaName shall contain only US-ASCII characters using the codes 0x21 through 0x2D and 0x2F through 0x7E. A period (0x2E) must not be present in the mediaName. The widthDim is separated from the lengthDim by a hyphen (0x2D). No decimal values (i.e. periods) shall be present within a media size dimension. Symbol characters (0x21 through 0x2F, 0x3A through 0x3F, 0x5B through 0x5F, and 0x7B through 0x7E) are not prohibited, with the exception of the period (0x2E), but are not encouraged. 12. Section 3.1.4 General, the following sentence needs clarification: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. While Media Size Self Describing Names are presented using all lower case in this standard, other standards that use these names, MAY: a. also require only lower case as in this standard b. allow lower and upper case to be used with the same meaning as the names in this standard, i.e., case insensistive matching c. require all upper case letters to be used with the same meaning as the names in this standard 13. Section 3.2 Custom Media Size Name Format Using the ABNF, sections 3.2.1 through 3.2.4 can be compressed into the following single line of ABNF: media_size_name = [na-] "custom-" name "." short_dim "-" long_dim 14. Tables. A number of us reviewed the document at Xerox and we liked the organization and ordering of the entries in the tables (by increasing size of the smaller dimension) and the grouping of entries separated by blank lines (when there was another logical group. But this ordering should be explained. 15. Section 4 Conformance: I suggest that any standard referencing this standard needs to specify whether the names MUST be all lower case, may be mixed case with the same meaning, or MUST be all upper case. We also need a URL so they can publish the reference to this standard. 16. Section 5 IANA Considerations ISSUE 1 IANA has a registry of media names. We need to say something about whether or not we are using it to publish our names and why. 17. Internationalization Considerations ISSUE 2 Wow. If we allow any other charsets for custom names, which does seem reasonable, then we have to modify the ABNF for custom names. Yes, we should be modern and mention UTF-8. Unfortunately, if we were to allow any charset, such as national use charsets or EBCDIC, our ABNF becomes incredibly hairy. Also there would have to be a way to convey the charset in what ever protocol was being use, so we'd have to add that requirement on the standard that was referencing out standard. I'm not sure we want to go there. Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Tue Mar 6 18:07:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F259@x-crt-es-ms1.cp10.es.xerox.com> Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From imcdonald at sharplabs.com Tue Mar 6 20:37:09 2001 From: imcdonald at sharplabs.com (McDonald, Ira) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: IPP> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ED0A4@mailsrvnt02.enet.sharplabs.com> Hi Ron and Tom, Excellent! I agree with all of your conclusions below. Cheers, - Ira McDonald, consulting architect at Sharp and Xerox High North Inc -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: IPP> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From norbertschade at oaktech.com Thu Mar 8 18:37:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" References: <918C79AB552BD211A2BD00805F15CE8504C5F259@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <00b801c0a828$b16e06b0$500714ac@NSCHADEW1> >From the point of view of UPDF the consens described below is the way to go. 1. Keep the media type out of the Media size standard. Remove duplicates. We don't have problems with using 'monarch' and '10x13' in the size names. 'monarch' is a useful and familiar word for a specific size. 2. We would appreciate another small standard for media types. As we are already implementing the Media size standard into UPDF, we are in need for some type ID anyhow in the corresponding structure for media types. I'm not a color expert, but in case ICC profiles have a list of predefined media type names, that's worth considering as a source as well. 3. We are not in need for a media name, as proposed in Tom's notes. A media can have a number of attributes including size and type. In our system we need an unique ID for any media, but that is up to the editing developer. He/she may use Tom's way to create an ID or simply use a number or a more simple string. The eventual UI string will be different anyhow. Regards Norbert Schade ----- Original Message ----- From: "Hastings, Tom N" To: "ipp (E-mail)" Cc: "pwg (E-mail)" ; "UPDF WG (E-mail)" Sent: Tuesday, March 06, 2001 6:07 PM Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" > Ron and I had a phone discussion and have come up with the following simple > suggestions for this issue about envelope media type in the PWG Media Size > standard: > > 1. We agreed that most sizes are not intended for envelopes, some are > intended for envelopes, and some are intended for both stationery and > envelopes. > > 2. The Media Size standard should not mention media types at all. So the > exception about envelope media type in section 1.1 Scope will be removed. > We suggest that a separate short PWG standard for Media Types would be good, > that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production > Printing standards can cite for their Media Type attribute values. > > 3. The '-envelope' will be removed from all Media Size Names in the > standard, and any resulting duplicate names will be eliminated. The > envelope tables will be merged with the other tables. As has been done for > postcards, the Alias (common name) column will have "(envelope)" in > parenthesis added in order to indicate that the size is intended for > envelopes. We didn't discuss how to distinguish between the sizes, such as > na-monarch, that are intended only for envelopes and those, such as > na-10x13, which are intended for envelopes and other media types. Thoughts? > > Comments? > > Thanks, > Tom > > P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as > well. > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Monday, March 05, 2001 15:19 > To: don@lexmark.com > Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media > type of " envelope" > > > Don, > > I agree with you NOT re-order any Media Self Describing Media Name (Media > Size Name for short) from the order that is in the D0.3 draft. > > What I was talking about is, if we want to also add Media Type names to the > standard as a separate concept (also needed by UPnP and the Printer MIB), we > could do that. Then we could also define an additional syntax for Media > Names (used by IPP "media" attribute) which puts the Media Type Name in > front of the Media Size Name (same order). These Media Type Names would NOT > be enumerated in combination with all the possible sizes, but would just be > a format. Please see the rest of the attached mail message that talks about > the problem of the current draft that mixes Media Type and Media Size Name, > but only for envelope Media Types. > > Tom > > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Monday, March 05, 2001 14:36 > To: Hastings, Tom N > Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of > " envelope" > > > > > All: > > I am opposed to ANY reordering of the self describing name. > > prefix - medianame . widthDim - lengthDIM is the right format. > > ********************************************** > * Don Wright don@lexmark.com * > * Chair, Printer Working Group * > * Chair, IEEE MSC * > * * > * Director, Strategic & Technical Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 859-232-4808 (phone) 859-232-6740 (fax) * > ********************************************** > > > > > > "Hastings, Tom N" on > 03/05/2001 01:18:35 PM > > To: "pwg (E-mail)" , "ipp (E-mail)" > , "UPDF WG (E-mail)" > > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " > envelope" > > > > Just to be clear, neither alternatives (a) or (b) that I suggested in the > original mail change the current D0.3 syntax for the Media Size Self > Describing Name format which is (using the notation in the D0.3 version): > > prefix - mediaName . widthDim - lengthDim > > Alternative (b) would add a syntax for Media Names which includes the Media > Type Name followed by the Media Size Self Describing Name. I also change > the suggestion for the Media Name syntax slightly to put the 'na-' as part > of the Self Describing Media Size Name field, instead of in front of > everything, i.e.,: > > mediaTypeName . prefix - mediaName . widthDim - lengthDim > > instead of: > > prefix - mediaTypeName . mediaName . widthDim - lengthDim > > > ISSUE: Should we use real ABNF for defining the syntax? > > > Examples: > > Media Size Self Describing Name (from current draft and with either > alternative a or b): > > iso-a4.2100-2970 > iso-b4.2500-3530 > na-letter.8500-11000 > > Media Name (if alternative b is added to the draft): > > stationery.iso-a4.2100-2970 > envelope.iso-b4-2500-3530 > stationery.na-letter.8500-11000 > transparency.na-letter.8500-11000 > > Tom > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Sunday, March 04, 2001 21:58 > To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) > Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of > "envelope" > > > For discussion about the "PWG Media Size Draft standard", D0.3, on the > mailing list and the UPDF and IPP WG meetings, Monday, March 5, and > Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the > upcoming meetings. Someone take good notes, since neither Ron nor I will be > able to attend. > > Summary of issue: > > Problem: > The current draft contains sizes that are independent of media type, except > for envelopes. For each of the envelope sizes the draft includes two names, > one without '-envelope' and one with '-envelope' with the same dimensions > and says that the names with '-envelope' also imply a media type of > envelope. > > Possible Solutions: > Either: > > a. "Media Size Standardized Names" - current title > The standard should be completely independent of media type but indicate > that the size names do NOT imply media type. However, the standard should > include all sizes, even those that are primarily suited for a single media > type, such as envelopes, as well as sizes for any other media types, such as > stationery, labels, business cards, postcards, etc. > > b. "Media Size, Media Type, and Media Standardized Names" > Same as (a), but add (1) Media Type Names to the standard as a separate part > and (2) a way to combine Media Type Names and Media Size Names into Media > Names using '.' as a field separator. > > We have at least six other standards that will use the results of this PWG > standard. Here is how these other standards would use alternatives (a) and > (b): > > Media Size Media Type Media > Name Name Name > (a and b) (b) (b) > Printer MIB: > prtInputMediaName (App C) x > prtInputMediaType x > Appendix B x > > IPP: > "media" attribute x could x > > PWG IEEE/ISTO 5100.3: > "media-type" in "media-col" x > > IPP FAX: > "media" attribute x > > UPnP: > MediaType parameter x > MediaSize parameter x > > Wireless: > hopefully the same as UPnP > > > > Detailed Discussion: > The D0.3 Draft has the following paragraph in the Scope section > > 1.1 Scope > This document defines media sizes only. Other media attributes such as > color, type, or weight are not included. One exception is the inclusion of > the media type of 'envelope.' Since many envelope sizes are unique and > envelopes have very special physical characteristics which requires special > handling and printing formats, this attribute is included with the size. > > > I suggest that having this exception for envelopes will cause confusion. > The control of media type should be independent wherever Media Size Names > are used. For example, I might want to specify a stationery media type that > is any envelope size in order to proof my envelope printing. Also I might > want to specify an envelope media to be a stationery media size. > > For protocols in which the Media Type and Media Size are independent, such > as the Printer MIB and UPnP, having this exception for envelope sizes will > cause problems. Which takes precedence, if say, the Media Type is > 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? > > For protocols where the same attribute can take on Media Names and Media > Size Names, such as IPP, having Size Names that are the same as Media Names > will be ambiguous. > > In IPP, the "media" Job Template attribute takes three different kinds of > keyword names (in the following order in Appendix C): > > Media Names: > 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm > 'iso-b4-envelope': Specifies the ISO B4 envelope medium > > Input Tray Names: > 'top': The top input tray in the printer. > > Media Size Names: > 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in > ISO 216 > > This issue does point out a bug in IPP Appendix C names for the North > American keywords (but isn't for ISO and JIS names). The same keywords > appear twice with different meanings: > > Media Names: > 'na-10x13-envelope': Specifies the North American 10x13 envelope > medium > 'monarch-envelope': Specifies the Monarch envelope > 'na-number-10-envelope': Specifies the North American number 10 > business envelope medium > > Media Size Names: > 'na-10x13-envelope': Specifies the North American 10x13 size: 10 > inches by 13 inches > 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 > in) > 'na-number-10-envelope': Specifies the North American number 10 > business envelope size: 4.125 inches by 9.5 inches > > The bug is that both the Media Names and the Media Size Names have the > '-envelope' component in them, meaning that they are duplicate names. The > '-envelope' should be removed from the IPP North American Media Size Name > keywords in order to eliminate the duplicate keywords that mean different > things. The ones with '-envelope' mean an envelope medium, the ones without > '-envelope' mean just the size. How the media type is determined depends on > the IPP implementation (and possibly other attributes such as the > "media-type" member attribute of the "media-col" Job Template attribute (see > PWG Production Printing standard, for example: IETF-ISTO 5100.3 available > at: > ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). > > > Back to the PWG Media Size Name standard D0.3: > There is some duplication of semantics (if we agree NOT to include the > envelope media type semantics and stick to size names only) between: > > Table 3.3 North American Standard Sheet Media Sizes AND > Table 3.4 North American Standard Envelope Media Sizes > > and complete duplication of the ISO b and c series between: > Table 3.5 ISO Standard Sheet Media Sizes AND > Table 3.6 ISO Standard Envelope Media Sizes > > where the only difference in the Self Describing Name is whether or not > there is an '-envelope' component. > > So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. > For those entries in Table 3.4 and Table 3.6 that don't have any > corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, > either removing the '-envelope' or change it to 'envelope-size'. For > example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to > either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', > depending on which the group thinks is clearer. Same for > 'na-number-11-envelope.4500-10375', etc. > > I don't know about the Japanese and Chinese envelope sizes. > > > > Alternative (b) (add Media Type Names and Media Names) > > Alternative (b) needs all the same changes as alternative (a). In addition > we would add a list of Media Type Names. Lets start with the names from the > Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing > which includes some Media Type Names needed by UPnP: > > stationery > transparency > envelope > envelope-plain > envelope-window > continuous > continuous-long > continuous-short > tab-stock > pre-cut-tabs > full-cut-tabs > multi-part-form > labels > multi-layer > screen > screen-paged > photographic > cardstock > other > > The syntax for Media Names could be: > > [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim > > Media Names wouldn't need to be added as additional tables or table entries > in the standard, but just a rule for generation from the MediaTypeName and > the MediaSizeName values. > > Comments? > > Thanks, > Tom > > > > -----Original Message----- > From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] > Sent: Wednesday, February 28, 2001 11:50 > To: ipp (E-mail); pwg (E-mail) > Subject: PWG> FW: Update to Media Sizes Document (version D0.3) > > > I've created a sub-directory for the PWG media-sizes project and copied D0.3 > version into it: > > ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf > > I've also copied the versions of Jim Lo's original document in .doc, .pdf, > and .html: > > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc > ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf > > Also two RFCs the deal with media from the Internet Fax group: > > RFC 2879 - Content Feature Schema for Internet Fax (V2) > RFC 2534 - Media Features for Display, Print, and Fax > > ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt > ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt > > Tom > > -----Original Message----- > From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] > Sent: Friday, February 23, 2001 07:53 > To: IMAGING@FORUM.UPNP.ORG > Subject: Update to Media Sizes Document (version D0.3) > > > I did not receive any comments on the D0.2 version, so this update only > includes the missing paragraphs plus some corrections i discovered. > > I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. > Since I am not able to attend these meetings, someone needs to take good > notes. > > Ron Bergman > Hitachi Koki Imaging Solutions > <> > > > > > > From lfarrell at cissc.canon.com Fri Mar 9 21:19:52 2001 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:05:08 2009 Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Message-ID: <6C940F5153E5D211937A0090274E8D8B01E411BA@cissc.cisoc.canon.com> Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Mon Mar 12 19:09:27 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F4C9@x-crt-es-ms1.cp10.es.xerox.com> Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From wayde.gardner at intelligraphics.com Tue Mar 13 12:15:34 2001 From: wayde.gardner at intelligraphics.com (Wayde Gardner) Date: Wed May 6 14:05:08 2009 Subject: UPD> Bluetooth technology Message-ID: <001f01c0abe1$37322b80$940211ac@intelligraphics.com> We would be happy to contribute where possible. http://www.intelligraphics.com/wireless_bluetooth.html Wayde Gardner Digital Imaging Technologies Intelligraphics, Inc. http://www.intelligraphics.com mailto:waydeg@intelligraphics.com Phone: 972-479-1770 x110 Fax: 972-479-1760 -------------- next part -------------- A non-text attachment was scrubbed... Name: Wayde Gardner.vcf Type: text/x-vcard Size: 442 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010313/22027bfa/WaydeGardner-0001.vcf From don at lexmark.com Fri Mar 16 12:47:06 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:08 2009 Subject: UPD> Re: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Message-ID: <200103161756.MAA10986@interlock2.lexmark.com> Tom, et al: The opinion expressed at the IPP meeting in Tampa was that the MEDIA SIZES and MEDIA TYPES should be in the same document if the "-envelope" was removed from the self-describing media names in the current MEDIA SIZES document. We believed that it was important for applications that use one standard (i.e. Media Sizes) MUST also use the Media Types. By making them one standard with a conformance statement requiring usage of both we would insure conforming applications to be able to distinguish fully all sizes and types. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/12/2001 07:09:27 PM To: "pwg (E-mail)" cc: "ipp (E-mail)" , "UPDF WG (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From hastings at cp10.es.xerox.com Thu Mar 22 03:24:09 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:08 2009 Subject: UPD> MED - Media Standardized Names Draft D0.4 down-loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5F8AF@x-crt-es-ms1.cp10.es.xerox.com> So Ron and I have agreed to add the Media Type Names to the Media Size Name standard, if that was the consensus at the meeting. We need to work on the conformance language some more. Since the Printer MIB and the PWG Production Printing "media-color" member attribute also use Media Color Names, we added them too. ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04-rev.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04-rev.pdf ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-04.pdf Ron and I haven't merged the envelope size names with the other size names with the clarification that the size names do not imply media type. That is flagged as an issue in each of the envelope tables. Ron also has some more sizes to add. Here is the Abstract: This document specifies standard names to be used to indicate media types, media colors, and media sizes in other standards. These lists of names are a superset of the names that are currently presented in the Printer MIB [RFC1759] and the IPP Model and Semantics [RFC2911] documents. It is intended to supplement the currently defined lists as well as to provide a normative reference for all subsequent standards. This document is a draft of an IEEE-ISTO PWG Proposed Standard and is in full conformance with all provisions of the PWG Process (see http://www.pwg.org/chair/pwg-process-990825.pdf). PWG Proposed Standards are working documents of the IEEE-ISTO PWG and its working groups. The list of current PWG projects and drafts can be obtained at http://www.pwg.org. I've also sent this to the UPnP Imaging WG who originally requested the PWG to write such a standard that could be used by other print protocols. They have a telecon, Thursday, March 22. Please send comments to the above DLs. Ron and I will collaborate on updating the document. Thanks, Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Friday, March 16, 2001 09:47 To: Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail) Subject: Re: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Tom, et al: The opinion expressed at the IPP meeting in Tampa was that the MEDIA SIZES and MEDIA TYPES should be in the same document if the "-envelope" was removed from the self-describing media names in the current MEDIA SIZES document. We believed that it was important for applications that use one standard (i.e. Media Sizes) MUST also use the Media Types. By making them one standard with a conformance statement requiring usage of both we would insure conforming applications to be able to distinguish fully all sizes and types. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/12/2001 07:09:27 PM To: "pwg (E-mail)" cc: "ipp (E-mail)" , "UPDF WG (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - OK if the PWG Media Type and Media Size standards are separ ate PWG standards? Ron and I discussed whether the Media Types should be a separate section in the same document as the Media Sizes, or put in a separate document. We both feel that keeping it a separate document will be simpler and more modular. We think that the Media Types are less likely to have additions, than are Media sizes. However, either may undergo changes as some other group needs additions to one or the other. It will be easier for those interested in only one of these standards to keep track of changes of it, if they are separate. The basis of the agreement on the mailing list seems to be that Media Type and Media Size are independent concepts. The best way to keep them independent is to keep them as separate standards. Whether some other protocol wishes to combine the two into a single attribute is the province of that other protocol standard, and not of either of the Media Type standard or the Media Size standard. Also it will be much simpler for other standards to refer to either the Media Type standard or the Media Size standard as needed. So are there any strong objections to making the Media Size standard and the Media Type standard as two separate standards? (The current Media Size standard would remove the current discussion about the envelope Media Type in the definitions and would remove the '-envelope' in the names. However, for those sizes that were originally defined for a certain type what that type is, such as the C series is for envelopes and some of the B series is for both stationery and envelopes, some sizes are for postcards, etc.) The Media Type standard would be similar to the Media Size standard but with the Media Type names, alias, and common names listed. When we are further along in the drafts, we'll assign them the next two 5100.n values, say 5100.5 and 5100.6, in the IEEE-ISTO PWG series. Editors of the Media Type and Media Size standards, Tom and Ron -----Original Message----- From: Farrell, Lee [mailto:lfarrell@cissc.canon.com] Sent: Friday, March 09, 2001 18:20 To: 'Hastings, Tom N'; ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: RE: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Tom, At the IPP meeting on Wednesday, this topic was discussed. However, we got stuck when trying to evaluate your proposal based on the original goal(s) of the Standardized Names document. Don mentioned that an exhaustive list of possible names was necessary for UPnP. I vaguely recall the need [or was it just a side benefit?] to be able to parse the Self Describing Name to automatically generate a "common" or "legacy" name for presentation to the user. Were these intended goals of the document? Are there others? In principle, no one at the meeting had any strong objections to your suggestion. Generally, people like the clean separation of type from size. We just weren't sure if it created problems with regard to the intended goal(s). During the discussion, it was even suggested that if the group agrees to remove the "-envelope" and a separate list of media types is created, this list should also be included in the same document. lee -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, March 06, 2001 3:07 PM To: ipp (E-mail) Cc: pwg (E-mail); UPDF WG (E-mail) Subject: UPD> RE: PWG> PWG Media Size Standardized Names ISSUE: media type of " envelope" Ron and I had a phone discussion and have come up with the following simple suggestions for this issue about envelope media type in the PWG Media Size standard: 1. We agreed that most sizes are not intended for envelopes, some are intended for envelopes, and some are intended for both stationery and envelopes. 2. The Media Size standard should not mention media types at all. So the exception about envelope media type in section 1.1 Scope will be removed. We suggest that a separate short PWG standard for Media Types would be good, that the Printer MIB, UPnP Printing, and IEEE-ISTO PWG 5100.3 Production Printing standards can cite for their Media Type attribute values. 3. The '-envelope' will be removed from all Media Size Names in the standard, and any resulting duplicate names will be eliminated. The envelope tables will be merged with the other tables. As has been done for postcards, the Alias (common name) column will have "(envelope)" in parenthesis added in order to indicate that the size is intended for envelopes. We didn't discuss how to distinguish between the sizes, such as na-monarch, that are intended only for envelopes and those, such as na-10x13, which are intended for envelopes and other media types. Thoughts? Comments? Thanks, Tom P.S. Ron can't send to the PWG DLs, so I'll copy this thread to them as well. -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, March 05, 2001 15:19 To: don@lexmark.com Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: UPD> RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Don, I agree with you NOT re-order any Media Self Describing Media Name (Media Size Name for short) from the order that is in the D0.3 draft. What I was talking about is, if we want to also add Media Type names to the standard as a separate concept (also needed by UPnP and the Printer MIB), we could do that. Then we could also define an additional syntax for Media Names (used by IPP "media" attribute) which puts the Media Type Name in front of the Media Size Name (same order). These Media Type Names would NOT be enumerated in combination with all the possible sizes, but would just be a format. Please see the rest of the attached mail message that talks about the problem of the current draft that mixes Media Type and Media Size Name, but only for envelope Media Types. Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Monday, March 05, 2001 14:36 To: Hastings, Tom N Cc: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" All: I am opposed to ANY reordering of the self describing name. prefix - medianame . widthDim - lengthDIM is the right format. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Hastings, Tom N" on 03/05/2001 01:18:35 PM To: "pwg (E-mail)" , "ipp (E-mail)" , "UPDF WG (E-mail)" cc: (bcc: Don Wright/Lex/Lexmark) Subject: RE: IPP> PWG Media Size Standardized Names ISSUE: media type of " envelope" Just to be clear, neither alternatives (a) or (b) that I suggested in the original mail change the current D0.3 syntax for the Media Size Self Describing Name format which is (using the notation in the D0.3 version): prefix - mediaName . widthDim - lengthDim Alternative (b) would add a syntax for Media Names which includes the Media Type Name followed by the Media Size Self Describing Name. I also change the suggestion for the Media Name syntax slightly to put the 'na-' as part of the Self Describing Media Size Name field, instead of in front of everything, i.e.,: mediaTypeName . prefix - mediaName . widthDim - lengthDim instead of: prefix - mediaTypeName . mediaName . widthDim - lengthDim ISSUE: Should we use real ABNF for defining the syntax? Examples: Media Size Self Describing Name (from current draft and with either alternative a or b): iso-a4.2100-2970 iso-b4.2500-3530 na-letter.8500-11000 Media Name (if alternative b is added to the draft): stationery.iso-a4.2100-2970 envelope.iso-b4-2500-3530 stationery.na-letter.8500-11000 transparency.na-letter.8500-11000 Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Sunday, March 04, 2001 21:58 To: pwg (E-mail); ipp (E-mail); UPDF WG (E-mail) Subject: IPP> PWG Media Size Standardized Names ISSUE: media type of "envelope" For discussion about the "PWG Media Size Draft standard", D0.3, on the mailing list and the UPDF and IPP WG meetings, Monday, March 5, and Wednesday-Thursday, March 7-8. Please discuss this fundamental issue at the upcoming meetings. Someone take good notes, since neither Ron nor I will be able to attend. Summary of issue: Problem: The current draft contains sizes that are independent of media type, except for envelopes. For each of the envelope sizes the draft includes two names, one without '-envelope' and one with '-envelope' with the same dimensions and says that the names with '-envelope' also imply a media type of envelope. Possible Solutions: Either: a. "Media Size Standardized Names" - current title The standard should be completely independent of media type but indicate that the size names do NOT imply media type. However, the standard should include all sizes, even those that are primarily suited for a single media type, such as envelopes, as well as sizes for any other media types, such as stationery, labels, business cards, postcards, etc. b. "Media Size, Media Type, and Media Standardized Names" Same as (a), but add (1) Media Type Names to the standard as a separate part and (2) a way to combine Media Type Names and Media Size Names into Media Names using '.' as a field separator. We have at least six other standards that will use the results of this PWG standard. Here is how these other standards would use alternatives (a) and (b): Media Size Media Type Media Name Name Name (a and b) (b) (b) Printer MIB: prtInputMediaName (App C) x prtInputMediaType x Appendix B x IPP: "media" attribute x could x PWG IEEE/ISTO 5100.3: "media-type" in "media-col" x IPP FAX: "media" attribute x UPnP: MediaType parameter x MediaSize parameter x Wireless: hopefully the same as UPnP Detailed Discussion: The D0.3 Draft has the following paragraph in the Scope section 1.1 Scope This document defines media sizes only. Other media attributes such as color, type, or weight are not included. One exception is the inclusion of the media type of 'envelope.' Since many envelope sizes are unique and envelopes have very special physical characteristics which requires special handling and printing formats, this attribute is included with the size. I suggest that having this exception for envelopes will cause confusion. The control of media type should be independent wherever Media Size Names are used. For example, I might want to specify a stationery media type that is any envelope size in order to proof my envelope printing. Also I might want to specify an envelope media to be a stationery media size. For protocols in which the Media Type and Media Size are independent, such as the Printer MIB and UPnP, having this exception for envelope sizes will cause problems. Which takes precedence, if say, the Media Type is 'stationery' but the Media Size Name is, say 'iso-b4-envelope.2500-3530'? For protocols where the same attribute can take on Media Names and Media Size Names, such as IPP, having Size Names that are the same as Media Names will be ambiguous. In IPP, the "media" Job Template attribute takes three different kinds of keyword names (in the following order in Appendix C): Media Names: 'iso-b4-white': Specifies the ISO B4 white medium: 250 mm x 353 mm 'iso-b4-envelope': Specifies the ISO B4 envelope medium Input Tray Names: 'top': The top input tray in the printer. Media Size Names: 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in ISO 216 This issue does point out a bug in IPP Appendix C names for the North American keywords (but isn't for ISO and JIS names). The same keywords appear twice with different meanings: Media Names: 'na-10x13-envelope': Specifies the North American 10x13 envelope medium 'monarch-envelope': Specifies the Monarch envelope 'na-number-10-envelope': Specifies the North American number 10 business envelope medium Media Size Names: 'na-10x13-envelope': Specifies the North American 10x13 size: 10 inches by 13 inches 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 in) 'na-number-10-envelope': Specifies the North American number 10 business envelope size: 4.125 inches by 9.5 inches The bug is that both the Media Names and the Media Size Names have the '-envelope' component in them, meaning that they are duplicate names. The '-envelope' should be removed from the IPP North American Media Size Name keywords in order to eliminate the duplicate keywords that mean different things. The ones with '-envelope' mean an envelope medium, the ones without '-envelope' mean just the size. How the media type is determined depends on the IPP implementation (and possibly other attributes such as the "media-type" member attribute of the "media-col" Job Template attribute (see PWG Production Printing standard, for example: IETF-ISTO 5100.3 available at: ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf). Back to the PWG Media Size Name standard D0.3: There is some duplication of semantics (if we agree NOT to include the envelope media type semantics and stick to size names only) between: Table 3.3 North American Standard Sheet Media Sizes AND Table 3.4 North American Standard Envelope Media Sizes and complete duplication of the ISO b and c series between: Table 3.5 ISO Standard Sheet Media Sizes AND Table 3.6 ISO Standard Envelope Media Sizes where the only difference in the Self Describing Name is whether or not there is an '-envelope' component. So whether we choose Alternative (a) or (b), delete Table 3.4 and Table 3.6. For those entries in Table 3.4 and Table 3.6 that don't have any corresponding size in Table 3.3 or Table 3.5, move the name to 3.3 or 3.5, either removing the '-envelope' or change it to 'envelope-size'. For example, move 'na-personal-envelope.3625-6500' to 3.3 and change its name to either 'na-personal.3625-6500' or 'na-personal-envelope-size.3624-6500', depending on which the group thinks is clearer. Same for 'na-number-11-envelope.4500-10375', etc. I don't know about the Japanese and Chinese envelope sizes. Alternative (b) (add Media Type Names and Media Names) Alternative (b) needs all the same changes as alternative (a). In addition we would add a list of Media Type Names. Lets start with the names from the Printer MIB, Internet FAX, and IEEE-ISTO 5100.3 PWG Production Printing which includes some Media Type Names needed by UPnP: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock other The syntax for Media Names could be: [na-]MediaTypeName.MediaSizeName.WidthDim-LengthDim Media Names wouldn't need to be added as additional tables or table entries in the standard, but just a rule for generation from the MediaTypeName and the MediaSizeName values. Comments? Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, February 28, 2001 11:50 To: ipp (E-mail); pwg (E-mail) Subject: PWG> FW: Update to Media Sizes Document (version D0.3) I've created a sub-directory for the PWG media-sizes project and copied D0.3 version into it: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-size-03.pdf I've also copied the versions of Jim Lo's original document in .doc, .pdf, and .html: ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.html ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/papersizes-ipp-gpd-ppd.pdf Also two RFCs the deal with media from the Internet Fax group: RFC 2879 - Content Feature Schema for Internet Fax (V2) RFC 2534 - Media Features for Display, Print, and Fax ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2879.txt ftp://ftp.pwg.org/pub/pwg/media-sizes/rfc2534.txt Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@HITACHI-HKIS.COM] Sent: Friday, February 23, 2001 07:53 To: IMAGING@FORUM.UPNP.ORG Subject: Update to Media Sizes Document (version D0.3) I did not receive any comments on the D0.2 version, so this update only includes the missing paragraphs plus some corrections i discovered. I hope this can be reviewed in the UDPF and/or the IPP meetings in Tampa. Since I am not able to attend these meetings, someone needs to take good notes. Ron Bergman Hitachi Koki Imaging Solutions <> From norbertschade at oaktech.com Thu Mar 22 11:42:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> custom media Message-ID: <003e01c0b2ef$27edfd10$500714ac@NSCHADEW1> I like the syntax for custom media sizes, which can work for proprietary (added by some IHV) sizes added to a driver before compilation as well as sizes defined by the end user working with an installed driver. Do we want to think of something similar for types and colors? I see 'Other' in the types section. But this is just one. So if I wanted to add two proprietary ones, I'd have to use the same keyword. Don't like that. Even something like 'Other-N', where 'N' is a positive integer leaves everything open. I'm sure there are better ways to do it. Same with color? Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010322/2708169f/attachment-0001.html From norbertschade at oaktech.com Thu Mar 22 16:41:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> generic features Message-ID: <003301c0b318$e8c670c0$500714ac@NSCHADEW1> We are talking for some time about limiting our specification to certain features like media handling, font handling, color, etc., but providing a generic method to add others like EconoMode, REt, etc. I call the latter group of features the generic features from now on for better identification. We said we would provide a number of fields to make the most entries and probably even prepare different structures for different groups of features (the simple On/Off features, finishing features like stapling/punching with position values, etc). I must say I suffer. I admit I suffer for quite a while already. As much as I like the idea to limit the UPDF to the most common features and have one more generic feature called 'GenericFeature', I don't trust it really. The more I think about it the more I suffer. And I have this suspicious feeling in my stomach that we oversee something. As some of you know I care alot about my stomach. Enough joking. I haven't solved all issues around the generic features so far. Either we solve it or they will go or we'll buy some weaknesses. 1. Bidirectional communication When it comes to bidi, the driver must detect the meaning of a certain incoming feature to make the connection to a driver setting. We haven't talked about bidi too much so far, but even if we leave it out in the first level of UPDF, I want us to anticipate enough functionality that we will not have to change a previous spec when adding new functionality in future. I have certain expectations of bidi. I do not expect bidi to tell me everything a driver may have or likes to know about a certain feature. It is enough when bidi is telling me what of the information the driver has already (either compiled or as UPDF) is to be activated. As a consequence this may activate a whole group of other information not having been passed in. And that's ok. So it comes to keywords and settings. Settings can be different things: values, ranges, structures and may be more. The point when talking about generic features is that the driver must be able to anticipate, which keywords and settings the bidi routine will pass in. Sample: it must know that the bidi keyword is EconoMode and not EMode. It must know that the setting is a toggle and not one within a range of values. If we do not care about this anticipation, we let the whole API between a driver and a communication routine open. That would mean we forget about a common API to a communication routine and leave that open to everybody's proprietary solution - which is a legitimate way to go. But I am still dreaming there will be one common IPP communication routine and one common PJL (or whatever) communication routine. That would mean every UPDF would have to anticipate the same keywords and settings. So if we find a solution for the bidi problem, I feel it must include a spec for predefined keywords and a description how settings can come in. Then a driver can understand incoming parameters. 2. Constraints I think this is even more serious. Imagine we generic features and somebody implements two instances of them: EconoMode and REt. The element name in the dtd would be GenericFeature in both cases. Literally it is not GenericFeature1 and GenericFeature2. That's the point. The element names are not unique. How would somebody specify a constraint that EconoMode=On cannot go with REt=On (forget about the nonsense of the statement)? This constraint issue is going wild in my stomach. This is definitely a showstopper! Please help me out. Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010322/0df2e837/attachment-0001.html From RonBergman at aol.com Thu Mar 22 17:44:47 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:08 2009 Subject: Fwd: RE: UPD> custom media Message-ID: <21.929a61a.27ebda5f@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> custom media Date: Thu, 22 Mar 2001 13:40:30 -0800 Size: 6327 Url: http://www.pwg.org/archives/upd/attachments/20010322/769dbac3/attachment-0001.mht From mike at easysw.com Fri Mar 23 08:48:53 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:08 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5F8AF@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3ABB5445.A1905FED@easysw.com> "Hastings, Tom N" wrote: > > So Ron and I have agreed to add the Media Type Names to the Media > Size Name standard, if that was the consensus at the meeting. We > need to work on the conformance language some more. > ... OK, some general comments: 1. For the media type names, is "continuous" considered to be the same as "roll"? I ask only because roll paper does not have the perforations that continuous forms have. I suggest adding a "roll" media type or ammending the description for "continuous" to include roll type media with no perforations. 2. The current media types don't address variations of particular media types; these variations are generally the "finish" of the media (glossy, matte, etc.), so I would recommend adding standard "media finish" values that can be used to identify an exact media type, rather than overloading the current media types with additional name-finish varients. 3. There is presently no way to define the min & max custom media size; this is absolutely required for this to work in the real world (otherwise how do you know what media sizes are valid?), e.g.: "custom-size-minimum." short-dim "-" long-dim "custom-size-maximum." short-dim "-" long-dim This would essentially research the "size-minimum" and "size-maximum" names, but allow a device to communicate that any size from the minimum to the maximum dimensions is supported. If these sizes are not available then the client should only select media sizes from the provided list. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Fri Mar 23 10:54:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> coating and other attributes of media Message-ID: <004401c0b3b1$94d82370$500714ac@NSCHADEW1> I second Michael Sweet's request for a "finish" (or whatever the name will be) attribute. In UPDF we have to have some solution for that anyhow. See below my view from a driver's point of view. Why is a driver/client interested in getting information about media types from the device? 1.. Simply showing it in the client's user interface for further selection. This would not require any different functionality of the client. It would mainly be marketing information that the device is able to feed a number of print media. 2.. Temperature related issues. In this case it is useful to know, which is the current media type. This requires a different print file to be sent. In the simpliest case this requires just one additional job command. 3.. Constraints The print file (not only the job settings, but the binary part) has to be seriously changed depending on the current media type. There are two areas: 3.1. Mechanical issues This can affect driver functionality at page start/end. Means sending different or additional command sequences at page start/end or even staying away from printing in certain areas e.g. at the top of the page (media type specific minimum or at least recommended margins). A special case of this issue can be to stay away from certain areas, as the media is prepared a certain way like preprinted or prepunched. It could also have tray related constraints. Certain media types may not be fed from some trays, as they need a straight paper path. Other constraints like transparency -> no duplex is another issue. 3.2. Color conversion including grey scale. When the color conversion is done in the device, e.g. you have an sRGB device, it is enough for the client to send a simple job setting like in issue 2. If the device is not capable of doing that the client may want to do the conversion itself, which means serious changes in the binary section of the print file. Sometimes device objects (fonts, rectangles and other graphical objects, etc.) are handled by the device, while raster graphics are handled by the driver. This typically is surface or finish related. Sometimes this attribute is called coating. Unfortunately it is reality that all these media type attributes are thrown into one list, more or less big and often very model and PDL specific. My private golden rule so far is, that I become suspicious, when a media seems to be two media types the same time, e.g. glossy and prepunched. To serve reality my proposal for the UPDF is that we keep one list of media types in our description. We will use the keywords of the global media standard (Ron's spec), but add at least one more attribute to each media type, called Coating. This coating seems to be the attribute a Windows 2000 devmode is interested in - more than the rather physical attributes of Ron's spec, which have more to do with the overall shape (outside the size) or stiffiness of the media. So even if two media would have the same spec keyword, we'd have a chance to differenciate between them. I wonder whether other attributes like Pre-handled (prepunched, preprinted, etc.) or opacity would be of further help. Glad we have color now. I do not see the need for other attributes. An indication whether there are enough attributes with enough variations in Ron's spec might be: Do we expect that most of the media types we know today playing a role in the game of printing are covered? Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010323/45cb4b6a/attachment-0001.html From mike at easysw.com Fri Mar 23 10:59:02 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:08 2009 Subject: UPD> [Fwd: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded] Message-ID: <3ABB72C6.30A00945@easysw.com> -------- Original Message -------- Subject: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded Date: Fri, 23 Mar 2001 09:41:57 -0500 From: Mike Bartman To: "'Michael Sweet'" I'm just curious...why are you folks trying to name every possibility for media type that might ever have existed, or will exist? Why not just do it like DOCUMENT_FORMAT and make it an arbitrary string to be defined elsewhere, if at all? That would seem to be simplest, most flexible and even easier to implement. Why add complexity that will only limit future utility? I mean, have you included "billboard" as a media type? I know of at least one "printer" that can print billboard-sized sheets all at once...I think Fujitsu makes it. What about "bedsheet"? We have iron-on T-shirt media now (is that defined for IPP? Which size?) and someday there might be someone who makes a printer to do the same for bedsheets too. Businness card forms exist today, as do greeting cards, brochures (bi- and tri-fold) and a number of other media types, in a host of "weights", colors, textures and rag contents. There probably is, or will be, a printer server that can handle all of them from one device or media source or another...are you going to try to name them all explicitly?? Why? Maybe that got discussed when I wasn't looking, but it sure seems confusing now! :^) -- Mike > -----Original Message----- > From: Michael Sweet [mailto:mike@easysw.com] > Sent: Friday, March 23, 2001 8:49 AM > To: Hastings, Tom N > Cc: ipp (E-mail); UPDF WG (E-mail) > Subject: Re: IPP> MED - Media Standardized Names Draft D0.4 > down-loaded > > > "Hastings, Tom N" wrote: > > > > So Ron and I have agreed to add the Media Type Names to the Media > > Size Name standard, if that was the consensus at the meeting. We > > need to work on the conformance language some more. > > ... > > OK, some general comments: > > 1. For the media type names, is "continuous" considered to be > the same as "roll"? I ask only because roll paper does not > have the perforations that continuous forms have. > > I suggest adding a "roll" media type or ammending the > description for "continuous" to include roll type media > with no perforations. > > 2. The current media types don't address variations of particular > media types; these variations are generally the "finish" of > the media (glossy, matte, etc.), so I would recommend adding > standard "media finish" values that can be used to identify > an exact media type, rather than overloading the current > media types with additional name-finish varients. > > 3. There is presently no way to define the min & max custom > media size; this is absolutely required for this to work > in the real world (otherwise how do you know what media > sizes are valid?), e.g.: > > "custom-size-minimum." short-dim "-" long-dim > "custom-size-maximum." short-dim "-" long-dim > > This would essentially research the "size-minimum" and > "size-maximum" names, but allow a device to communicate > that any size from the minimum to the maximum dimensions > is supported. If these sizes are not available then the > client should only select media sizes from the provided > list. > > -- > ______________________________________________________________________ > Michael Sweet, Easy Software Products mike@easysw.com > Printing Software for UNIX http://www.easysw.com > From norbertschade at oaktech.com Fri Mar 23 11:15:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:08 2009 Subject: UPD> more attributes for media Message-ID: <001001c0b3b4$8ba622e0$500714ac@NSCHADEW1> One more comment: I do not in every case require that a new media attribute like Coating goes with a list of predefined keywords. In some cases it may just be fine to agree on certain attributes that drivers/client deal with the same kind of structures, so they have a similar approach to understanding a number of communication protocols, etc. API's would be similar. An attribute Coating can as well go with a specification for custom coating as the only 'predefined' keyword, just following the general approach just in this spec. Perhaps we want to add the most common keywords in case of coating as well. For other attributes a custom keyword can be sufficient and leaves the spec open to any future extension. Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010323/0d408f15/attachment-0001.html From norbertschade at oaktech.com Fri Mar 23 15:08:24 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> UPDF meeting notes from Tampa Message-ID: <003001c0b3d5$041a6ae0$500714ac@NSCHADEW1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 145 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010323/d298ff7a/attachment-0001.gif From mike at easysw.com Mon Mar 26 10:20:34 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> [Fwd: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded] Message-ID: <3ABF5E42.158B0EDB@easysw.com> -------- Original Message -------- Subject: RE: IPP> MED - Media Standardized Names Draft D0.4 down-loaded Date: Fri, 23 Mar 2001 12:18:22 -0500 From: Mike Bartman To: "'Michael Sweet'" > From: Michael Sweet [mailto:mike@easysw.com] > Mike Bartman wrote: > > > > I'm just curious...why are you folks trying to name every > > possibility for media type that might ever have existed, or will > > exist? Why not just do it like DOCUMENT_FORMAT and make it an > > arbitrary string to be defined elsewhere, if at all? That would > > seem to be simplest, most flexible and even easier to implement. > > Why add complexity that will only limit future utility? > > I think the main issue is that *standard* media types need to be > enumerated (by keyword value) so that you don't end up with 50 > different names for "plain paper"... :) Ok, I can see that. With document-format isn't the deal that you can use any mime-media type, defined by RFC, or an arbitrary string? That would get you the base level of standardization that everyone could count on (assuming that there's an equivalent for media formats like there was for document data formats), without limiting proprietary extensions that may be necessary in some cases. I'm not sure that just having a single "custom" value is good enough...I'd like to be able to reference my own media type by a name that makes sense to me, not by "custom" with a definition each time. "bonus stickers" might be a value I want to use for media type...and it might make sense to my programmable printer, where it's equal to "bin 1" or "make operator request with that name" or something. If there was a "media-types-supported" value in the get-printer-attributes reply, I could even present such a thing to a user for them to select if they want to. > Without a standard naming convention (whether all the valid values > are defined or not) there can be no interoperability between > systems and devices. The goal is to allow a single piece of > software/hardware to communicate with any presentation device > without having to be hardcoded/wired for each device. No problem with that as a base, I just wouldn't like to see it stop there. I want to be able to extend the media type names that are available, either because the printer knows them, or because it can be told what to call things that it knows about (alias naming?) to more closely match user expectations for various forms of media (Purchase Order Forms, Billboards, etc.). The client doesn't have to have things hardcoded...they can be configuration settings, or acquired from the printer through query. My client will accept anything the user cares to enter for most items, and only overrules when there's a printer attribute that the client has received that says it isn't going to work (i.e. user asks for 1000 copies on a printer with a valid copies range of 1:99). I don't want to waste your time on this if all this has been handled. Just trying to offer a suggestion in case it wasn't already ruled out for some reason. Like I said, I haven't followed the entire discussion on this one. I've been implementing my IPP client... (now in beta test! :^) Thanks for reading. If it's useful, feel free to pass it on, if it's not, then just ignore me. :^) -- Mike Bartman From norbertschade at oaktech.com Mon Mar 26 12:17:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF Message-ID: <000c01c0b618$95964ee0$500714ac@NSCHADEW1> We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010326/25e5a077/attachment-0001.html From sommer at granitesystems.com Mon Mar 26 22:00:58 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF In-Reply-To: <000c01c0b618$95964ee0$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010326220023.00954320@mailbox.bellatlantic.net> I vote for one PDL per UPDF. Jim At 3/26/01 12:17 PM, Norbert Schade wrote: >We never finally decided whether we will allow exactly one PDL per UPDF >description or more. >I put that on vote. >Please send your vote this week. >We will decide on Friday, March 30th, late afternoon. > >My personal vote is one PDL only. >Reasons: >Don't move more information around than you need. >Editing of XML files is easier, when there are parrallel files (master >description, command sequences, locales, etc.) instead of editing >different sections in very different areas of one huge file. >Development is possible in steps done by different groups, while one huge >description probably never gets done. > >Regards >Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010326/15d51f08/attachment-0001.html From don at lexmark.com Tue Mar 27 08:12:43 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF Message-ID: <200103271313.IAA20417@interlock2.lexmark.com> As much as I'd like one all encompassing UPDF, I think having only one PDL per UPDF is the only practical solution. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Norbert Schade" on 03/26/2001 12:17:06 PM To: "UPD group" cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> PDL per UPDF We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010327/f18a0445/att1-0001.htm From harryl at us.ibm.com Tue Mar 27 09:29:48 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF Message-ID: One PDL per UPDF. While UPDF may seem to be lagging in development and adoption, I still think it is a powerful idea. I'm afraid the complexity of simultaneously addressing multiple PDLs might keep things from ever getting off the ground. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Norbert Schade" Sent by: owner-upd@pwg.org 03/26/2001 10:17 AM To: "UPD group" cc: Subject: UPD> PDL per UPDF We never finally decided whether we will allow exactly one PDL per UPDF description or more. I put that on vote. Please send your vote this week. We will decide on Friday, March 30th, late afternoon. My personal vote is one PDL only. Reasons: Don't move more information around than you need. Editing of XML files is easier, when there are parrallel files (master description, command sequences, locales, etc.) instead of editing different sections in very different areas of one huge file. Development is possible in steps done by different groups, while one huge description probably never gets done. Regards Norbert Schade From sommer at granitesystems.com Tue Mar 27 10:30:59 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> Generic Features In-Reply-To: <004401c0b3b1$94d82370$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010327100751.009687e0@mailbox.bellatlantic.net> Norbert and I met yesterday to go over a few items. The one item that we spent the most time with was the "Generic Feature". If you recall, the generic feature was a way of allowing the definition of features that we couldn't possibly conceive of but that are generally controlled with either PJL, IPP or special PS at the beginning of a job. The generic feature doesn't affect how the driver generates PDL, it just generates special, device specific commands. Defining the structure for the generic feature wasn't a problem but handling them in constraints was. Norbert and I couldn't come up with a generic solution so we've had to fall back to the following: - Identify common, currently-used printer features and define these in UPDF. - Allow for a fixed number of other printer features and allot space for them in UPDF. The proposal is to allot space for 16 generic, undefined printer features. In addition, the following features will be predefined: - Output Order - Jog - Staple - Punch - Finishing - Print Density - Print Quality - Resolution Enhancement - Toner Saver - Page Protect - Jam Recovery The structure of each of the predefined features will be exactly the same as the generic features so they can really be used as desired. If anyone has any other items that they'd like to be predefined, we're open to suggestions. I think that if we have 16 predefined features in addition to 16 generic features then that should be more than adequate. Comment? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010327/a132caba/attachment-0001.html From mike at easysw.com Tue Mar 27 12:41:40 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE56@triton.hitachi-hkis.com> Message-ID: <3AC0D0D4.7D566C36@easysw.com> "Bergman, Ron" wrote: > ... > 1. Roll paper was purposely omitted from the document. Refer to > the second paragraph of section 1.1, Scope. This decision was > made for two reasons; 1) it adds another level of complexity to > the document and 2) there appears to be very little interest by > PWG participants in roll feed devices. That's a shame, since roll feed devices are extremely popular and would benefit from some "standard" support. I'm not sure what additional complexity you see, aside from describing the min and max size of the media. Adding a "roll" media type will at least allow the media to be accurately specified - cutter control, etc. can be left to other attributes in other places. > 2. Since we have already "bit the bullet" and added Media Type > and Color, finish is a likely next step. Since my time is > currently limited and knowledge of this subject is minimal, > a volunteer is needed to provide the necessary input. So, > when can you have a draft? ;-) :) I'll be out of the office for the next couple weeks, so unless you can wait that long don't expect anything from me... > 3. Maximum and minimum values define a characteristic of the > printer and I believe this is way beyond the scope of this > document. The Printer MIB currently provides an excellent > source for this information. That may be true, but that doesn't help IPP clients... If the printer MIB defines attribute names, maybe we can mirror them here so that they will be used in other protocols with the same names and ranges? -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From markv at us.ibm.com Tue Mar 27 20:51:05 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF Message-ID: >At 3/26/01 12:17 PM, Norbert Schade wrote: >We never finally decided whether we will allow exactly one PDL per UPDF description or more. Yes, I am listening and I vote 1 PDL per updf. Reason: Varying capabilities between PDL personalities such as fonts, resolutions, printable area, ... would cause too much confusion. Additional comments: Having a separate command file will give some flexibility. Additional concerns: Some previsions must be made for PDLs which contain multiple modes or commands to do the same thing. For example, PCL5 (a single PDL has an HPGL/2 mode). Or are you saying PCL5 not using HPGL/2 is one PDL and PCL5 in HPGL/2 MODE is another. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Wed Mar 28 11:15:13 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> PDL per UPDF References: Message-ID: <002301c0b7a2$4505b200$500714ac@NSCHADEW1> I think we got to support different 'RenderingMode' like Raster and GL. E.g. fonts have to be accessible in both modes, but they have different command sequences. We have to check, where this element belongs in our description. I guess it's on a quite high level. The support of GL is one major reason, why I wanted to provide support for 'IF'-statements in command sequences. See Parameter converter documentation. This may become clearer now. So we can support two or more modes in one command sequence. that is definitely not possible in any other device description. Norbert Schade ----- Original Message ----- From: "Mark VanderWiele" To: Sent: Tuesday, March 27, 2001 8:51 PM Subject: Re: UPD> PDL per UPDF > >At 3/26/01 12:17 PM, Norbert Schade wrote: > >We never finally decided whether we will allow exactly one PDL per UPDF > description or more. > > Yes, I am listening and I vote 1 PDL per updf. > > Reason: Varying capabilities between PDL personalities such as fonts, > resolutions, printable area, ... would cause too much confusion. > > Additional comments: Having a separate command file will give some > flexibility. > > Additional concerns: Some previsions must be made for PDLs which contain > multiple modes or commands to do the same thing. For example, PCL5 (a > single PDL has an HPGL/2 mode). Or are you saying PCL5 not using HPGL/2 is > one PDL and PCL5 in HPGL/2 MODE is another. > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678-4779 > MARKV@IBMUS > email: markv@us.ibm.com > > From norbertschade at oaktech.com Wed Mar 28 13:16:03 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales Message-ID: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> If you look into the 'UPDF Entities.dtd', you see an entity defined for locales. It's a quite short list implemented by Mike Young about two years ago. I'd like to finish that section in the near future. So I am asking for a proper concept we can use in our open standard. Requirements: It has to be complete, which means it should support all major human languages. It must provide two components, where the first is the default language like English and the second is the dialect. This allows required fallback routines. Right now we have a more verbal system with an uncomplete list. Before we finish that I ask for feedback from experts. Even if you connect me to some people, who are supposed to be the experts, it'd be fine. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010328/008f41a2/attachment-0001.html From sommer at granitesystems.com Wed Mar 28 14:26:11 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales In-Reply-To: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> You can get language codes from http://www.unicode.org/unicode/onlinedat/languages.html. It has a table showing the language name, the 2 character ISO-639 code, the Windows code number, the Mac name, and the Mac code number. You can get country codes from http://www.unicode.org/unicode/onlinedat/countries.html. It has a table showing the country name, the 2 and 3 character ISO-3166 codes, the Windows code number, the Mac name, and the Mac code number. Of course it's hard to know which languages are spoken in which countries. You could just allow a locale to consist of any language code with any country code. If you want to limit the list, I got the following list of language - country pairs from the Microsoft help: Arabic - Saudi Arabia Arabic - Iraq Arabic - Egypt Arabic - Libya Arabic - Algeria Arabic - Morocco Arabic - Tunisia Arabic - Oman Arabic - Yemen Arabic - Syria Arabic - Jordan Arabic - Lebanon Arabic - Kuwait Arabic - U.A.E. Arabic - Bahrain Arabic - Qatar Bulgarian - Bulgaria Catalan - Spain Chinese - Taiwan Chinese - PRC Chinese - Hong Kong Chinese - Singapore Chinese - Macau Czech - Czech Republic Danish - Denmark German - Germany German - Switzerland German - Austria German - Luxembourg German - Liechtenstein Greek - Greece English - United States English - United Kingdom English - Australia English - Canada English - New Zealand English - Ireland English - South Africa English - Jamaica English - Caribbean English - Belize English - Trinidad English - Zimbabwe English - Philippines Spanish - Spain Spanish - Mexico Spanish - Spain (International Sort) Spanish - Guatemala Spanish - Costa Rica Spanish - Panama Spanish - Dominican Republic Spanish - Venezuela Spanish - Colombia Spanish - Peru Spanish - Argentina Spanish - Ecuador Spanish - Chile Spanish - Uruguay Spanish - Paraguay Spanish - Bolivia Spanish - El Salvador Spanish - Honduras Spanish - Nicaragua Spanish - Puerto Rico Finnish - Finland French - France French - Belgium French - Canada French - Switzerland French - Luxembourg French - Monaco Hebrew - Israel Hungarian - Hungary Icelandic - Iceland Italian - Italy Italian - Switzerland Japanese - Japan Korean - Korea Dutch - Netherlands Dutch - Belgium Norwegian - Norway (Bokmal) Norwegian - Norway (Nynorsk) Polish - Poland Portuguese - Brazil Portuguese - Portugal Romanian - Romania Russian - Russia Croatian - Croatia Serbian - Serbia (Latin) Serbian - Serbia (Cyrillic) Slovak - Slovakia Albanian - Albania Swedish - Sweden Swedish - Finland Thai - Thailand Turkish - Turkey Urdu - Pakistan Indonesian - Indonesia Ukrainian - Ukraine Belarusian - Belarus Slovene - Slovenia Estonian - Estonia Latvian - Latvia Lithuanian - Lithuania Classic Lithuanian - Lithuania Farsi - Iran Vietnamese - Viet Nam Armenian - Armenia Azeri - Azerbaijan (Latin) Azeri - Azerbaijan (Cyrillic) Basque - Spain FYRO Macedonian - Former Yugoslav Republic of Macedonia Afrikaans - South Africa Georgian - Georgia Faeroese - Faeroe Islands Hindi - India Malay - Malaysia Malay - Brunei Darussalam Kazak - Kazakstan Swahili - Kenya Uzbek - Uzbekistan (Latin) Uzbek - Uzbekistan (Cyrillic) Tatar - Tatarstan Bengali - India Punjabi - India Gujarati - India Oriya - India Tamil - India Telugu - India Kannada - India Malayalam - India Assamese - India Marathi - India Sanskrit - India Konkani - India Jim From sommer at granitesystems.com Wed Mar 28 14:40:46 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales In-Reply-To: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> References: <001b01c0b7b3$269a0170$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010328143038.00955bb0@mailbox.bellatlantic.net> Another table of Windows language - country pairs can be found at http://msdn.microsoft.com/library/psdk/winbase/nls_8xo3.htm Jim From norbertschade at oaktech.com Wed Mar 28 15:44:39 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales References: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> Message-ID: <005a01c0b7c7$e8cfc7c0$500714ac@NSCHADEW1> Ok, with these ones we can be sure that we are on the safe side. I'd rather stay away from the Microsoft list. This kind of conversion would be up to the Windows driver. Looks that we go with the ISO code for the language and the ISO Code2 for the country right now. Do we want to stick with it? If yes, we'd want to have an entity for locales to be used as the parameter in Locale_ID in our locale files. These entries should look like 'Arabic - Saudi Arabia - arSA'. The first two components make it easy for the human reader to select the proper entry. The third component of the keyword is the ISO abbreviation. Our locale files have three components: a predefined identifyer "UPDF Locale", a second component and the IHV component like "HP LaserJet" (supposed to be used with all HP LaserJets in this sample). I do not think the second component should be the first two components of the language/country keyword. This could result in an unbelievable long file name. So I'd appreciate to use the ISO abbreviation instead. A developer editing locale files could easily detect the abbreviation from the third component of the Locale_ID list. this would always be a four character entry. Has even advantages when sorting. This would keep us almost identical with our entity list. We'd eliminate the underscore and extend the list. Would be a significant step in our file naming convention. I'd appreciate some short statements before we make it a rule. Hope to confirm that tomorrow as well as the PDL per UPDF description. Regards Norbert Schade BTW: Assuming we will not get serious complaints about the above option who can quickly assemble the three-component list as described??? Let's say somewhere next week when confirmed tomorrow? ----- Original Message ----- From: "Jim Sommer" To: "Norbert Schade" ; "UPD group" Sent: Wednesday, March 28, 2001 2:26 PM Subject: Re: UPD> open standard for locales > You can get language codes from > http://www.unicode.org/unicode/onlinedat/languages.html. It has a table > showing the language name, the 2 character ISO-639 code, the Windows code > number, the Mac name, and the Mac code number. > > You can get country codes from > http://www.unicode.org/unicode/onlinedat/countries.html. It has a table > showing the country name, the 2 and 3 character ISO-3166 codes, the Windows > code number, the Mac name, and the Mac code number. > > Of course it's hard to know which languages are spoken in which countries. > You could just allow a locale to consist of any language code with any > country code. If you want to limit the list, I got the following list of > language - country pairs from the Microsoft help: > > Arabic - Saudi Arabia > Arabic - Iraq > Arabic - Egypt > Arabic - Libya > Arabic - Algeria > Arabic - Morocco > Arabic - Tunisia > Arabic - Oman > Arabic - Yemen > Arabic - Syria > Arabic - Jordan > Arabic - Lebanon > Arabic - Kuwait > Arabic - U.A.E. > Arabic - Bahrain > Arabic - Qatar > Bulgarian - Bulgaria > Catalan - Spain > Chinese - Taiwan > Chinese - PRC > Chinese - Hong Kong > Chinese - Singapore > Chinese - Macau > Czech - Czech Republic > Danish - Denmark > German - Germany > German - Switzerland > German - Austria > German - Luxembourg > German - Liechtenstein > Greek - Greece > English - United States > English - United Kingdom > English - Australia > English - Canada > English - New Zealand > English - Ireland > English - South Africa > English - Jamaica > English - Caribbean > English - Belize > English - Trinidad > English - Zimbabwe > English - Philippines > Spanish - Spain > Spanish - Mexico > Spanish - Spain (International Sort) > Spanish - Guatemala > Spanish - Costa Rica > Spanish - Panama > Spanish - Dominican Republic > Spanish - Venezuela > Spanish - Colombia > Spanish - Peru > Spanish - Argentina > Spanish - Ecuador > Spanish - Chile > Spanish - Uruguay > Spanish - Paraguay > Spanish - Bolivia > Spanish - El Salvador > Spanish - Honduras > Spanish - Nicaragua > Spanish - Puerto Rico > Finnish - Finland > French - France > French - Belgium > French - Canada > French - Switzerland > French - Luxembourg > French - Monaco > Hebrew - Israel > Hungarian - Hungary > Icelandic - Iceland > Italian - Italy > Italian - Switzerland > Japanese - Japan > Korean - Korea > Dutch - Netherlands > Dutch - Belgium > Norwegian - Norway (Bokmal) > Norwegian - Norway (Nynorsk) > Polish - Poland > Portuguese - Brazil > Portuguese - Portugal > Romanian - Romania > Russian - Russia > Croatian - Croatia > Serbian - Serbia (Latin) > Serbian - Serbia (Cyrillic) > Slovak - Slovakia > Albanian - Albania > Swedish - Sweden > Swedish - Finland > Thai - Thailand > Turkish - Turkey > Urdu - Pakistan > Indonesian - Indonesia > Ukrainian - Ukraine > Belarusian - Belarus > Slovene - Slovenia > Estonian - Estonia > Latvian - Latvia > Lithuanian - Lithuania > Classic Lithuanian - Lithuania > Farsi - Iran > Vietnamese - Viet Nam > Armenian - Armenia > Azeri - Azerbaijan (Latin) > Azeri - Azerbaijan (Cyrillic) > Basque - Spain > FYRO Macedonian - Former Yugoslav Republic of Macedonia > Afrikaans - South Africa > Georgian - Georgia > Faeroese - Faeroe Islands > Hindi - India > Malay - Malaysia > Malay - Brunei Darussalam > Kazak - Kazakstan > Swahili - Kenya > Uzbek - Uzbekistan (Latin) > Uzbek - Uzbekistan (Cyrillic) > Tatar - Tatarstan > Bengali - India > Punjabi - India > Gujarati - India > Oriya - India > Tamil - India > Telugu - India > Kannada - India > Malayalam - India > Assamese - India > Marathi - India > Sanskrit - India > Konkani - India > > > Jim > > From RonBergman at aol.com Wed Mar 28 21:17:17 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: Fwd: FW: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <8f.8ddbfb9.27f3f52d@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Wed, 28 Mar 2001 18:17:38 -0800 Size: 1896 Url: http://www.pwg.org/archives/upd/attachments/20010328/3c742e05/attachment-0001.mht From hastings at cp10.es.xerox.com Wed Mar 28 21:50:57 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FB2C@x-crt-es-ms1.cp10.es.xerox.com> In response to Michael's three suggestions: 1. Request to add roll media as a media type. I agree with Ron's answer. The current definition of the 'continuous' types indicates that it consists of sheets (of a predetermined size) connected together, while roll media requires cutting. Here are the definitions from the Media standard: continuous Continuously connected sheets of an opaque material - which edge is connected is not specified continuous-long Continuously connected sheets of an opaque material connected along the long edge continuous-short Continuously connected sheets of an opaque material connected along the short edge So I think we should not introduce the notion of roll media and stick with roll media being out of scope. 2. Request to add media finish, here is what the PWG IEEE-ISTO Production Printing standard, 5100.3 has for "media-front-coating" and "media-back-coating" (not media finish, but I think they are the same thing): 3.13.10 media-front-coating (type3 keyword | name(MAX)) and media-back-coating (type3 keyword | name(MAX)) The "media-front-coating" and "media-back-coating" member attributes indicate what pre-process coating has been applied to the front and back of the desired media, respectively. Standard keyword values for "media-front-coating" and "media-back-coating" are: 'none' Indicated that the media MUST not have any coating. 'glossy' Indicates that the media MUST have a "glossy" coating. 'high-gloss' Indicates that the media MUST have a "high-gloss" coating. 'semi-gloss' Indicates that the media MUST have a "semi-gloss" coating. 'satin' Indicates that the media MUST have a "satin" coating. 'matte' Indicates that the media MUST have a "matte" coating. The "media-front-coating-supported" (1setOf (type3 keyword | name(MAX))) and "media-back-coating-supported" (1setOf (type3 keyword | name(MAX))) Printer attribute identifies the values of these "media-front-coating" and "media-back-coating" member attributes that the Printer supports. JDF Spirial 6 also includes the same values and as "coatings", not "finish": FrontCoatings ? Enumeration-Span What pre-process coating has been applied to the front surface of the media. Possible values are: None: the default. Glossy HighGloss Matte Satin Semigloss So I would not oppose adding MediaCoating to the Media standard, what do others think? 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim Such an addition would be necessary, if the UPnP Printer template is to reference our PWG standard for its MediaType and MediaSize syntaxes and standardized values, instead of defining its own syntax. So I'd be in favor of adding the minimum and maximum syntax for use with custom media sizes. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, March 27, 2001 08:36 To: 'Michael Sweet'; Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Michael, In response to your comments: 1. Roll paper was purposely omitted from the document. Refer to the second paragraph of section 1.1, Scope. This decision was made for two reasons; 1) it adds another level of complexity to the document and 2) there appears to be very little interest by PWG participants in roll feed devices. 2. Since we have already "bit the bullet" and added Media Type and Color, finish is a likely next step. Since my time is currently limited and knowledge of this subject is minimal, a volunteer is needed to provide the necessary input. So, when can you have a draft? ;-) 3. Maximum and minimum values define a characteristic of the printer and I believe this is way beyond the scope of this document. The Printer MIB currently provides an excellent source for this information. Ron Bergman Hitachi Koki Imaging Solutions -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Friday, March 23, 2001 5:49 AM To: Hastings, Tom N Cc: ipp (E-mail); UPDF WG (E-mail) Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Hastings, Tom N" wrote: > > So Ron and I have agreed to add the Media Type Names to the Media > Size Name standard, if that was the consensus at the meeting. We > need to work on the conformance language some more. > ... OK, some general comments: 1. For the media type names, is "continuous" considered to be the same as "roll"? I ask only because roll paper does not have the perforations that continuous forms have. I suggest adding a "roll" media type or ammending the description for "continuous" to include roll type media with no perforations. 2. The current media types don't address variations of particular media types; these variations are generally the "finish" of the media (glossy, matte, etc.), so I would recommend adding standard "media finish" values that can be used to identify an exact media type, rather than overloading the current media types with additional name-finish varients. 3. There is presently no way to define the min & max custom media size; this is absolutely required for this to work in the real world (otherwise how do you know what media sizes are valid?), e.g.: "custom-size-minimum." short-dim "-" long-dim "custom-size-maximum." short-dim "-" long-dim This would essentially research the "size-minimum" and "size-maximum" names, but allow a device to communicate that any size from the minimum to the maximum dimensions is supported. If these sizes are not available then the client should only select media sizes from the provided list. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Wed Mar 28 22:20:59 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5FB2C@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AC2AA1B.58CBEDE9@easysw.com> "Hastings, Tom N" wrote: > ... > So I think we should not introduce the notion of roll media and > stick with roll media being out of scope. I personally disagree with this decision, especially since there *are* consumer inkjets today (and for the past several years, in fact) that support roll (sometimes called "banner") media of more-or-less arbitrary length. I understand that some things about roll media may be out of scope (cutting, marking, etc.), but to ignore roll media entirely will make this specification useless. I merely propose that the following media type be added to the current specification: 'roll' - A continuous roll of media whose limits are described by the custom-min and custom-max sizes. Again, it is *extremely* important that we support roll media types because they are available for many consumer inkjets as well as high-end devices. Most of these devices *do* need to know that you want to use roll fed media, and if no keyword is defined for it then you'll end up with a different name for each implementation. I agree, however, that things like cutter control and marking the page area on the media are beyond the scope of this specification, so any mention of roll media should be limited to the media type and not any of the other issues. > ... > So I would not oppose adding MediaCoating to the Media standard, > what do others think? Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? > ... > Translating the UPnP syntax to our ABNF would become: > > custom-media-size-max-self-describing-name = > [prefix] "custom-max" "." short-dim "-" long-dim > > custom-media-size-min-self-describing-name = > [prefix] "custom-min" "." short-dim "-" long-dim Yes, this will work perfectly well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From sommer at granitesystems.com Thu Mar 29 09:02:14 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales In-Reply-To: <005a01c0b7c7$e8cfc7c0$500714ac@NSCHADEW1> References: <4.2.0.58.20010328135218.00975260@mailbox.bellatlantic.net> Message-ID: <4.2.0.58.20010329085740.00956310@mailbox.bellatlantic.net> I think that using the ISO abbreviations is the best way to go. My only preference would be that the 4 character locale code be the fist component instead of the last component but it doesn't make that much of a difference. Since I already have a list started, I will volunteer to complete the list and post it soon. Jim At 3/28/01 03:44 PM, Norbert Schade wrote: >Ok, with these ones we can be sure that we are on the safe side. >I'd rather stay away from the Microsoft list. >This kind of conversion would be up to the Windows driver. >Looks that we go with the ISO code for the language and the ISO Code2 for >the country right now. Do we want to stick with it? >If yes, we'd want to have an entity for locales to be used as the parameter >in Locale_ID in our locale files. >These entries should look like 'Arabic - Saudi Arabia - arSA'. >The first two components make it easy for the human reader to select the >proper entry. >The third component of the keyword is the ISO abbreviation. >Our locale files have three components: a predefined identifyer "UPDF >Locale", a second component and the IHV component like "HP LaserJet" >(supposed to be used with all HP LaserJets in this sample). >I do not think the second component should be the first two components of >the language/country keyword. This could result in an unbelievable long file >name. So I'd appreciate to use the ISO abbreviation instead. >A developer editing locale files could easily detect the abbreviation from >the third component of the Locale_ID list. >this would always be a four character entry. Has even advantages when >sorting. > >This would keep us almost identical with our entity list. We'd eliminate the >underscore and extend the list. >Would be a significant step in our file naming convention. > >I'd appreciate some short statements before we make it a rule. Hope to >confirm that tomorrow as well as the PDL per UPDF description. > >Regards >Norbert Schade > >BTW: Assuming we will not get serious complaints about the above option who >can quickly assemble the three-component list as described??? Let's say >somewhere next week when confirmed tomorrow? From norbertschade at mediaone.net Thu Mar 29 08:21:59 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> Device configuration in UPDF Message-ID: <000201c0b86d$6cd7c540$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFCommandSequences-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Configuration.doc Type: application/octet-stream Size: 95744 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFConfiguration-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 8150.xml Type: text/xml Size: 917 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceConfiguration-HPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 18374 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 1340 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFDeviceConfiguration-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 740 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deAT-HP LaserJet.xml Type: text/xml Size: 1767 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale-deAT-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 1735 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFLocale-enUS-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Option Configuration-HP Duplexing Unit PCL5e.xml Type: text/xml Size: 758 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFOptionConfiguration-HPDuplexingUnitPCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF OptionConfiguration.dtd Type: application/octet-stream Size: 1283 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFOptionConfiguration-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2517 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010329/f47c3f11/UPDFCommandSequences-HPLaserJetPCL5e-0001.xml From RonBergman at aol.com Thu Mar 29 12:06:21 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Thu, 29 Mar 2001 08:56:53 -0800 Size: 9069 Url: http://www.pwg.org/archives/upd/attachments/20010329/d1f535ca/attachment-0001.mht From RonBergman at aol.com Thu Mar 29 12:07:26 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Thu, 29 Mar 2001 09:00:29 -0800 Size: 3888 Url: http://www.pwg.org/archives/upd/attachments/20010329/07e59575/attachment-0001.mht From mike at easysw.com Thu Mar 29 14:50:02 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6E@triton.hitachi-hkis.com> Message-ID: <3AC391EA.2E38703B@easysw.com> "Bergman, Ron" wrote: > > Michael, > > I will add your roll definition to the Media Types section. In > your first request for this addition, I envisioned a major change > to the sizes table to include roll. This definition will be > included in the next draft. > ... Thanks! -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Thu Mar 29 15:09:18 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6D@triton.hitachi-hkis.com> Message-ID: <3AC3966E.B2859926@easysw.com> "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From sommer at granitesystems.com Thu Mar 29 15:16:46 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded In-Reply-To: <3AC3966E.B2859926@easysw.com> References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE6D@triton.hitachi-hkis.com> Message-ID: <4.2.0.58.20010329151318.00971100@mailbox.bellatlantic.net> I agree with Michael, I think we should define the keywords that are used to identify the smallest and largest user-defined, custom paper sizes. These two "paper sizes" can appear in the list of supported sizes and indicate that custom sizes are supported and the range of allowable sizes. I think it fits in perfectly with what we're trying to do with this document. Jim At 3/29/01 03:09 PM, Michael Sweet wrote: >"Bergman, Ron" wrote: > > ... > > I disagee with your proposal for adding printer size restrictions > > to the document. So far this specification has only involved > > attributes related to media. Now you are proposing that we add > > an attribute that is related to printers. This belongs in the > > appropriate UPnP or IPP or other document that defines how to > > describe a printer. If we add this then it will be necessary > > ... > >I'm not sure I agree with this (or maybe I just not understanding >your objection right); the purpose of this standard/spec is to >define the names used for media sizes, types, finishes, etc. so >that other protocols can then use those names uniformly. > > From an implementation standpoint, it may be desireable to have >media size names that are reserved for representing 1) whether >custom media sizes are supported, and 2) what the size limits are >for the device being queried. This allows all protocols to use >a common method for conveying the custom media size information, >while the exact values used in the custom size names are determined >by the device and not the protocols or this spec. > >IPP contains no explicit support for custom media sizes; CUPS >works around this limitation by supporting a "custom" media size >keyword and relies on the to know that they can request a custom >media size using the name "custom.WWWxLLL", where "WWW" and "LLL" >are the width and length of the media in points (works well for >a PS-based printing system... :) This only works for CUPS, and >I have no idea what Microsoft does, for example, with their >media support under Windows 2000... > >So, I guess what I'm saying is this: > > 1. Describe "custom-min" and "custom-max" media size names > and the format they use. Specify that these names will > only be present for devices that support custom sizes, and > that both must appear if they are used at all. > > 2. Explicitly state that the values used in the custom-min/max > names are defined by the device and not the spec. > > 3. Explicitly state that the units for media sizes in the > size names are set by the media spec and not by the > protocol spec. Units outside the size name can obviously > be anything the protocol wants... > >#1 will make sure that any client can determine if a device supports >custom sizes, no matter what protocol is being used. > >#2 will remove any requirement for additional info in the media spec >on how to manage custom sizes. > >#3 will ensure that the dimensions in size names are consistent no >matter what protocol is being used. > >-- >______________________________________________________________________ >Michael Sweet, Easy Software Products mike@easysw.com >Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Thu Mar 29 15:33:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> min/max custom size values Message-ID: <001a01c0b88f$77a2dc90$500714ac@NSCHADEW1> Hmmmmmm... We are reaching dangerous areas. As much as I like to have the keywords a driver can look for to find those values, I hope that nobody is expecting this to tell anything, where the two values belong to. Explicitely: If somebody sends the current print media sizes available in the different trays to the host with a communication protocol like IPP (or another), he should not add a min/max custom size value generally. This would indicate that these two values are valid for all input trays, which normally is wrong. These are input tray specific values. I know that they can be affected by some other setting as well like a duplexer. These conditions are certainly out of scope of the global media list. So as long as we just identify the two keywords and leave it to the communication protocol (or whatever other routine wants to use it) to tell about interdependencies, fine. If we add the two keys, this must be clear in the comment. Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010329/d808fdcf/attachment-0001.html From mike at easysw.com Thu Mar 29 16:31:08 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> min/max custom size values References: <001a01c0b88f$77a2dc90$500714ac@NSCHADEW1> Message-ID: <3AC3A99C.765308BB@easysw.com> Norbert Schade wrote: > ... > This would indicate that these two values are valid for all input > trays, which normally is wrong. These are input tray specific > values. I know that they can be affected by some other setting as > well like a duplexer. These conditions are certainly out of scope > of the global media list. That is correct, but I think we can add a fourth "rule" for the spec, which will apply to *all* attributes (remember, there are plenty of printers that can't print on cardstock from particular trays, too, so it ain't just an issue for custom sizes... :) I think this will be appropriate for the "scope" section; it should mention that the media spec just defines the values, not what will be supported for a particular combination, and that the underlying protocols must handle this mess themselves (e.g. IPP uses the media collection stuff or validate-job to determine the valid combinations of values...) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From markv at us.ibm.com Fri Mar 30 10:44:11 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Fri Mar 30 12:42:00 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> min/max custom size values References: Message-ID: <002301c0b940$b9896a50$500714ac@NSCHADEW1> Mark, I know where you are coming from. But in this case I disagree with you. I think it's the job of the global media spec to provide lists of keywords for size, type, coating (if media source would be added, I'd be the first to take it over in UPDF). Any semantic level, where keywords are combined to information about a device status, is the task of a communication protocol like IPP (or even a MIB), a device description like UPDF or a driver. So I'd expect IPP to tell me that there is a media present with four attributes 'Letter,Stationary,Glossy,ManualTray' and two other media with other attribute parameters. In UPDF we want to provide a chance to declare these four attributes a unit. And the driver hopefully has some functionality to create an appropriate UI for that. This would result in the required behavior of the whole environment. The two keywords for min/max custom sizes may as well come as attributes of media sources or duplex settings or any other section within the communication protocol. It's only about relying on a certain syntax on keywords. If the communication protocol or the UPDF use it wrong in their context, then that's there fault. Regards Norbert Schade ----- Original Message ----- From: "Mark VanderWiele" To: "Norbert Schade" Cc: "UPD group" ; "IPP Group" ; "Pete Zannucci" ; "Mark_Hamzy/Austin/IBM%IBMUS" Sent: Friday, March 30, 2001 10:44 AM Subject: Re: UPD> Re: IPP> min/max custom size values > Careful, we may be making the same mistake we made in IPP where the form > size, media type, and tray are returned separately causing user interface > nightmare since all three of these really must be selected together and > represent the actual configuration of the printer. Therefore, I would > propose that when we have settled in on a syntax for the form size, media > type, and tray we go one step further and define a way to join the fields > so that the proper constraints can be represented. Perhaps a simple "+" > character. Again, form size by itself is meaningless. > > Regards, > Mark VanderWiele > IBM, Linux Tecnology Center > 512-838-4779, t/l 678-4779 > MARKV@IBMUS > email: markv@us.ibm.com > > From RonBergman at aol.com Fri Mar 30 20:58:29 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <84.138f0ddf.27f693be@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Date: Fri, 30 Mar 2001 16:53:03 -0800 Size: 4718 Url: http://www.pwg.org/archives/upd/attachments/20010330/4ef44e52/attachment-0001.mht From sommer at granitesystems.com Mon Apr 2 09:48:04 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:09 2009 Subject: UPD> open standard for locales In-Reply-To: <001201c0a1c5$0ef04330$500714ac@NSCHADEW1> Message-ID: <4.2.0.58.20010402093510.00963290@mailbox.bellatlantic.net> Here's a list of locales that use the ISO language and country codes. I know it's not all encompassing since I don't what countries speak some of the languages. However, it's a good start and people should post any missing entries. I have the list sorted by code. It's not necessarily an obvious sort for English but it's probably the best to use since nothing is going to be good for everyone. Jim -------------------------------------- code - language - country afZA - Afrikaans - South Africa arAE - Arabic - United Arab Emirates arBH - Arabic - Bahrain arDZ - Arabic - Algeria arEG - Arabic - Egypt arIQ - Arabic - Iraq arJO - Arabic - Jordan arLY - Arabic - Libya arMA - Arabic - Morocco arOM - Arabic - Oman arLB - Arabic - Lebanon arKW - Arabic - Kuwait arQA - Arabic - Qatar arSA - Arabic - Saudi Arabia arSY - Arabic - Syria arTN - Arabic - Tunisia arYE - Arabic - Yemen asIN - Assamese - India azAZ - Azerbaijani - Azerbaijan beBY - Byelorussian - Belarus bgBG - Bulgarian - Bulgaria bnIN - Bengali - India caES - Catalan - Spain csCZ - Czech - Czech Republic daDK - Danish - Denmark deAT - German - Austria deCH - German - Switzerland deDE - German - Germany deLI - German - Liechtenstein deLU - German - Luxembourg dzBT - Bhutani - Bhutan elGR - Greek - Greece enAU - English - Australia enBB - English - Barbados enBM - English - Bermuda enBZ - English - Belize enCA - English - Canada enGS - English - Bahamas enIE - English - Ireland enJM - English - Jamaica enNZ - English - New Zealand enPH - English - Philippines enUK - English - United Kingdom enUS - English - United States enZA - English - South Africa enTT - English - Trinidad and Tabago enVG - English - US Virgin Islands enVI - English - British Virgin Islands enZW - English - Zimbabwe esAR - Spanish - Argentina esBO - Spanish - Bolivia esCL - Spanish - Chile esCO - Spanish - Colombia esCR - Spanish - Costa Rica esCU - Spanish - Cuba esEC - Spanish - Ecuador esES - Spanish - Spain esDO - Spanish - Dominican Republic esGT - Spanish - Guatemala esHM - Spanish - Honduras esMX - Spanish - Mexico esNI - Spanish - Nicaragua esPA - Spanish - Panama esPE - Spanish - Peru esPR - Spanish - Puerto Rico esPY - Spanish - Paraguay esSV - Spanish - El Salvador esUY - Spanish - Uruguay esVE - Spanish - Venezuela etEE - Estonian - Estonia euES - Basque - Spain faIR - Farsi - Iran fiFI - Finnish - Finland foFO - Faeroese - Faeroe Islands frBE - French - Belgium frCA - French - Canada frCH - French - Switzerland frLU - French - Luxembourg frMC - French - Monaco frFR - French - France gaIE - Irish - Ireland guIN - Gujarati - India heIL - Hebrew - Israel hiIN - Hindi - India hrHR - Croatian - Croatia huHU - Hungarian - Hungary hyAM - Armenian - Armenia idID - Indonesian - Indonesia inID - Indonesian - Indonesia isIS - Icelandic - Iceland itCH - Italian - Switzerland itIT - Italian - Italy iwIL - Hebrew - Israel jaJP - Japanese - Japan jiIL - Yiddish - Isreal kaGE - Georgian - Georgia kkKZ - Kazahk - Kazahkstan klGL - Greenlandic - Greenland kmKH - Cambodian - Cambodia knIN - Kannada - India koKP - Korean - Democratic People's Republic of Korea koKR - Korean - Republic of Korea ksIN - Kashmiri - India kuIQ - Kurdish - Iraq loLA - Laothain - Laos ltLT - Lithuanian - Lithuania lvLV - Latvian - Latvia mkMK - Macedonian - Former Yugoslav Republic of Macedonia mlIN - Malayalam - India mnMN - Mongolian - Mongolia moMD - Moldavian - Moldava mrIN - Marathi - India msBN - Malay - Brunei Darussalam msMY - Malay - Malaysia mtMT - Maltese - Malta myMM - Burmese - Myanmar neNP - Nepali - Nepal nlBE - Dutch - Belgium nlNL - Dutch - Netherlands noNO - Norwegian - Norway orIN - Oriya - India paIN - Punjabi - India plPL - Polish - Poland ptBR - Portuguese - Brazil ptPT - Portuguese - Portugal roRO - Romanian - Romania ruRU - Russian - Russia saIN - Sanskrit - India skSK - Slovak - Slovakia slSL - Slovene - Slovenia smWS - Samoan - Samoa soSO - Somali - Somalia sqAL - Albanian - Albania suSD - Sudanese - Sudan svFI - Swedish - Finland svSE - Swedish - Sweden swKE - Swahili - Kenya taIN - Tamil - India teIN - Telugu - India thTH - Thai - Thailand trTR - Turkish - Turkey ukUA - Ukrainian - Ukraine urIN - Uru - India urPK - Urdu - Pakistan uzUZ - Uzbek - Uzbekistan viVN - Vietnamese - Viet Nam yiIL - Yiddish - Isreal zhCN - Chinese - China zhHK - Chinese - Hong Kong zhMO - Chinese - Macau zhSG - Chinese - Singapore zhTW - Chinese - Taiwan -------------------------------------- From RonBergman at aol.com Mon Apr 2 12:01:44 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> Fwd: Media Names, case sensitivity Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: Media Names, case sensitivity Date: Mon, 2 Apr 2001 08:57:08 -0700 Size: 1936 Url: http://www.pwg.org/archives/upd/attachments/20010402/9ff54fea/attachment-0001.mht From norbertschade at mediaone.net Mon Apr 2 18:16:05 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:09 2009 Subject: UPD> new locale list Message-ID: <003901c0bbc2$832407c0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 1810 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale-enUS-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 870 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1803 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFLocale-deDE-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 9158 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010402/00b2412d/UPDFEntities-0001.obj From hastings at cp10.es.xerox.com Mon Apr 2 19:51:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:09 2009 Subject: UPD> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCA4@x-crt-es-ms1.cp10.es.xerox.com> Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. Ron From don at lexmark.com Mon Apr 2 20:23:03 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <200104030906.FAA04419@interlock2.lexmark.com> Ron, et al: We don't need to wait until last call to assign a number. Cindy: Could you assign 5100.5 to this project: "Media Standardized Names"? ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** RonBergman%aol.com@interlock.lexmark.com on 03/30/2001 08:58:29 PM To: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: Fwd: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Return-Path: Received: from rly-zc03.mx.aol.com (rly-zc03.mail.aol.com [172.31.33.3]) by air-zc03.mail.aol.com (v77_r1.36) with ESMTP; Fri, 30 Mar 2001 19:49:48 -0500 Received: from triton.hitachi-hkis.com (mailport.dpc.com [192.101.159.107]) by rly-zc03.mx.aol.com (v77_r1.36) with ESMTP; Fri, 30 Mar 2001 19:49:17 -0500 Received: by triton.hitachi-hkis.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 16:53:12 -0800 Message-ID: <3BC1BD0C7E6DD411A13200508BDCC83D27BE70@triton.hitachi-hkis.com> From: "Bergman, Ron" To: "'Hastings, Tom N'" , "Bergman, Ron" , RonBergman@aol.com Cc: pwg@pwg.org, ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Date: Fri, 30 Mar 2001 16:53:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Thanks Tom! I believe I have all the other changes included and I plan to do a final check this weekend. So I'll hold off until these arrive so we can have a close to final draft next week. Regarding an ISTO-PWG assigned number, Don told me we have to wait until Working Group last call before it can be assigned. If we start the last call next week the earliest we would have a number is May 2nd. Why again must the UpNP have a number before the next meeting? Ron Here is the response from Don. >> >> Ron: >> >> We can assign this a number any time but.... >> >> 1) Since this is an output of the IPP working group, it needs a 2 week working >> group last call, then... >> >> 2) A PWG membership vote (another 2 weeks) >> >> 3) Then it will be posted to the PWG standards page probably as >> ftp://ftp.pwg.org/pub/pwg/standards/pwg5100.5.pdf >> >> ********************************************** >> * Don Wright don@lexmark.com * >> * Chair, Printer Working Group * >> * Chair, IEEE MSC * -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, March 30, 2001 4:06 PM To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From don at lexmark.com Mon Apr 2 20:02:18 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> Fwd: Media Names, case sensitivity Message-ID: <200104030907.FAA04443@interlock2.lexmark.com> All: I prefer we go with case insensitive names. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** RonBergman%aol.com@interlock.lexmark.com on 04/02/2001 12:01:44 PM To: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: IPP> Fwd: Media Names, case sensitivity Return-Path: Received: from rly-xb04.mx.aol.com (rly-xb04.mail.aol.com [172.20.105.105]) by air-xb02.mail.aol.com (v77_r1.36) with ESMTP; Mon, 02 Apr 2001 11:53:31 -0500 Received: from triton.hitachi-hkis.com (mailport.dpc.com [192.101.159.107]) by rly-xb04.mx.aol.com (v77_r1.36) with ESMTP; Mon, 02 Apr 2001 11:53:11 2000 Received: by triton.hitachi-hkis.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 08:57:09 -0700 Message-ID: <3BC1BD0C7E6DD411A13200508BDCC83D27BE71@triton.hitachi-hkis.com> From: "Bergman, Ron" To: "Tom Hastings (E-mail)" Cc: "'ipp@pwg.org'" , "'upd@pwg.org'" , "'RonBergman@aol.com'" Subject: Media Names, case sensitivity Date: Mon, 2 Apr 2001 08:57:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. Just stating the names are not case sensitive, puts the burden on the client. But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. Ron From harryl at us.ibm.com Tue Apr 3 10:31:46 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> RE: Media Names, case sensitivity Message-ID: I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/02/2001 05:51 PM To: "Bergman, Ron" cc: "'ipp@pwg.org'" , "'upd@pwg.org'" , "'RonBergman@aol.com'" , "pmp (E-mail)" Subject: IPP> RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. Ron From RonBergman at aol.com Tue Apr 3 11:53:37 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:09 2009 Subject: UPD> Fwd: FW: IPP> RE: Media Names, case sensitivity Message-ID: <93.91e03df.27fb4bfa@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 08:29:37 -0700 Size: 6505 Url: http://www.pwg.org/archives/upd/attachments/20010403/71a95b8c/attachment-0001.mht From hastings at cp10.es.xerox.com Tue Apr 3 15:30:22 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCDD@x-crt-es-ms1.cp10.es.xerox.com> Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 15:34:04 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCE0@x-crt-es-ms1.cp10.es.xerox.com> Michael wrote: Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? I think that we should just define the names and leave the attribute naming up to the print protocol folks. We should indicate that these names can apply to either or both sides of a medium. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Wednesday, March 28, 2001 19:21 To: Hastings, Tom N Cc: Bergman, Ron; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Hastings, Tom N" wrote: > ... > So I think we should not introduce the notion of roll media and > stick with roll media being out of scope. I personally disagree with this decision, especially since there *are* consumer inkjets today (and for the past several years, in fact) that support roll (sometimes called "banner") media of more-or-less arbitrary length. I understand that some things about roll media may be out of scope (cutting, marking, etc.), but to ignore roll media entirely will make this specification useless. I merely propose that the following media type be added to the current specification: 'roll' - A continuous roll of media whose limits are described by the custom-min and custom-max sizes. Again, it is *extremely* important that we support roll media types because they are available for many consumer inkjets as well as high-end devices. Most of these devices *do* need to know that you want to use roll fed media, and if no keyword is defined for it then you'll end up with a different name for each implementation. I agree, however, that things like cutter control and marking the page area on the media are beyond the scope of this specification, so any mention of roll media should be limited to the media type and not any of the other issues. > ... > So I would not oppose adding MediaCoating to the Media standard, > what do others think? Should we also then define the front and back coating, as is done for the other standards? Or are we just going to define the names of the values and leave the attribute naming up to the protocol folks? > ... > Translating the UPnP syntax to our ABNF would become: > > custom-media-size-max-self-describing-name = > [prefix] "custom-max" "." short-dim "-" long-dim > > custom-media-size-min-self-describing-name = > [prefix] "custom-min" "." short-dim "-" long-dim Yes, this will work perfectly well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From harryl at us.ibm.com Tue Apr 3 16:37:05 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:09 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 16:50:19 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:09 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCF4@x-crt-es-ms1.cp10.es.xerox.com> I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From harryl at us.ibm.com Tue Apr 3 17:04:49 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:09 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From hastings at cp10.es.xerox.com Tue Apr 3 17:23:25 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: IPP> min/max custom size values Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FCFC@x-crt-es-ms1.cp10.es.xerox.com> Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Tue Apr 3 18:34:38 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD11@x-crt-es-ms1.cp10.es.xerox.com> So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From hastings at cp10.es.xerox.com Tue Apr 3 18:53:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD16@x-crt-es-ms1.cp10.es.xerox.com> Minor terminology issue, since we seem to be agreeing to all lower case for our names: Are we really defining "keywords", rather than "names", in this media standard? Keywords are usually for program to program communication as intended by our media standard and are usually all lower case and can use case sensitive matching for simple interoperability and efficiency. On the other hand, names, are usually mixed case and need case insensitive matching and are more intended for direct human input or output. This distinction is exactly what IPP means by the 'keyword' versus 'name' attribute syntax (data type). IPP 'keywords' are all lowers case and the standard defines many keywords. IPP 'names' are mixed case and the IPP standard defines no standard names. Would it help the understanding of our Media standard to change the terminology by changing "Name" to "Keyword" throughout the standard, i.e., the standard defines Media Type Keywords, Media Color Keywords, and Media Size Self Describing Keywords, instead of Media Type Names, Media Color Names, Media Size Self Describing Names. Note: that if we agree to Harry's and Mark's proposal to define a concatenated syntax of our keywords, then we would be defining Media Keywords which could be used directly by the IPP "media" (keyword | name) Job Template attribute as keyword values. So the 'stationery.na-letter.8500-11000.white' keyword could be used by IPP "media" Job Template attribute. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, April 03, 2001 15:35 To: Bergman, Ron; 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron From RonBergman at aol.com Tue Apr 3 19:43:58 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From RonBergman at aol.com Tue Apr 3 19:50:26 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <42.12f7c934.27fbbbc3@aol.com> Tom, I am not sure we need to make the distinction here. If we strongly suggest all lower case then most of the difference is covered. Keywords may not be a universal term. Or the usage of the "media names" may vary with the referencing standard. Unless there is a very strong support for keyword, I propose we stick with name. Ron In a message dated Tue, 3 Apr 2001 6:53:56 PM Eastern Daylight Time, "Hastings, Tom N" writes: << Minor terminology issue, since we seem to be agreeing to all lower case for our names: Are we really defining "keywords", rather than "names", in this media standard? Keywords are usually for program to program communication as intended by our media standard and are usually all lower case and can use case sensitive matching for simple interoperability and efficiency. On the other hand, names, are usually mixed case and need case insensitive matching and are more intended for direct human input or output. This distinction is exactly what IPP means by the 'keyword' versus 'name' attribute syntax (data type). IPP 'keywords' are all lowers case and the standard defines many keywords. IPP 'names' are mixed case and the IPP standard defines no standard names. Would it help the understanding of our Media standard to change the terminology by changing "Name" to "Keyword" throughout the standard, i.e., the standard defines Media Type Keywords, Media Color Keywords, and Media Size Self Describing Keywords, instead of Media Type Names, Media Color Names, Media Size Self Describing Names. Note: that if we agree to Harry's and Mark's proposal to define a concatenated syntax of our keywords, then we would be defining Media Keywords which could be used directly by the IPP "media" (keyword | name) Job Template attribute as keyword values. So the 'stationery.na-letter.8500-11000.white' keyword could be used by IPP "media" Job Template attribute. Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, April 03, 2001 15:35 To: Bergman, Ron; 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From hastings at cp10.es.xerox.com Tue Apr 3 20:05:21 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD1F@x-crt-es-ms1.cp10.es.xerox.com> I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From RonBergman at aol.com Tue Apr 3 20:31:06 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: <73.c6b0934.27fbc543@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 17:08:26 -0700 Size: 14086 Url: http://www.pwg.org/archives/upd/attachments/20010403/75d40bf3/attachment-0001.mht From RonBergman at aol.com Tue Apr 3 20:31:52 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: <99.12f6b739.27fbc578@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Date: Tue, 3 Apr 2001 17:31:11 -0700 Size: 7631 Url: http://www.pwg.org/archives/upd/attachments/20010403/242e0e8e/attachment-0001.mht From hastings at cp10.es.xerox.com Tue Apr 3 20:37:35 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: Media Names, case sensitivity Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD25@x-crt-es-ms1.cp10.es.xerox.com> Looks good to me. One question: did you mean to say "case sensitive rules" or "case insensitive rules". If a referencing standard sticks with all lower case as we strongly recommend, then it can get away with the simpler case sensitive rules, right? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:08 To: 'RonBergman@aol.com'; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, Here is my proposal: "Media Names defined in this specification are presented using lower case characters. Other referencing standards may impose case sensitive rules if necessary. For interoperability and implementation efficiency, this standard strongly recommends these names be used in the lower case form defined in this document." Ron -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, April 03, 2001 4:44 PM To: ron.bergman@hitachi-hkis.com; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From hastings at cp10.es.xerox.com Tue Apr 3 20:50:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: min and max size and the creeping scope of the media standard [new subject] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD26@x-crt-es-ms1.cp10.es.xerox.com> Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:05 PM To: Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From hastings at cp10.es.xerox.com Tue Apr 3 22:13:20 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: min and max size and the creeping scope of the media standard [all-in-one names] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD28@x-crt-es-ms1.cp10.es.xerox.com> Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:05 PM To: Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I agree with Michael that we should add the maximum and minimum size name pattern for custom media. I don't share Ron's concern that adding the name pattern for custom minimum and maximum size will lead to anything further being needed in the Media Standard (if it did, then I might change my mind). I also believe that we have to add the min and max custom size if we want the UPnP WG to reference our standard from the UPnP BasicPrint Template for syntax and names for use in their MediaSize variables. Their current Template, which we hope to replace for Media Size and Media Type already have the custom min and max syntax. Satisfying the UPnP WG BasicPrint Template was one of the reasons to get this PWG Media standard done in the first place. I wrote on 3/28 as the syntax for adding custom max and minimum size names: 3. Request to represent minimum and maximum size for use with the custom mechanism. Interestingly, UPnP Print template has a way to represent the minimum and maximum sizes that a Printer supports using the custom syntax. Translating the UPnP syntax to our ABNF would become: custom-media-size-max-self-describing-name = [prefix] "custom-max" "." short-dim "-" long-dim custom-media-size-min-self-describing-name = [prefix] "custom-min" "." short-dim "-" long-dim A Printer that supports a minimum custom size of, say, 3 inches by 5 inches, and a maximum of, say, 8.5 inches by 14, would have the following two values: na-custom-max.8500-1400 na-custom-min.300-500 Any disagreements? I also believe that this meets Michael's needs for custom sizes, whether for the 'roll' Media Type or any of the other Media Type values. Tom -----Original Message----- From: Michael Sweet [mailto:mike@easysw.com] Sent: Thursday, March 29, 2001 12:09 To: Bergman, Ron Cc: 'Hastings, Tom N'; ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: Re: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded "Bergman, Ron" wrote: > ... > I disagee with your proposal for adding printer size restrictions > to the document. So far this specification has only involved > attributes related to media. Now you are proposing that we add > an attribute that is related to printers. This belongs in the > appropriate UPnP or IPP or other document that defines how to > describe a printer. If we add this then it will be necessary > ... I'm not sure I agree with this (or maybe I just not understanding your objection right); the purpose of this standard/spec is to define the names used for media sizes, types, finishes, etc. so that other protocols can then use those names uniformly. >From an implementation standpoint, it may be desireable to have media size names that are reserved for representing 1) whether custom media sizes are supported, and 2) what the size limits are for the device being queried. This allows all protocols to use a common method for conveying the custom media size information, while the exact values used in the custom size names are determined by the device and not the protocols or this spec. IPP contains no explicit support for custom media sizes; CUPS works around this limitation by supporting a "custom" media size keyword and relies on the to know that they can request a custom media size using the name "custom.WWWxLLL", where "WWW" and "LLL" are the width and length of the media in points (works well for a PS-based printing system... :) This only works for CUPS, and I have no idea what Microsoft does, for example, with their media support under Windows 2000... So, I guess what I'm saying is this: 1. Describe "custom-min" and "custom-max" media size names and the format they use. Specify that these names will only be present for devices that support custom sizes, and that both must appear if they are used at all. 2. Explicitly state that the values used in the custom-min/max names are defined by the device and not the spec. 3. Explicitly state that the units for media sizes in the size names are set by the media spec and not by the protocol spec. Units outside the size name can obviously be anything the protocol wants... #1 will make sure that any client can determine if a device supports custom sizes, no matter what protocol is being used. #2 will remove any requirement for additional info in the media spec on how to manage custom sizes. #3 will ensure that the dimensions in size names are consistent no matter what protocol is being used. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From harryl at us.ibm.com Wed Apr 4 10:47:12 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: Looks good. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- RonBergman@aol.com Sent by: owner-ipp@pwg.org 04/03/2001 06:31 PM To: , , cc: Subject: Fwd: RE: IPP> RE: Media Names, case sensitivity ----- Message from "Bergman, Ron" on Tue, 3 Apr 2001 17:08:26 -0700 ----- To: "'RonBergman@aol.com'" , harryl@us.ibm.com, hastings@cp10.es.xerox.com cc: ipp@pwg.org, owner-ipp@pwg.org, pmp@pwg.org, upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, Here is my proposal: "Media Names defined in this specification are presented using lower case characters. Other referencing standards may impose case sensitive rules if necessary. For interoperability and implementation efficiency, this standard strongly recommends these names be used in the lower case form defined in this document." Ron -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, April 03, 2001 4:44 PM To: ron.bergman@hitachi-hkis.com; harryl@us.ibm.com; hastings@cp10.es.xerox.com Cc: ipp@pwg.org; owner-ipp@pwg.org; pmp@pwg.org; upd@pwg.org Subject: RE: IPP> RE: Media Names, case sensitivity Tom, I would reword slightly, but it does convey what is desired. Ron In a message dated Tue, 3 Apr 2001 6:35:35 PM Eastern Daylight Time, "Hastings, Tom N" writes: << So how about the following short, clear, concise conformance statement: Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard STRONGLY RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 14:22 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RonBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity I agree with Harry. This document really should not mandate case sensitivity. We should simply STRONGLY RECOMMEND lower case. Adding more paragraphs does nothing. All a document that references this standard needs to do is state "...names per IEEE ISTO PWG 5100.5, with all names represented using upper case characters." Unless we hire Brinks or the Mafia, we cannot force anyone to fully comply. As Harry said "a short, clear, concise definition" Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 2:05 PM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); 'RoBergman@aol.com'; Bergman, Ron; 'upd@pwg.org' Subject: RE: IPP> RE: Media Names, case sensitivity If we want to insist on all lower case then why don't we just say so? I just want a short, clear, concise definition. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 02:50 PM To: "Bergman, Ron" , "'Harry Lewis'" cc: "'ipp@pwg.org'" , owner-ipp@pwg.org, "pmp (E-mail)" , "'upd@pwg.org'" , "'RoBergman@aol.com'" , "pmp (E-mail)" Subject: RE: IPP> RE: Media Names, case sensitivity I'd like to express an objection to Harry's proposal for case insensitiveness in media names. As I understand case insensitiveness, any mixture of upper and lower case characters match and must be treated as equivalent. Therefore, a recipient (client or Printer) has to convert to some internal case convention before comparing for a match. But to be user friendly, such a recipient (Printer) should remember the case that was originally sent by the client, so that the user when querying the same attributes subsequently, sees the original case that the user submitted. To me, such implementation does not lead to "interoperability and implementation efficiency", but just the opposite. That is why IPP specifically uses all lower case for keyword attribute values and so does UPnP. So do other protocols that use IPP semantics. Even prtInputMediaType object in the Printer MIB (RFC 1759) has all lower case values defined. Now that we have general agreement in the current print protocols to use all lower case, why not at least RECOMMEND all lower case be used by such referencing standards? So I'd like to see something like Harry's approach, but RECOMMEND that values be all lower case. After all, keywords are really tokens for programs, not people. Having to deal with case conversion in a protocol for no benefit, seems a waste. Also once keyword names are all lower case, then they are also "case sensitive", allowing for more efficient matching. So if a client supplies a keyword name with some uppercase characters, they won't match the supported values that the Printer has (since they are all lower case). BTW, IPP does RECOMMEND case insensitive matching for attributes with 'name' data type, but the 'keyword' data type MUST be all lower case (and hence case sensitive matching for keywords is simpler and correct). Also I'd like to see the statement moved from the Media Size Self Describing Names section to the general conformance section for all three kinds of names, as suggested by Ron. So using Harry's approach, but making it apply for Media Type Names, Media Color Names, and Media Size Self Describing Names, the following two paragraphs would be added to section 6 Conformance Requirements: " Letters in the names defined in this standard use all lower case. For interoperability and implementation efficiency, this standard RECOMMENDS that other referencing standards also use these names in their all-lower-case form. Then case sensitive matching can be used. However, other referencing standards MAY allow substitution of any lower case letter with its corresponding uppercase letter in the names defined in this standard. Such standards MUST require that such substituted letters be treated as equivalent to their corresponding lower case letters, i.e., case-insensitive matching. For example, if a referencing standard allows uppercase letters in the names defined in this standard, then the following examples MUST be equivalent: 'na-letter.8500-11000', 'NA-LETTER.8500-11000, 'NA-Letter.8500-11000', 'Na-LeTtEr.8500-11000'. " Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 07:54 To: 'Harry Lewis'; Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org'; 'RoBergman@aol.com' Subject: RE: IPP> RE: Media Names, case sensitivity Harry, I like your proposal and unless others express an objection will add this to the document. Ron -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 7:32 AM To: Hastings, Tom N Cc: 'ipp@pwg.org'; owner-ipp@pwg.org; pmp (E-mail); Bergman, Ron; 'upd@pwg.org' Subject: Re: IPP> RE: Media Names, case sensitivity I suggest something more compact like - "Media Size Self Describing Names are not case sensitive. As a convention, they are presented here using lower case characters. Other referencing standards may impose case sensitive rules across their own interface. For interoperability and implementation efficiency, imposing case sensitivity is not recommended. " ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 18:16 To: 'Hastings, Tom N'; Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Tom, See my comments below Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Monday, April 02, 2001 4:52 PM To: Bergman, Ron Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com'; pmp (E-mail) Subject: RE: Media Names, case sensitivity Ron, About case sensitivity in names in the Media standard: Draft 0.3 had: Media Size Self Describing Names are not case sensitive but will always be presented in this standard using lower case characters. What I changed it to was: While Media Size Self Describing Names are presented in this standard using lower case characters, other standards that use these names, MUST indicate the case sensitivity for their conformance. Such other standards MAY: a) also require only lower case as in this standard b) allow lower, upper case, and mixed case to be used with the same meaning as the names in this standard, i.e., case insensitive matching c) require all uppercase letters to be used with the same meaning as the corresponding names in this standard. Discussion: The important question is what interface is the media standard defining conformance requirements for? I had assumed that the media standard was NOT trying to define an interface that the Printer would implement or that a client would implement, but rather was giving a set of names and their semantics that other standards would reference. RB >> I agree! It would be up to these other standards to say whether or not case was important. For example, IPP says that keywords are all lower case, so that both client and Printer can count on having all lower case and not having to worry about case conversion. Other protocol, such as the Printer MIB use of MediaType and UPnP use of MediaType and MediaSize would have to say whether or not case was important. We might want the Media standard to RECOMMEND that these other standards only use all lower case. That would lower the burden on a Printer that is supporting, say, IPP, UPnP, and Printer MIB, if all three standards REQUIRED that the values be all lower case. RB >> If IPP requires lower case and UpNP requires upper case, then responses from the printer that contain media names have to be converted for one client or the other, depending upon the printer table. Existing IPP printers most likely have the table implemented as lower case. So, I would recommend that to be compatible we should really REQUIRE lower case. Then it would be compatible with current IPP clients and servers. The problem is not always on the printer (server) side, since the client can also send media names to the server. RB >> I would prefer to specify "not case sensitive" but I see now that for IPP compatibility it is best to require lower case. RB >> A good design will always convert received characters to a specific case and send any characters in the specified case. It would be best if all protocols specified and then the sender could use common code for all. BTW, I have seen some IANA Registries where the tokens are all upper case. That is why I included alternative c) above as well. Bottom line: The Media standard is writing conformance for other standards that reference the Media standard (like the IPP Notification Standard placed requirements on Delivery Method documents), not conformance for Printers or clients. RB >> I agree, and lower case would be the best choice for conformance. See my replies to your message below preceded by TH> Comments? Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Monday, April 02, 2001 08:57 To: Hastings, Tom N Cc: 'ipp@pwg.org'; 'upd@pwg.org'; 'RonBergman@aol.com' Subject: Media Names, case sensitivity Tom, I am curious as to why you changed my original statement that the names are not case sensitive to the the complicated set of requirements that, in effect, states "do whatever you want, but explicitly state what you want." TH> The draft is stating that other standards that use these names do what they want, but those standards (such as IPP, UPnP, Printer MIB, etc.) MUST say what they require. Your specification puts a larger burden on the Printer, since the printer will have to conform to the applications. (The printer may have to do a case conversion for some applications and not others.) So the printer (or other device) must know the exact format required by the application. TH> The Printer will have to conform to whatever standards the Printer chooses to support, i.e., IPP, UPnP, Printer MIB, ... Just stating the names are not case sensitive, puts the burden on the client. TH> I disagree. It depends on what the other standards say about case sensitivity. Perhaps the Media standard can RECOMMEND that other standards REQUIRE all lower case, as I suggested above. Wouldn't that help? RB >> Do any other standards, besides IPP exist? But the client simply has to do a conversion on all names received to whatever case he has chosen for his tables. The client does not need to know what the printer is sending. Whatever we conclude,, this text needs will be moved from section 5 to section 10, since it applies to all the names in the specification. TH> I agree it should be moved to a section that is common for all the names. However, section 10 is the authors section. RB >> I should have said the conformance section. Ron >> From RonBergman at aol.com Wed Apr 4 11:13:53 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: RE: IPP> RE: Media Names, case sensitivity Message-ID: <32.12ee56dd.27fc9431@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: IPP> RE: Media Names, case sensitivity Date: Tue, 3 Apr 2001 17:59:03 -0700 Size: 15282 Url: http://www.pwg.org/archives/upd/attachments/20010404/1d161266/attachment-0001.mht From RonBergman at aol.com Wed Apr 4 11:14:37 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: RE: min and max size and the creeping scope of the media standard [new subject] Message-ID: <99.12f8835c.27fc945d@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: min and max size and the creeping scope of the media standard [new subject] Date: Tue, 3 Apr 2001 18:38:31 -0700 Size: 9864 Url: http://www.pwg.org/archives/upd/attachments/20010404/d7a5d5f6/attachment-0001.mht From RonBergman at aol.com Wed Apr 4 11:15:19 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: RE: min and max size and the creeping scope of the media standard [all-in-one names] Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Date: Wed, 4 Apr 2001 08:01:47 -0700 Size: 12770 Url: http://www.pwg.org/archives/upd/attachments/20010404/368ac241/attachment-0001.mht From kugler at us.ibm.com Wed Apr 4 11:35:48 2001 From: kugler at us.ibm.com (Carl Kugler) Date: Wed May 6 14:05:10 2009 Subject: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Message-ID: I'm a little concerned about overloading the term Media Type for envelop, different kinds of paper, etc., since we already use that in document-format values (e.g., text/plain, application/postscript, etc.). -Carl From hastings at cp10.es.xerox.com Wed Apr 4 16:58:18 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Dr aft D0.4 down- loaded Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD6E@x-crt-es-ms1.cp10.es.xerox.com> Yes, there is a potential for confusion between the term Media Type in our Media Name standard and MIME Media Types, but... The term "media" to mean something to write on has been around a lot longer than the IETF and MIME, so I think the best approach to avoid the obvious confusion is to put the adjective MIME in front of media when we are talking about document-format values and use the term "media type", i.e., MIME Media Type to distinguish it from Media Type (stationery, transparency, etc.), OK? Also the attribute "media-type" is a member attribute of the "media-col" attribute in the approved PWG IEEE-ISTO Production Printing Extension. Also the attribute MediaType is a parameter in the almost approved UPnP BasicPrint Template. Here is the current text in IPP RFC 2911 about the subject (which I think avoids any confusion): 4.1.9 'mimeMediaType' The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and registered according to the procedures of RFC 2048 [RFC2048] for identifying a document format. The value MAY include a charset, or other, parameter, depending on the specification of the Media Type in the IANA Registry [IANA-MT]. Although most other IPP syntax types allow for only lower-cased values, this syntax type allows for mixed-case values which are case-insensitive. "document-format" (mimeMediaType): The client OPTIONALLY supplies this attribute. The Printer object MUST support this attribute. The value of this attribute identifies the format of the supplied document data. The following cases exist: 4.4.21 document-format-default (mimeMediaType) This REQUIRED Printer attribute identifies the document format that the Printer object has been configured to assume if the client does not supply a "document-format" operation attribute in any of the operation requests that supply document data. The standard values for this attribute are Internet Media types (sometimes called MIME types). For further details see the description of the 'mimeMediaType' attribute syntax in Section 4.1.9. Bottom line: I don't think we should change our Media Type terminology in our Media Names Standard. Tom -----Original Message----- From: Carl Kugler [mailto:kugler@us.ibm.com] Sent: Wednesday, April 04, 2001 08:36 Cc: ipp@pwg.org; upd@pwg.org; pwg@pwg.org Subject: Re: PWG> Fwd: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded I'm a little concerned about overloading the term Media Type for envelop, different kinds of paper, etc., since we already use that in document-format values (e.g., text/plain, application/postscript, etc.). -Carl From hastings at cp10.es.xerox.com Wed Apr 4 18:38:30 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD7C@x-crt-es-ms1.cp10.es.xerox.com> Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Wed Apr 4 20:37:24 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> Suggested Appendix for Media Names Standard for existing standard s Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FD8F@x-crt-es-ms1.cp10.es.xerox.com> I've drafted and attached an MS-WORD short Appendix B for the Media Names standard to indicate the existing standards that are intended to make use of this standard, namely the Printer MIB, IPP/1.0 and IPP/1.1, and the PWG IEEE-ISTO 5100.3 IPP Production Printing Attributes - Set1. I've indicated which objects and attributes in these standards are intended to use which names in the Media Name standard. I assume that standards that have not yet been published, such as the UPnP BasicPrint Template, should reference the PWG Media Names standard directly before being published, so we don't need to do that in our Media Names standard, OK? So I did not include mention of the UPnP BasicPrint Template in the proposed Appendix. This proposal also assumes that we add an Appendix A before it that defines some way to do All In One Media Names, which I reference in the tables. I would have made a flat text version, but I did it as tables to keep it short and easy to use. Comments? Tom <> -------------- next part -------------- A non-text attachment was scrubbed... Name: Appendix B-referenced-stds-as-tables.doc Type: application/msword Size: 38912 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010404/c00c3029/AppendixB-referenced-stds-as-tables-0001.doc From don at lexmark.com Thu Apr 5 03:18:59 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <200104050721.DAA24965@interlock2.lexmark.com> All: I too am violently opposed to this addition to what STARTED as a nice, simple, short standard that accomplished a lot. I would hate to see this grow and grow and grow until we can specify: toilet-tissue.na-4x4.4000-4000.white.extra-soft.two-ply.lubricated PLEASE STOP!! Write another INFORMATIONAL document if you want to do this. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From markv at us.ibm.com Thu Apr 5 09:58:15 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:10 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From harryl at us.ibm.com Thu Apr 5 10:53:12 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: IPP> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: I don't know, Don... that's pretty descriptive and easy to understand and parse, to me! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-ipp@pwg.org 04/05/2001 01:18 AM To: ipp@pwg.org, upd@pwg.org cc: Subject: IPP> Stop me before I kill again... was: Thoughts on the all-in-one name string for the Appendix of the Media Name standard All: I too am violently opposed to this addition to what STARTED as a nice, simple, short standard that accomplished a lot. I would hate to see this grow and grow and grow until we can specify: toilet-tissue.na-4x4.4000-4000.white.extra-soft.two-ply.lubricated PLEASE STOP!! Write another INFORMATIONAL document if you want to do this. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Thu Apr 5 13:58:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FDC2@x-crt-es-ms1.cp10.es.xerox.com> Mark, I agree that you need all of the information together that an implementation supports for a sensible selection by the user. The problem is: Can we agree on what the information is, or does it vary so much from implementation to implementation, that we can only hope to agree to a core set and leave the rest to implementation? Unfortunately, leaving very much to implementation, means that a client is unlikely to be able to work with implementations from different vendors, especially if the client has to localize the fields for the user. So, what is your favorite list of media characteristics with values that you'd like to see in a standard? Is there a small subset that we can agree to now and work on additional fields in a separate standard that augments what we can agree to for the Media Names standard now? Don, I was think out loud about different ways that we could try to put all of the fields in the All In One Name Appendix. I agree with you that we should put into the Media Names Appendix only what we can agree to now and work on augmenting that in a future standard when we have more time. So lets not put anything into the current Appendix that we might regret in the future document. OK? Thanks, Tom P.S. Plug for the IEEE-ISTO 5100.3 IPP Production Printing Attributes - Set1 standard. It allows the user to select from 12 media fields using the "media-col" (collection) Job Template attribute. See http://ftp.pwg.org/pub/pwg/standards/pwg5100.3.pdf, .doc, .rtf. -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Thursday, April 05, 2001 06:58 To: don@lexmark.com Cc: ipp@pwg.org; upd@pwg.org Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Thu Apr 5 19:48:11 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FDF3@x-crt-es-ms1.cp10.es.xerox.com> Ron, A number of us considered your proposal to add: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted to the Media Type Names. We think that would be a mistake. Draft D0.5 has the Media Type Names as: stationery transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock and we've agreed to add 'roll' and drop 'other' However, we think it would be a mistake to add the 5 values that you proposed, even though it seems simple. The reason for not adding them is that they are more orthogonal to Media Type, i.e., they apply to more than one type value: 'bond' can apply to stationery, envelope, envelope-plain, envelope-window 'recycled' can apply to stationery, envelope, envelope-plain, envelope-window, perhaps the 3 continuous values, the 3 tab values, cardstock, and roll. 'punched' can apply to stationery, tab-stock, pre-cut-tabs, full-cut-tabs, photographic. 'letterhead' can apply to stationery, envelope, envelope-plain, envelope-window. 'pre-printed' can apply to stationery, envelope, envelope-plain, envelope-window. We think that the better way to add these quasi orthogonal fields is as separate, optional fields set off by ".". So for our All In One Name, any of these values can be appended as fields. But if the media doesn't have the characteristic it doesn't have the field and doesn't have the ".". So the following are possible additional fields: bond recycled pre-punched letterhead or pre-printed They can be used in principle with any of the fields we have already defined. I'll send out a complete proposal later today. It is really simple, compared to the thoughts that I sent out yesterday that has gotten the negative reaction. Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 18:29 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Tom, This new proposal is much more complex than what was presented yesterday. I thought that the previous version was more than adequate for what was requested. I would like to hear from those that were asking for the "all-in-one" format before we make any further decisions on either proposal. I did notice one item in reading your proposal... I was about to suggest the addition of the media types: - stationery-bond - stationery-recycled - stationery-punched - stationery-letterhead - stationery-preprinted Which seem to fit very well into the current list of media types. I see that the Production Printing Extension has media-pre-printed as a separate attribute with keywords pre-printed and letter-head. Also, media-recycled is a separate attribute. It seems that extending the stationary type, as is done with envelope and continuous may not be as flexible but provides a fewer number of attibutes. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, April 04, 2001 3:39 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Ron, Here are some thoughts for the Media Names Standard appendix about concatenating fields to make an all-in-one name string that could be used as keyword values of the IPP/1.1 "media" Job Template attribute. I hope people will comment, especially those who have advocated the all-in-one name string fills an important need (which I agree with). The Media Names standard already has three fields: Media Type Name: stationery, transparency, envelope, envelope-plain, envelope-window, continuous, continuous-long, continuous-short, tab-stock, pre-cut-tabs, full-cut-tabs, multi-part-form, labels, multi-layer, screen, screen-paged, photographic, cardstock Media Size Self Describing Name: [prefix] size-name "." short-dim "-" long-dim Media Color Name: 'no-color', 'white', 'pink', 'yellow', 'blue', 'green', 'buff', 'goldenrod', 'red', 'gray', 'ivory', 'orange' and we've agreed to add Media Coating names: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' Assumption: that the three fields in our current draft MUST be present in an all-in-one name string and in order, separated by "." without any need to name the fields, since they all must be present: Media Type Name "." Media Size Self Describing Name "." Media Color Name Examples: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue >From the PWG IEEE-ISTO 5100.3 IPP Production Printing Extension, we have 7 additional member attributes of the "media-col" collection that could be fields in an all-in-one name string: media-pre-printed: 'blank', 'pre-printed', letter-head' media-hole-count: '0', '1', '2', '3', ... media-order-count: '1', '2', '3', ... media-weight-metric: '80', ... media-back-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-front-coating: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' media-recycled: 'none', 'standard' I'm using these 7 fields from the PWG 5100.3 as examples of how to extend the all-in-one string name that could be used with the IPP/1.1 "media" Job Template attribute. Whether our Appendix should give these as examples, or just give the pattern for additional fields, needs to be decided. These 7 additional fields are OPTIONAL in two senses: a. the implementation doesn't support the concept b. the implementation does support the concept, but the usual value of the field is 'none' for most media instances. 6 of the 7 fields have a natural 'none' value that could be represented by the omission of the field, rather than a specific value: pre-printed=blank, hole-count=0, order-count=1, back-coating=none, front-coating=none, recycled=none. Only weight-metric always needs a value if weight is supported. Whether or not these "optional" fields could occur in any order would depend on the standard that references the Media Name standard. I see three different approaches to combining the remaining 7 optional fields into an all-in-one name string, from most rigorous for machine parsing to simplest for human recognition. a. have each field start with a field name and a special character. Since "_" is the only character in IPP keyword syntax not used, I'm suggesting using it as the delimiter character. Example fields: 'recycled_standard', 'hole-count_3', 'front-coating_matte' b. have each field start with a field name set off by 'hyphen'. Examples: 'recycled-standard', 'hole-count-3', 'front-coating-matte' c. don't have field names at all. Just depend on the values not colliding. Examples: 'recycled', 'matte'. But that can't be done for the numeric values, for weight, hole count, order count, so need prefix or suffix for them. Examples: '3-hole', 'order-count-2' Here are the 5 examples above with each of the three methods: a. field names set off with "_": stationery.na-letter.8500-11000.white.weight-metric_80 stationery.iso-a4.iso-a4.2100-2970.white.weight-metric_80.pre-printer_letter -head photographic.na-5x7.5000-7000.white.weight-metric_80.front-coating_matte transparency.na-letter.8500-11000.no-color.weight-metric_80.hole-count_3 envelope.na-9x11.9000-11000.blue.weight-metric_80.recyled_standard b. field names set off with "-": stationery.na-letter.8500-11000.white.weight-metric-80 stationery.iso-a4.iso-a4.2100-2970.white.pre-printer-letter-head photographic.na-5x7.5000-7000.white.weight-metric-80.front-coating-matte transparency.na-letter.8500-11000.no-color.weight-metric-80.hole-count-3 envelope.na-9x11.9000-11000.blue.weight-metric-80.recycled-standard c. no field names, except for numeric data: stationery.na-letter.8500-11000.white.80gpsm stationery.iso-a4.iso-a4.2100-2970.white.letter-head photographic.na-5x7.5000-7000.white.80gpsm.matte transparency.na-letter.8500-11000.no-color.80gpsm.3-holes envelope.na-9x11.9000-11000.blue.80gpsm.recycled Someone had asked a question about the Media Coating as to whether we were just defining the name values or whether we were also defining the attributes, so that the coating for the front could be specified separately from the back. So we probably need to pick something for our Appendix for the Coating for front versus back. Comments? Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Wednesday, April 04, 2001 08:02 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Tom, Based upon the IPP restriction, the period is acceptable. As far as having some parameters optional in the string, my preference is no. Every parameter must have a value. This keeps processing the string simple and additional parameters can be added without breaking any old applications. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 7:13 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [all-in-one names] Ron, While slash is kind of clear, the problem is that it can't be used as an IPP keyword for the "media" attribute. IPP 'keyword' values can only be all lower case letters, digits, ".", "-", and "_". We wouldn't want to have IPP encode these all in one names using the 'name' attribute syntax, since IPP RECOMMENDs case insensitivity (upper case allowed and equivalent to lower case) for the 'name' attribute syntax values. I don't see any problem with using the "." to separate fields in the all-in-one names, since the media size field must have a "." within it as well. With ".", the names are like: stationery.na-letter.8500-11000.white.none which really reads pretty well. The fact that the Media Size Self Describing Name field is made up of two fields: Media Size Name and Dimensions, doesn't both me and still fits our syntax. But if there is objection to this dual use of ".", the underscore ("_") character is also available in the IPP 'keyword' syntax. Using the underscore character the names would look like: stationery_na-letter.8500-11000_white_none But if we use underscore to separate the fields, what will we use if we want to make fields optional, such as the Media Coating, which will usually want to be 'none'? There aren't any more IPP 'keyword' characters left. I had suggested that we might want to put the name of the field as a prefix separated by "_", if the field can be left out. Then we could have: stationery.na-letter.8500-11000.white -- meaning no coating and: stationery.na-letter.8500-11000.white.coating_matte when a coating other than none was wanted. Or we could just bite the bullet and always carry coating 'none' along in the names, since these names are intended for program to program communication and have no optional field mechanism. We could leave the idea of optional fields to the future (as long as we don't use up "_" now). Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 18:39 To: 'Hastings, Tom N'; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: RE: min and max size and the creeping scope of the media standard [new subject] Tom, The all-in-one could be postponed. I was thinking it should be an appendix in the Media Names standard as the recommended method of concatenating the defined media names to create a single media definition. Even so, it could be first published as an addendum and then later integrated into the standard in next years update. If we are close to having an agreement, it could be added now. I have no problem with your proposal. One thought I had was replacing the period as a separator between names with a slash(/). This might be easier on a parser, since the period is now the separator in the size name. So your example would be: stationery/na-letter.8500-11000/white/none Or, would a different character be better? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 5:51 PM To: Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail); Michael Sweet Subject: Re: min and max size and the creeping scope of the media standard [new subject] Looks good to me for the min and max. I agree that it fits within the scope of the standard. About the creeping scope of the media standard, I agree that UPnP doesn't need the all-in-one, but IPP could really use it. But if everyone keeps adding requirements, we'll never get what we seem to have good agreement on done. How about stopping the current version with: Media Type Names Media Color Names Media Finish Names Media Size Self Describing Names and then add the all-in-one as a companion PWG standard which augments this standard and which also has any other fields needed as well? Much as I'd like to see the all-in-one for IPP for use with the existing "media" Job Template attribute, I think that it can wait a few months. Also I suspect that it will take more debate and design. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Tuesday, April 03, 2001 17:31 To: 'Hastings, Tom N'; Michael Sweet; Bergman, Ron Cc: ipp (E-mail); UPDF WG (E-mail); 'RonBergman@aol.com'; Norbert Schade (E-mail) Subject: RE: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down- loaded Tom, I have added the following: 5.2.5 The size-name "max" shall be reserved to indicate an upper size limit of either a device or application. Also, the size-name "min" shall be reserved to indicate a lower size limit. Example: For a device that can process forms as small as 2 x 3 inches to 18 x 36 inches: na-custom-max.18000-36000 and na-custom-min.2000-3000 This is part of the custom size section (5.2). My original concern was how this was to be presented. This paragraph keeps within my guidelines as more applicable to media and not a device. I am quite sensitive to the issue of expansion of the scope of this project. Keep in mind that this started out as a simple compilation of all known media sizes. We have since added color, type, finish, and now there is a proposal for an all-in-one format. There also have been rejected proposals for media feed direction, printing orientation, and others that I have already forgotten. Not that what has been added is bad, we just have to be somewhat selective as to what is included. On the one hand, I am hearing that the UPnP project needs this completed before the meeting this month and then I see all the additions everyone wants. When sonething is added, it may add a nice feature, but it also pushes out the completion date. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Tuesday, April 03, 2001 14:23 To: Harry Lewis; Mark VanderWiele Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values Harry and Mark, To build on your idea (you turned me around), we could take the current IPP "media" attribute and define how to concatenate the keyword values in the Media Standard to make new IPP keywords, to make a "joined syntax". If we did that and put the concatenation rules into the Media standard itself, then we would be defining Media Names (something that the current draft says we aren't doing - see the Media Name definition in Section 2 Terminology, but we can just change that statement). We can just put the rules for combining the keyword values together. We don't need to add any more tables. All we need to do is pick the order and the separator character. For order, how about in order of decreasing significance: Media Type Name Media Size Name Media Color Name Media Coating Name (we've agreed to add this fourth set of names) For a separator character, I suggest that we use the ".", which we are already using as a separator character in the MediaSize. Examples of Media Names: stationery.na-letter.8500-11000.white.none stationery.iso-a4.iso-a4.2100-2970.white.none photographic.na-5x7.5000-7000.white.matte transparency.na-letter.8500-11000.no-color.none envelope.na-9x11.9000-11000.blue.none For the first three fields, they MUST all be present. But what about Media Coating. The values are: 'none', 'glossy', 'high-gloss', 'semi-gloss', 'satin', 'matte' If this were the last field ever, then we could say if it is missing, then it means 'none'. But I suspect that we want to be able to keep adding fields in the future (or that implementers might want to be able to add fields). Do we need to introduce keywords for those fields that can be omitted, such as Media Coating? The equal sign (=) would be more natural to set off keywords from values. However, to be compatible with IPP, the only unassigned character in IPP keywords is "underscore" (_). So think of the "coating_" as a prefix on the values. So the above 5 examples would be: stationery.na-letter.8500-11000.white stationery.iso-a4.iso-a4.2100-2970.white photographic.na-5x7.5000-7000.white.coating_matte transparency.na-letter.8500-11000.no-color envelope.na-9x11.9000-11000.blue Only the third one has the keyword coating, since it is the only one that has a coating that isn't 'none'. We probably have to define a canonical order for keywords presence or absence, in order to eliminate different orderings being equivalent, correct? Comments? Tom -----Original Message----- From: Harry Lewis [mailto:harryl@us.ibm.com] Sent: Tuesday, April 03, 2001 13:37 To: Hastings, Tom N Cc: Mark_Hamzy/Austin/IBM%IBMUS; IPP Group; Mark VanderWiele; Norbert Schade; owner-ipp@pwg.org; Pete Zannucci; UPD group Subject: RE: UPD> Re: IPP> min/max custom size values I think one of the things that might be encouraging Mark to recommend a "joined syntax" is the rate at which we keep inventing and/or applying new access protocols to this information (SNMP, IPP, uPnP etc.). If we were to define a joined syntax that concatenates the necessary information to "use" the media in the device (including Media Size, Media Type, Media Source, Media Name) there would be a greater chance of adoption across protocols (new and revised). ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- "Hastings, Tom N" Sent by: owner-ipp@pwg.org 04/03/2001 01:30 PM To: Mark VanderWiele , Norbert Schade cc: UPD group , IPP Group , Pete Zannucci , Mark_Hamzy/Austin/IBM%IBMUS Subject: RE: UPD> Re: IPP> min/max custom size values Mark, I agree that real applications need to know about combinations of media attributes. However, each print protocol has different ways to deal with that. So I think it is wiser for the Media standard to just list the names of the various characteristics and leave it to the various Print protocols do deal with combinations. Ok? For example, have you seen the IEEE-ISTO PWG 5100.3 Production Printing Extension, which does combine the media attributes into a collection, so that combinations can be configured by the administrator. However, even that spec does not have a way for the client to query the supported combinations. Last summer and fall, the IPP WG considered a proposal for a Resource object that had a number of operations to create, delete, and query Resource objects of a defined type. Media was a suggested type. Then the group agreed that IPP should really have distinct set of operations for each object type, so that we need to write a spec for the Media object that has operations, like Create-Media, Delete-Media, Get-Media-Attributes, Get-Media (with a filter). Are you interested in seeing such a spec and reviewing and/or contributing to it? An another example or a print protocol that deals with the combinations problem, the UPnP EnhancedLayoutPrint template defines a GetMargins operation in which the input parameters are MediaType and MediaSize and the output parameter is the four margins. If the client supplies a combination of MediaType and MediaSize that is not supported, the Printer MUST return an error code. Thanks, Tom -----Original Message----- From: Mark VanderWiele [mailto:markv@us.ibm.com] Sent: Friday, March 30, 2001 07:44 To: Norbert Schade Cc: UPD group; IPP Group; Pete Zannucci; Mark_Hamzy/Austin/IBM%IBMUS Subject: Re: UPD> Re: IPP> min/max custom size values Careful, we may be making the same mistake we made in IPP where the form size, media type, and tray are returned separately causing user interface nightmare since all three of these really must be selected together and represent the actual configuration of the printer. Therefore, I would propose that when we have settled in on a syntax for the form size, media type, and tray we go one step further and define a way to join the fields so that the proper constraints can be represented. Perhaps a simple "+" character. Again, form size by itself is meaningless. Regards, Mark VanderWiele IBM, Linux Tecnology Center 512-838-4779, t/l 678-4779 MARKV@IBMUS email: markv@us.ibm.com From hastings at cp10.es.xerox.com Fri Apr 6 06:08:18 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE0B@x-crt-es-ms1.cp10.es.xerox.com> Ron, Minor issue: which wins if dimensions are correct for the media size name? For example, for the Media Size Self-Describing Name is iso-a4.100-200, is the size ISO A4 or 10 by 20 mm? I suggest that the dimensions take precedence over the name. So we need to add such a statement in the document. Comments? Tom From RonBergman at aol.com Fri Apr 6 16:20:31 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Message-ID: <4a.13f299d0.27ff7f0f@aol.com> -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: RE: MED - Thoughts on the all-in-one name string for the Appendix of the Media Name standard Date: Fri, 6 Apr 2001 11:12:43 -0700 Size: 24127 Url: http://www.pwg.org/archives/upd/attachments/20010406/48a620c6/attachment-0001.mht From hastings at cp10.es.xerox.com Fri Apr 6 17:03:23 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> MED - Proposal for simple Media Self Describing Names (all in one names) Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE5B@x-crt-es-ms1.cp10.es.xerox.com> A number of us have looked at the problem posed by Harry and Mark to define a very simple "all-in-one" name syntax. This is our proposal. The entire proposal is three pages, plus examples, including listing the values that we currently have for Media Type and Media Color in the D0.5 draft. The attached .doc file is the MS-WORD version. We suggest that it could be a separate section or an Appendix in the Media Names Standard. Comments? Thanks, Tom and Bob Subj: Proposal for Simple Media Self Describing Names From: Tom Hastings, Bob Herriot File: simple-self-describing-names-010406.doc Date: 4/6/01 This paper proposes a very simple definition for Media Self Describing Names. It meets the objectives suggested by Harry and Mark for "all-in-one" names. We think that calling these names Media Self Describing Names will make the intent more clear. We suggest that Media Self Describing Names be added to the next draft, either as a new section or an Appendix, to go along side the D0.5 Draft Media Names which are: Media Size Self Describing Names, Media Type Names, and Media Color Names. Summary of Media Self Describing Names The central idea for the Media Self Describing Name is to provide a simple naming syntax that describes all of the salient characteristics of the media. Each salient characteristic is represented as a field separated by a "." character, starting with the Media Size Self Describing Name field. Each field, except for size, has a default value, which is the most commonly used value. To shorten the names and to follow existing media naming practice, the default value is never represented in the name. For example, the name: 'na-letter.8500-11000' represents white stationery, without holes, and not recycled, etc, and the name: 'na-personal.3625-6500.envelope.bond.blue' represents a blue bond personal envelope, not recycled, etc. This syntax is compatible with the IPP keyword syntax (all lower case, plus "." and "-") and can be used with the current IPP/1.1 client and Printer implementations of "media", "media-default", "media-ready", and "media-supported" attributes. A valid Media Self Describing Name MUST include the Media Size Self Describing Name (both Size Name and Dimensions fields as defined in the D0.5 Draft) followed by other fields which MUST be in the following order: Field Example Default Value ----- ------- ------------ 1 Media Size Self Describing Name na-letter.8500-11000 -- 2 Media Type Name envelope stationery 3 Media Stock Type Name bond plain 4 Media Color Name red white 5 Media Weight Name 80-gram unspecified 6 Media Hole Count Name holes-3 holes-0 7 Media Preprinted Name letterhead none 8 Media Recycled Name recycled none 9 Media Front Coating Name front-matte none 10 Media Back Coating Name back-glossy none 11 Media Order Count Name ordered-5 ordered-1 Any field whose value is the indicated default value MUST be omitted, including the "." separator character. Implementers MAY add additional fields. They MUST occur after the fields defined in this standard. Implementers MAY add additional field values to defined fields. Note that if a given field is not supported by an implementation, omitting that field is assumed to have the meaning as the default value. Thus this specification allows implementations to support whatever additional fields they want in addition to the REQUIRED Media Size Self Describing field. Thus there is no burden on implementations in defining the following additional fields in our Media Names standard. These definitions also provide a simple one-to-one mapping to the PWG IEEE-ISTO 5100.3 Production Printing Attributes - Set1 extension. Values for each field of Media Self Describing Names This section lists the values defined for each field of a Media Self Describing Name. The order presented is the same as is REQUIRED in the name when other than the default value is being represented. Media Size Self Describing Name (see D0.5 Draft): The ABNF for the Media Size Self Describing Name is: ["na-"] size_name "." short_dim "-" long_dim Media Type Name (see D0.5 Draft): stationery -- default transparency envelope envelope-plain envelope-window continuous continuous-long continuous-short tab-stock pre-cut-tabs full-cut-tabs multi-part-form labels multi-layer screen screen-paged photographic cardstock and we've agreed to add 'roll' and drop 'other' Media Stock Type Name: none -- default bond newsprint bristol Media Color Name (see D0.5 Draft): no-color -- ISSUE - get rid of this and clarify white to mean -- clear for transparency - white is the absence of -- color white -- default pink yellow blue green buff goldenrod red gray ivory orange Media Weight Name: unspecified -- default nnn-grams The default value is 'unspecified', meaning that leaving out the weight means that the weight is unspecified. Media Hole Count Name: holes-0 -- default holes-1 holes-2 holes-3 holes-4 holes-5 Media Preprinted Name: none -- default preprinted letterhead Media Recycled Name: none -- default recycled The Media Front Coating Name: none -- default front-glossy front-high-gloss front-semi-gloss front-satin front-matte The Media Back Coating Name: none -- default back-glossy back-high-gloss back-semi-gloss back-satin back-matte Media Order Count Name: ordered-1 -- default ordered-2 ordered-3 ordered-4 ordered-5 ordered-6 Examples na-letter.8500-11000 -- white stationery, no holes, etc. In other words, the size name by itself is the white stationery media, as in IPP na-personal.3625-6500.envelope -- white envelope, no holes, not recycled, etc. na-letter.8500-11000.transparency -- clear transparency (see issue above) na-3x5.3000-5000.photographic.front-matte -- white photographic front matte na-3x5.3000-5000.cardstock.blue -- blue 3x5 card stock na-letter.8500-11000.blue -- blue stationery, no holes, etc. na-letter.8500-11000.front-glossy -- white glossy on front side na-letter.8500-11000.front-glossy.back-glossy -- white glossy both sides na-letter.8500-11000.holes-3 -- three holed white stationery na-letter.8500-11000.envelope.blue -- blue envelope na-letter.8500-11000.recycled -- recycled white stationery na-letter.8500-11000.envelope.blue.recycled -- recycled blue envelope na-letter.8500-11000.bond -- white bond stationery, no holes, etc. na-letter.8500-11000.envelope.bond -- white bond envelope, etc. na-letter.8500-11000.letterhead.bond -- white bond letterhead, etc. na-letter.8500-11000.80-gram -- 80 grams per square meter white stationery. All of the examples above this one are of an unspecified weight, while this one is 80 grams per square meter weight. <> -------------- next part -------------- A non-text attachment was scrubbed... Name: simple-self-desccribing-names-010406.doc Type: application/msword Size: 50176 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010406/72b0e57c/simple-self-desccribing-names-010406-0001.doc From hastings at cp10.es.xerox.com Fri Apr 6 18:00:28 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE6A@x-crt-es-ms1.cp10.es.xerox.com> I just got off the phone with Shivaun and the plan is still for the UPnP BasicPrint Template to use the syntax for Media Size Self Describing Names from the PWG Media Names standard and reference it for the list of values. As a formality, the UPnP IMAGING WG will vote on the change at the Portland meeting, April 23-24. The hope is that the Portland meeting makes the final changes to the BasicPrint Template, based on the plug fest experience, what various venders actually support, and the PWG Media Names standard. Therefore, I think that we should put the "all-in-one" proposal in a separate PWG document, so that the UPnP BasicPrint Template has a stable document to reference. I'd be glad to continue the discussion about the "all-in-one" document in Portland, as well as finish the Media Names Standard. Ok? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 14:16 To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, I will be able to attend the Portland meeting (UPnP, PWG, and IPP FAX), so I'll volunteer to lead the discussion and collaborate with Ron after the meeting. I agree that the "all-in-one" is the real open issue and whether it should be included in the current document or made a separate document. I think it depends on the schedule from the UPnP group and whether or not they are going to use our format. If they need something stable and approved before we can agree on the "all-in-one" naming, then we should make the all in one a separate document. About the appendix to indicate which objects and attributes of existing standards are intended to use which Names in our standard, I think it is very important to include it in the Media Names standard. So I disagree about not including it. Otherwise, it will be very difficult for implementers to know which Names we intend as extensions to which objects and attributes in these existing standards (RFC 1759, IPP, and ISTO-IEEE 5100.3). Think about the implementers that aren't even on our mailing lists.... Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:58 To: 'Manros, Carl-Uno B'; Hastings, Tom N; Bergman, Ron; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, I agree with Carl-Uno's suggestion for extending the time to finish this document. Unfortunately I cannot attend the next meeting. So we will need a volunteer to lead the discussion and capture the results. I believe that the only real open issues concern the "all-in-one" format and if it should be included in this document or as a separate standard. There is also Tom's proposal for another appendix that specifies how existing standards are to use the Media standard. I have not seen any comment on this so I assume that no one cares either positively or negatively. I personally don't believe that this is necessary and should not be included. Any one disagree? Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:42 AM To: Hastings, Tom N; 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, As a last minute comment I would like to suggest extending the time to finish this document to span the next PWG meeting. It seems to me that there is still too much discussion and too many lose ends to close and publish this document quite yet... Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:14 AM To: 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, Unfortunately, I checked the wrong delivery service on the web site when I ordered the ASME Y14.1M a week ago Friday and it is being delivered by truck from New Jersey to LA and won't arrive until next Tuesday or Wednesday. The guy who I could get the numbers over the phone when home early today, so we're out of luck. I'm on vacation next week. So maybe we add these sizes later, perhaps as a corrigendum or during last call. Tom -----Original Message----- From: Hastings, Tom N Sent: Friday, March 30, 2001 16:06 To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From hastings at cp10.es.xerox.com Fri Apr 6 22:30:56 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE89@x-crt-es-ms1.cp10.es.xerox.com> Ron, I think you are right. There is no need for the Media Name Standard to say anything about what an implementation should do if the Media Size Name (e.g., na-letter), has dimensions that don't agree with the standard. So ignore my suggestion. Thanks, Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:09 To: 'Hastings, Tom N'; ipp (E-mail) Cc: UPDF WG (E-mail) Subject: RE: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Tom, I am not sure why this is an issue. If we have defined a name in the specification with this mismatch, it must be corrected. If a name mismatch occurs in a custom name, it is up to the person that creates the custom name to ensure it is what he wanted. If you are referring to a corrupted name, then it is up to the receiver to determine the appropriate action, which should be specified by the protocol (UPnP, IPP, etc). If the device does not have a sizes table to compare, then all it can do is accept the size. If it can validate, then it should reject. I don't agree a statement is needed in the PWG Media specification for this case. Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 3:08 AM To: ipp (E-mail) Cc: UPDF WG (E-mail) Subject: UPD> MED - Minor issue: which wins if dimensions are correct for the m edia size name? Ron, Minor issue: which wins if dimensions are correct for the media size name? For example, for the Media Size Self-Describing Name is iso-a4.100-200, is the size ISO A4 or 10 by 20 mm? I suggest that the dimensions take precedence over the name. So we need to add such a statement in the document. Comments? Tom From hastings at cp10.es.xerox.com Fri Apr 6 22:34:06 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:10 2009 Subject: UPD> RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Message-ID: <918C79AB552BD211A2BD00805F15CE8504C5FE8A@x-crt-es-ms1.cp10.es.xerox.com> I don't know an exact date, but my sense is that the group wants to be finished with the UPnP BasicPrint Template at the Portland meeting. I left a message with Shivaun and did not get a reply. She is on vacation next week and will be back in the office, Monday April 16. I'm also taking a vacation next week and will be back in the office on Monday April 16. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 15:45 To: 'Hastings, Tom N'; Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org'; UPDF WG (E-mail) Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, Do you know when UPnP requires a "published" standard? Or do they just need the number to reference? I don't know why, if we ever agree on the "all-in-one", that it cannot be an appendix to the Media Standard. Just because UPnP doesn't require it, they do not have to ue everything in the standard. If we must publish the document soon, it could be a corrigendum (I must look up that word!) and then added when the Media spec is re-published (as a -2002). Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 3:00 PM To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org'; UPDF WG (E-mail) Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just got off the phone with Shivaun and the plan is still for the UPnP BasicPrint Template to use the syntax for Media Size Self Describing Names from the PWG Media Names standard and reference it for the list of values. As a formality, the UPnP IMAGING WG will vote on the change at the Portland meeting, April 23-24. The hope is that the Portland meeting makes the final changes to the BasicPrint Template, based on the plug fest experience, what various venders actually support, and the PWG Media Names standard. Therefore, I think that we should put the "all-in-one" proposal in a separate PWG document, so that the UPnP BasicPrint Template has a stable document to reference. I'd be glad to continue the discussion about the "all-in-one" document in Portland, as well as finish the Media Names Standard. Ok? Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 14:16 To: Bergman, Ron; Manros, Carl-Uno B; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, I will be able to attend the Portland meeting (UPnP, PWG, and IPP FAX), so I'll volunteer to lead the discussion and collaborate with Ron after the meeting. I agree that the "all-in-one" is the real open issue and whether it should be included in the current document or made a separate document. I think it depends on the schedule from the UPnP group and whether or not they are going to use our format. If they need something stable and approved before we can agree on the "all-in-one" naming, then we should make the all in one a separate document. About the appendix to indicate which objects and attributes of existing standards are intended to use which Names in our standard, I think it is very important to include it in the Media Names standard. So I disagree about not including it. Otherwise, it will be very difficult for implementers to know which Names we intend as extensions to which objects and attributes in these existing standards (RFC 1759, IPP, and ISTO-IEEE 5100.3). Think about the implementers that aren't even on our mailing lists.... Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Friday, April 06, 2001 11:58 To: 'Manros, Carl-Uno B'; Hastings, Tom N; Bergman, Ron; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, I agree with Carl-Uno's suggestion for extending the time to finish this document. Unfortunately I cannot attend the next meeting. So we will need a volunteer to lead the discussion and capture the results. I believe that the only real open issues concern the "all-in-one" format and if it should be included in this document or as a separate standard. There is also Tom's proposal for another appendix that specifies how existing standards are to use the Media standard. I have not seen any comment on this so I assume that no one cares either positively or negatively. I personally don't believe that this is necessary and should not be included. Any one disagree? Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:42 AM To: Hastings, Tom N; 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available All, As a last minute comment I would like to suggest extending the time to finish this document to span the next PWG meeting. It seems to me that there is still too much discussion and too many lose ends to close and publish this document quite yet... Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, April 06, 2001 11:14 AM To: 'Bergman, Ron'; 'RonBergman@aol.com' Cc: 'pwg@pwg.org'; 'ipp@pwg.org' Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Ron, Unfortunately, I checked the wrong delivery service on the web site when I ordered the ASME Y14.1M a week ago Friday and it is being delivered by truck from New Jersey to LA and won't arrive until next Tuesday or Wednesday. The guy who I could get the numbers over the phone when home early today, so we're out of luck. I'm on vacation next week. So maybe we add these sizes later, perhaps as a corrigendum or during last call. Tom -----Original Message----- From: Hastings, Tom N Sent: Friday, March 30, 2001 16:06 To: Bergman, Ron; Hastings, Tom N; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available I just ordered a copy from the ASME. It should be here next Tuesday. Tom -----Original Message----- From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com] Sent: Thursday, March 29, 2001 07:38 To: 'Hastings, Tom N'; RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: RE: IPP> RE: PWG> Media Names Standard, Version D0.5 Available Tom, I do not have access to ASME-Y14.1M, so I am unable to do this research. Do you have a copy? Ron -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Wednesday, March 28, 2001 7:14 PM To: RonBergman@aol.com Cc: pwg@pwg.org; ipp@pwg.org Subject: IPP> RE: PWG> Media Names Standard, Version D0.5 Available IPP (RFC2911) has a number of media names that include engineering sizes taken from [ASME-Y14.1M]. For some reason we only included them as media names (e.g., iso-a1x3-transparent), and not as media size names (e.g., iso-a1x3) in IPP. These size names are: iso-a1x3, iso-a1x4 iso-a2x3, iso-a2x4, iso-a2x5 iso-a3x3, iso-a3x4, iso-a3x5, iso-a3x6, iso-a3x7 iso-a4x3, iso-a4x4, iso-a4x5, iso-a4x6, iso-a4x7, iso-a4x8, iso-a4x9 Should we add them? Someone should look at [ASME-Y14.1M] and get the proper length dimensions (which aren't in IPP), to go with the width dimensions which are in IPP. Thanks, Tom -----Original Message----- From: RonBergman@aol.com [mailto:RonBergman@aol.com] Sent: Tuesday, March 27, 2001 11:48 To: pwg@pwg.org; ipp@pwg.org Subject: PWG> Media Names Standard, Version D0.5 Available The latest version is now available at: ftp://ftp.pwg.org/pub/pwg/media-sizes/pwg-media-05.pdf The major change is the merging of the envelope sizes with the other tables and the separation of the media type with the size. In addition I have added the definition of a format for custom media types and color per a request from Norbert. There are still two open issues that I am waiting for clarification from Tom. 1. Tom added a reference [REG] in section 3, but no corresponding entry in the References section. 2. The ABNF for the size name in section 5.1 may be incorrect. I am not an ABNF expert, but I believe that | "-" | "-" ) should be simply | "-" ) I will try to attend the IPP teleconference tomorrow to discuss any other issues concerning this document. Ron Bergman Hitachi Koki Imaging Solutions From don at lexmark.com Mon Apr 9 12:44:08 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Don't stop Do what is necessary Message-ID: <200104091713.NAA14862@interlock2.lexmark.com> Mark, et al: I have no problem with creating the combined name but I think this is better done in the end standard that uses these names in a combined form. There may be reasons that UPD wants a certain set of characteristics in its media names that differ from what IPP might want, or uPnP might want, etc. If this standard tries to be all things to all users then it will never be done. One of the major issues raised by the IETF with IPP was it was just too big to deal with. It is thought to be better to create a number of smaller standards that deal with a smaller set of issues and then use those smaller standards as building blocks. I think this is a perfect example where smaller and simpler is better. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Mark VanderWiele" on 04/05/2001 09:58:15 AM To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com cc: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From RonBergman at aol.com Mon Apr 9 16:26:06 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:10 2009 Subject: UPD> Fwd: FW: Media Standardized Names, Version D0.6 is now available Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: "Bergman, Ron" Subject: FW: Media Standardized Names, Version D0.6 is now available Date: Mon, 9 Apr 2001 08:02:14 -0700 Size: 1659 Url: http://www.pwg.org/archives/upd/attachments/20010409/c2775d00/attachment-0001.mht From markv at us.ibm.com Mon Apr 9 20:22:45 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Missing Locales arAA (Arabic) enBE (Belgium) enGB (Great Britain) enIN (India) shSP (Serbian Latin) shYU (Serbian Latin - Yugoslavia) srSP (Serbian Cyrillic) srYU (Serbian Cyrillic - Yugoslavia) slSI (Slovene) (the last character is uppercase "i") Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on 04/03/2001 07:08 PM --------------------------- Jim Sommer @pwg.org on 04/02/2001 08:48:04 AM Sent by: owner-upd@pwg.org To: UPDF cc: Subject: Re: UPD> open standard for locales Here's a list of locales that use the ISO language and country codes. I know it's not all encompassing since I don't what countries speak some of the languages. However, it's a good start and people should post any missing entries. I have the list sorted by code. It's not necessarily an obvious sort for English but it's probably the best to use since nothing is going to be good for everyone. Jim -------------------------------------- code - language - country afZA - Afrikaans - South Africa arAE - Arabic - United Arab Emirates arBH - Arabic - Bahrain arDZ - Arabic - Algeria arEG - Arabic - Egypt arIQ - Arabic - Iraq arJO - Arabic - Jordan arLY - Arabic - Libya arMA - Arabic - Morocco arOM - Arabic - Oman arLB - Arabic - Lebanon arKW - Arabic - Kuwait arQA - Arabic - Qatar arSA - Arabic - Saudi Arabia arSY - Arabic - Syria arTN - Arabic - Tunisia arYE - Arabic - Yemen asIN - Assamese - India azAZ - Azerbaijani - Azerbaijan beBY - Byelorussian - Belarus bgBG - Bulgarian - Bulgaria bnIN - Bengali - India caES - Catalan - Spain csCZ - Czech - Czech Republic daDK - Danish - Denmark deAT - German - Austria deCH - German - Switzerland deDE - German - Germany deLI - German - Liechtenstein deLU - German - Luxembourg dzBT - Bhutani - Bhutan elGR - Greek - Greece enAU - English - Australia enBB - English - Barbados enBM - English - Bermuda enBZ - English - Belize enCA - English - Canada enGS - English - Bahamas enIE - English - Ireland enJM - English - Jamaica enNZ - English - New Zealand enPH - English - Philippines enUK - English - United Kingdom enUS - English - United States enZA - English - South Africa enTT - English - Trinidad and Tabago enVG - English - US Virgin Islands enVI - English - British Virgin Islands enZW - English - Zimbabwe esAR - Spanish - Argentina esBO - Spanish - Bolivia esCL - Spanish - Chile esCO - Spanish - Colombia esCR - Spanish - Costa Rica esCU - Spanish - Cuba esEC - Spanish - Ecuador esES - Spanish - Spain esDO - Spanish - Dominican Republic esGT - Spanish - Guatemala esHM - Spanish - Honduras esMX - Spanish - Mexico esNI - Spanish - Nicaragua esPA - Spanish - Panama esPE - Spanish - Peru esPR - Spanish - Puerto Rico esPY - Spanish - Paraguay esSV - Spanish - El Salvador esUY - Spanish - Uruguay esVE - Spanish - Venezuela etEE - Estonian - Estonia euES - Basque - Spain faIR - Farsi - Iran fiFI - Finnish - Finland foFO - Faeroese - Faeroe Islands frBE - French - Belgium frCA - French - Canada frCH - French - Switzerland frLU - French - Luxembourg frMC - French - Monaco frFR - French - France gaIE - Irish - Ireland guIN - Gujarati - India heIL - Hebrew - Israel hiIN - Hindi - India hrHR - Croatian - Croatia huHU - Hungarian - Hungary hyAM - Armenian - Armenia idID - Indonesian - Indonesia inID - Indonesian - Indonesia isIS - Icelandic - Iceland itCH - Italian - Switzerland itIT - Italian - Italy iwIL - Hebrew - Israel jaJP - Japanese - Japan jiIL - Yiddish - Isreal kaGE - Georgian - Georgia kkKZ - Kazahk - Kazahkstan klGL - Greenlandic - Greenland kmKH - Cambodian - Cambodia knIN - Kannada - India koKP - Korean - Democratic People's Republic of Korea koKR - Korean - Republic of Korea ksIN - Kashmiri - India kuIQ - Kurdish - Iraq loLA - Laothain - Laos ltLT - Lithuanian - Lithuania lvLV - Latvian - Latvia mkMK - Macedonian - Former Yugoslav Republic of Macedonia mlIN - Malayalam - India mnMN - Mongolian - Mongolia moMD - Moldavian - Moldava mrIN - Marathi - India msBN - Malay - Brunei Darussalam msMY - Malay - Malaysia mtMT - Maltese - Malta myMM - Burmese - Myanmar neNP - Nepali - Nepal nlBE - Dutch - Belgium nlNL - Dutch - Netherlands noNO - Norwegian - Norway orIN - Oriya - India paIN - Punjabi - India plPL - Polish - Poland ptBR - Portuguese - Brazil ptPT - Portuguese - Portugal roRO - Romanian - Romania ruRU - Russian - Russia saIN - Sanskrit - India skSK - Slovak - Slovakia slSL - Slovene - Slovenia smWS - Samoan - Samoa soSO - Somali - Somalia sqAL - Albanian - Albania suSD - Sudanese - Sudan svFI - Swedish - Finland svSE - Swedish - Sweden swKE - Swahili - Kenya taIN - Tamil - India teIN - Telugu - India thTH - Thai - Thailand trTR - Turkish - Turkey ukUA - Ukrainian - Ukraine urIN - Uru - India urPK - Urdu - Pakistan uzUZ - Uzbek - Uzbekistan viVN - Vietnamese - Viet Nam yiIL - Yiddish - Isreal zhCN - Chinese - China zhHK - Chinese - Hong Kong zhMO - Chinese - Macau zhSG - Chinese - Singapore zhTW - Chinese - Taiwan -------------------------------------- From sommer at granitesystems.com Mon Apr 9 20:44:50 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: Message-ID: <4.2.0.58.20010409203512.00966810@mailbox.bellatlantic.net> I have enUK in the list but it should be enGB. I have slSL in the list but it should be slSI (lower case ell and upper case eye). The language sh is listed as Serbo-Croatian and sr is listed Serbian. I couldn't find the countries AA and SP in the ISO country code list. Jim At 4/9/01 08:22 PM, Mark VanderWiele wrote: >Missing Locales > > >arAA (Arabic) >enBE (Belgium) >enGB (Great Britain) >enIN (India) >shSP (Serbian Latin) >shYU (Serbian Latin - Yugoslavia) >srSP (Serbian Cyrillic) >srYU (Serbian Cyrillic - Yugoslavia) >slSI (Slovene) (the last character is uppercase "i") > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From harryl at us.ibm.com Tue Apr 10 07:20:53 2001 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:10 2009 Subject: IPP> Re: UPD> Don't stop Do what is necessary Message-ID: I agree it might be more flexible and serve better in multiple protocols or environments if we avoid specifying one fixed form of concatenation. I think Mark's point, which I have heard him making for over a year, now, in UPDF and IPP meetings is that a client does need all this information in order for any of it to be effective. I think we should head this "warning". ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- don@lexmark.com Sent by: owner-ipp@pwg.org 04/09/2001 10:44 AM To: "Mark VanderWiele" cc: ipp@pwg.org, upd@pwg.org Subject: IPP> Re: UPD> Don't stop Do what is necessary Mark, et al: I have no problem with creating the combined name but I think this is better done in the end standard that uses these names in a combined form. There may be reasons that UPD wants a certain set of characteristics in its media names that differ from what IPP might want, or uPnP might want, etc. If this standard tries to be all things to all users then it will never be done. One of the major issues raised by the IETF with IPP was it was just too big to deal with. It is thought to be better to create a number of smaller standards that deal with a smaller set of issues and then use those smaller standards as building blocks. I think this is a perfect example where smaller and simpler is better. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-232-4808 (phone) 859-232-6740 (fax) * ********************************************** "Mark VanderWiele" on 04/05/2001 09:58:15 AM To: "Don_Wright/Lex/Lexmark.LEXMARK"@sweeper.lex.lexmark.com cc: ipp%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Don't stop Do what is necessary Don: If you want to create a simple unusable standard than do it. Reality is that media description and selection only makes sense if you have all the information presented in a logical single description (including location). Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Tue Apr 10 14:31:32 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:10 2009 Subject: UPD> XML syntax Message-ID: <001001c0c1ec$773e5430$551414ac@hsg.ma.oaktech.com> I'm looking out for help today while trying to write some proper XML for what I want to implement. My intention: Let think about media types. It's quite easy to provide a list of predefined keywords to let the developer choose from allowed values only. That's an attribute with an enumerated list. But it's getting complicated when I want to allow him to choose from the list or enter his own name for a custom media type. So I was dreaming of something like an editable combo box. Does not seem to be possible with XML. What about workarounds? Who was facing that kind of problem already and developed some syntax for it? Or knows somebody who did or may know? A simple solution could be to add a keyword 'custom' to the list of predefined ones and adding another attribute, which then holds the custom string. Feels like a hack to me. In that case I'd expect a rule like 'show the custom string only when keyword custom is chosen in the predefined list'. Don't know that syntax either by heart. Help??? Norbert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010410/1bb58f91/attachment-0001.html From mike at easysw.com Tue Apr 10 15:56:14 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded References: <918C79AB552BD211A2BD00805F15CE8504C5FD1F@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AD3655E.90818BC2@easysw.com> [Agreement coming late, since I was off enjoying a bit of vacation time... :)] "Hastings, Tom N" wrote: > ... > A Printer that supports a minimum custom size of, say, 3 inches > by 5 inches, and a maximum of, say, 8.5 inches by 14, would have > the following two values: > > na-custom-max.8500-1400 > na-custom-min.300-500 > > Any disagreements? > > I also believe that this meets Michael's needs for custom sizes, > whether for the 'roll' Media Type or any of the other Media Type > values. > ... Yes... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Apr 10 16:03:08 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: min and max size and the creeping scope of the media standard[new subject] References: <3BC1BD0C7E6DD411A13200508BDCC83D27BE86@triton.hitachi-hkis.com> Message-ID: <3AD366FC.CFCC4339@easysw.com> "Bergman, Ron" wrote: > ... > separator in the size name. So your example would be: > > stationery/na-letter.8500-11000/white/none > > Or, would a different character be better? > ... The "media-col" attribute (and associated collection syntax) can be used with the "standard" names defined here. Trying to shoehorn everything into the media attribute just won't work, and as much as I hate collections they seem to be the best solution to this particular problem. So, I would recommend to *not* add this kind of a proposal to the current spec - it is WAY out of scope and would apparently duplicate the work done for media-col without properly representing other media attributes (weight, etc.) that may be needed... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From mike at easysw.com Tue Apr 10 16:24:14 2001 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:10 2009 Subject: UPD> Re: IPP> MED - Proposal for simple Media Self Describing Names (all in onenames) References: <918C79AB552BD211A2BD00805F15CE8504C5FE5B@x-crt-es-ms1.cp10.es.xerox.com> Message-ID: <3AD36BEE.C983D0A9@easysw.com> "Hastings, Tom N" wrote: > ... > A valid Media Self Describing Name MUST include the Media Size Self > Describing Name (both Size Name and Dimensions fields as defined in > the D0.5 Draft) followed by other fields which MUST be in the > following order: > ... What about a media with a glossy back finish but a matte front finish? Do you then explicitly include the "matte" for the front finish? Also, this requires the parser to know what keywords go with what attribute - that is, "matte" is a finish attribute, and "bond" is a media type name, "80-gram" is a media weight, etc... If we are going to make this a "standard", then we probably want to require any intervening names to be included, for example: na-letter.8500-11000.red should be: na-letter.8500-11000.stationary.plain.red or: na-letter.8500-11000...red with any unspecified fields *after* the last one set to the default (or matching any value) This is one of the reasons I think we should not try to add all-in-one names to the spec, but should use the existing mechanisms (e.g. for IPP the "media-col" attribute) and just standardize the naming of the values. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From don at lexmark.com Wed Apr 11 11:27:40 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: <200104111527.LAA12470@interlock2.lexmark.com> For some reason I thought both enUK and enGB were valid. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** Jim Sommer on 04/09/2001 08:44:50 PM To: "Mark VanderWiele" , owner-upd%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: Re: UPD> Re: UPDF open standard for locales I have enUK in the list but it should be enGB. I have slSL in the list but it should be slSI (lower case ell and upper case eye). The language sh is listed as Serbo-Croatian and sr is listed Serbian. I couldn't find the countries AA and SP in the ISO country code list. Jim At 4/9/01 08:22 PM, Mark VanderWiele wrote: >Missing Locales > > >arAA (Arabic) >enBE (Belgium) >enGB (Great Britain) >enIN (India) >shSP (Serbian Latin) >shYU (Serbian Latin - Yugoslavia) >srSP (Serbian Cyrillic) >srYU (Serbian Cyrillic - Yugoslavia) >slSI (Slovene) (the last character is uppercase "i") > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From norbertschade at oaktech.com Wed Apr 11 11:40:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales References: <200104111527.LAA12470@interlock2.lexmark.com> Message-ID: <001201c0c29d$b8c1b350$551414ac@hsg.ma.oaktech.com> Bad situation. We should be unique. Looking at the Unicode weg pages I tend to use enGB. I also stay with the Unicode language keywords for Serbo-Croation and Serbian. I'm waiting for some details from Mark to finish it up like what countries are AA and SP. He seems to have a slightly different source. Norbert Schade ----- Original Message ----- From: To: "Jim Sommer" Cc: "Mark VanderWiele" ; ; Sent: Wednesday, April 11, 2001 11:27 AM Subject: Re: UPD> Re: UPDF open standard for locales > > > For some reason I thought both enUK and enGB were valid. > > ********************************************** > * Don Wright don@lexmark.com * > * Chair, Printer Working Group * > * Chair, IEEE MSC * > * * > * Director, Alliances & Standards * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 859-825-4808 (phone) 603-963-8352 (fax) * > ********************************************** > > > > Jim Sommer on 04/09/2001 > 08:44:50 PM > > To: "Mark VanderWiele" , > owner-upd%pwg.org@interlock.lexmark.com, upd%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: Re: UPD> Re: UPDF open standard for locales > > > > I have enUK in the list but it should be enGB. > > I have slSL in the list but it should be slSI (lower case ell and upper > case eye). > > The language sh is listed as Serbo-Croatian and sr is listed Serbian. > > I couldn't find the countries AA and SP in the ISO country code list. > > Jim > > > At 4/9/01 08:22 PM, Mark VanderWiele wrote: > > >Missing Locales > > > > > >arAA (Arabic) > >enBE (Belgium) > >enGB (Great Britain) > >enIN (India) > >shSP (Serbian Latin) > >shYU (Serbian Latin - Yugoslavia) > >srSP (Serbian Cyrillic) > >srYU (Serbian Cyrillic - Yugoslavia) > >slSI (Slovene) (the last character is uppercase "i") > > > >Regards, > >Mark VanderWiele > >IBM, Linux Technology Center > >512-838-4779, t/l 678 > >MARKV@IBMUS > >email: markv@us.ibm.com > > > > > > From sommer at granitesystems.com Wed Apr 11 11:55:00 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: <001201c0c29d$b8c1b350$551414ac@hsg.ma.oaktech.com> References: <200104111527.LAA12470@interlock2.lexmark.com> Message-ID: <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> I haven't seen any standard that has UK in it so I say use GB. AA and SP are IBM internal designation for all Arabic countries and Serbia (see email attached below). If you look at http://www.niso.org/3166.html#serbia you'll see the Serbia question addressed. So, I don't think these need to be added. Jim ---------- Subject: Re: UPDF open standard for locales To: sommer@granitesystems.com Cc: "Mark VanderWiele" From: "Mary Trumble" Date: Tue, 10 Apr 2001 19:14:07 -0400 Message-ID: "SP" is the abbreviation that IBM uses for Serbia. It's appropriate to call it a "territory", in the POSIX-locale sense, but, politically-speaking, there may be a difference of opinion about whether it's a country. "AA" is the IBM generic designation for "Arabic-speaking countries". If you're including only (and all) countries you don't need this. Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/5be92d05/attachment-0001.html From norbertschade at oaktech.com Wed Apr 11 12:11:35 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales References: <200104111527.LAA12470@interlock2.lexmark.com> <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> Message-ID: <005e01c0c2a2$14feb060$551414ac@hsg.ma.oaktech.com> Based on the latest comments this is my proposal: Add enBE, enIN, shYU, srYU. Change enUK to enGB. Do not add arAA, shSP, srSP, as they are not based on the Unicode standard. Does that work for everybody? Regards Norbert Schade ----- Original Message ----- From: Jim Sommer To: Norbert Schade ; UPD group Sent: Wednesday, April 11, 2001 11:55 AM Subject: Re: UPD> Re: UPDF open standard for locales I haven't seen any standard that has UK in it so I say use GB. AA and SP are IBM internal designation for all Arabic countries and Serbia (see email attached below). If you look at http://www.niso.org/3166.html#serbia you'll see the Serbia question addressed. So, I don't think these need to be added. Jim ------------------------------------------------------------------------------ Subject: Re: UPDF open standard for locales To: sommer@granitesystems.com Cc: "Mark VanderWiele" From: "Mary Trumble" Date: Tue, 10 Apr 2001 19:14:07 -0400 Message-ID: "SP" is the abbreviation that IBM uses for Serbia. It's appropriate to call it a "territory", in the POSIX-locale sense, but, politically-speaking, there may be a difference of opinion about whether it's a country. "AA" is the IBM generic designation for "Arabic-speaking countries". If you're including only (and all) countries you don't need this. Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/ecef067b/attachment-0001.html From sommer at granitesystems.com Wed Apr 11 13:05:03 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: <005e01c0c2a2$14feb060$551414ac@hsg.ma.oaktech.com> References: <200104111527.LAA12470@interlock2.lexmark.com> <4.2.0.58.20010411114256.0095f150@mailbox.bellatlantic.net> Message-ID: <4.2.0.58.20010411130323.009552a0@mailbox.bellatlantic.net> In addition, slSL should be changed to slSI. Jim At 4/11/01 12:11 PM, Norbert Schade wrote: >Based on the latest comments this is my proposal: >Add enBE, enIN, shYU, srYU. >Change enUK to enGB. >Do not add arAA, shSP, srSP, as they are not based on the Unicode standard. > >Does that work for everybody? >Regards >Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010411/025d655b/attachment-0001.html From norbertschade at oaktech.com Wed Apr 11 13:07:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> all-in-one media handling Message-ID: <007801c0c2a9$d5567ad0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010411/3061a13e/NorbertSchade-0001.vcf From RonBergman at aol.com Wed Apr 11 16:32:46 2001 From: RonBergman at aol.com (RonBergman@aol.com) Date: Wed May 6 14:05:11 2009 Subject: UPD> Media Names Spec Discussion Message-ID: <17.145fdfa3.2806196e@aol.com> We have been getting complaints regarding the multiple postings regarding this subject. Some members only see a single message (such as myself) and others see all. So I am requesting that all future messages on this subject be sent only to the ipp mail list. Also, there have been several requests for new names to be added to the document without any real definition of the name. (For example, requesting the name "foobar" with the definition "this is a foobar type", is not adequate.) If you would like me to add a definition, I will guarantee that it will not be what you expect. So, please provide a definition or no further consideration will be given to the request. Ron Bergman Hitachi Koki Imaging Solutions From norbertschade at mediaone.net Sat Apr 14 17:00:04 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> minimum hardware margins Message-ID: <000c01c0c525$e18dc3c0$f2755b18@ne.mediaone.net> Within UPDF we were working with absolute units of mm/1000 in a number of cases like everything, which had to do with media handling. We commit to implement the new spec for global media handling (Ron's spec) from now on. We want to indicate our full support of this spec in our concept. Current implementations within our protocol will already be based on draft 0.6. We expect the syntax not to be changed drastically any more! We don't have problems with adding or removing some keywords within the well defined lists. But this has to be finished soon (within April) not to let us slip out of our own schedules. As we are finishing our implementation of our mother sample followed directly by a number of sample implementations based on that mother, we are in a critical process. The spec specifies two special values outside the list of keywords used in the lists, which are used for minimum and maximum media sizes. We will use that same syntax for one additional case to let a driver use the same routines all over the place. We leave it to the global media handling spec, where it adds these keywords (as side notes or recommendations) or not. The proposals for the new keywords within UPDF are na-margin-min-left.250 na-margin-min-right.250 na-margin-min-top.250 na-margin-min-bottom.250 Syntax should look familiar to you. 'na' is optional like in definitions for media size. It generally follows the rules of the spec. In this sample the minimum margins are a quarter of an inch. Confirmation requested within the UPDF group. Comment from IPP group and the spec owners appreciated. We may use this syntax, if needed in other places, as well to provide a consistent concept. Thanks to the very good work of Ron Bergman, Tom Hasting and others. Regards Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010414/d1a3e39a/attachment-0001.html From norbertschade at mediaone.net Sat Apr 14 17:43:29 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> DTD editing Message-ID: <000d01c0c52b$f1de09a0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7232 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010414/3450aabc/UPDFPrintMediaHandling-0001.obj From norbertschade at oaktech.com Mon Apr 16 11:10:02 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> telecon Message-ID: <001401c0c687$4fdc0dc0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/49408d43/NorbertSchade-0001.vcf From hastings at cp10.es.xerox.com Mon Apr 16 12:33:37 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:11 2009 Subject: UPD> telecon [media, color, and raster graphics] Message-ID: <918C79AB552BD211A2BD00805F15CE8504C600CF@x-crt-es-ms1.cp10.es.xerox.com> Norbert, It wasn't clear to me whether or not you were going to attempt to cover color and raster graphics at this Friday's telecon? Your expression: "On the other hand print media handling is almost done. So there will be little room for other things" could be interpreted either (1) that we will be spending most of the time reviewing the media handling and so there will be "little room for color and raster graphics", or (2) the media is all done, so there will be some time for other things. We have some color experts at Xerox who might be helpful, if you were going to cover that subject. I don't think they are interested in the media part though. So it would be helpful to have time allocations in the agenda for the telecon, so that people could call in when the subject of interest was being discussed. I would be glad to call in for the media part (and stay in for the color and raster graphics, though I am not an expert, if that is also covered). Color and raster graphics are a topic, so it might be more prudent to have the color and raster graphics on a separate telecon and have this Friday's telecon focus on finishing the media topic. What do you think? Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Monday, April 16, 2001 08:10 To: UPD group Subject: UPD> telecon Remember the Tampa meeting notes? Excerpt: Tele conferences We will have a small number of telecons. The first is proposed to be April, 20th, at noon EST. Please indicate your availability in the week before. I will provide an agenda for that one. Sample topics will be color and raster graphics. Depending on progress there are one or two more planned before Toronto. Who will be in? Depending on the participants I will prepare an agenda. I've finished a larger section over the week-end while implementing the global media spec into UPDF. This now gives us the chance to do some cleanup. I still do not have the time - and do not feel to be a color expert on the required level - to do that implementation. This is getting critical. I haven't yet found the time to further specify raster graphics either. On the other hand print media handling is almost done. So there will be little room for other things. Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010416/2e45a8ab/attachment-0001.html From norbertschade at oaktech.com Mon Apr 16 13:19:38 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Fw: telecon Message-ID: <004701c0c699$6aa24810$551414ac@hsg.ma.oaktech.com> Should have been more careful. > I haven't yet found the time to further specify raster graphics either. On the other hand print media handling is almost > done. So there will be little room for other things. That means: Yes, we will have room for other things. I want to come to a consensus for most of the media handling this week and then move on to other things. The feedback today make already clear that there is interest in doing the telecon. Hereby decided. I want to wait for more notes from people going to attend, before I distribute an agenda on Wednesday. Recommendation: Have your dtd and XML editor running during the telecon. You don't need to edit, but it's easier talking. Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010416/e9323e0a/attachment-0001.html From norbertschade at oaktech.com Mon Apr 16 15:58:04 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Message-ID: <005601c0c6af$8c7c32a0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/af7c4348/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Apr 16 15:58:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Message-ID: <006201c0c6af$99d4a400$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/6e8b772d/NorbertSchade-0001.vcf From norbertschade at mediaone.net Mon Apr 16 21:27:08 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> global media handling implemented Message-ID: <000d01c0c6dd$854f1b40$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7615 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFCommandSequences-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 21423 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 13432 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 870 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1814 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale-deDE-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 2894 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFLocale-enUS-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2614 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDFCommandSequences-HPLaserJetPCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010416/5efb3a9b/UPDF-0001.obj From norbertschade at mediaone.net Tue Apr 17 21:43:35 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> tonight's changes Message-ID: <001701c0c7a8$fbb2b500$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 19320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 13540 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 3319 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFLocale-enUS-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 7819 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 22320 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010417/d4483fe1/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml From norbertschade at oaktech.com Wed Apr 18 13:58:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> telecon Friday, April 20th, noon EST Message-ID: <003501c0c831$2774e9a0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010418/89fa9870/NorbertSchade-0001.vcf From markv at us.ibm.com Wed Apr 18 20:07:12 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Norbert: I will try to get the following information into the desired format. However, I wanted to let you know that the Linux globaization work is tackling the same problem and has another locals list. They have identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in your list of locals. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on 04/18/2001 06:33 PM --------------------------- Akio Kido@IBMJP 04/16/2001 09:13 PM To: Mark VanderWiele/Austin/IBM@IBMUS cc: George Kraft/Austin/IBM@IBMUS From: Akio Kido/Japan/IBM@IBMJP Subject: Re: UPDF open standard for locales (Document link: Mark VanderWiele) Hi, Mark. Sorry for my delaied response. ( I was on business trip on last week and restricted access to IBM network ). Annex B of LI18NUX2000 Globalization specification specified the list of locales that should be supported by LI18NUX2000 confomant distribution. Please refer to http://www.li18nux.org/li18nux2k/ As far as I checked the LI18NUX2000, the following locales are in the LI18NUX2000 but not in the list attached. arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, gvGB, knIN, kwGB, psIN, ruUA, sdIN, shYU, srYU. Best regards, Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) 1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 To: Akio Kido/Japan/IBM@IBMJP cc: George Kraft/Austin/IBM@IBMUS From: Mark VanderWiele/Austin/IBM@IBMUS Subject: Re: UPDF open standard for locales Kido-san: The following list all the way at the bottom of this note is a proposed list to identify translations in the Universal Printer Driver Format standard being worked on by the Printer Working Group (www.pwg.org). Please verify its completeness, Forward to other IBM interested parties, & and or propose a better source. I am told you may be working on an I18N standard for locals. Is this true? Is there another list I should be looking at? Thank you, Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com From norbertschade at oaktech.com Thu Apr 19 08:56:41 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales References: Message-ID: <000d01c0c8d0$2e2f04c0$551414ac@hsg.ma.oaktech.com> Mark, I have no problem adding new triples of locale-language-country to our list, as long as the abbreviations, languages and countries are coming from the ISO lists. I'm open to any new combination. How to do it best? Can you provide the new lines with the proper syntax, when you got that final, and I just add it? Regards Norbert ----- Original Message ----- From: "Mark VanderWiele" To: ; Sent: Wednesday, April 18, 2001 8:07 PM Subject: UPD> Re: UPDF open standard for locales > Norbert: I will try to get the following information into the desired > format. However, I wanted to let you know that the Linux globaization work > is tackling the same problem and has another locals list. They have > identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, > esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in > your list of locals. > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678 > MARKV@IBMUS > email: markv@us.ibm.com > ---------------------- Forwarded by Mark VanderWiele/Austin/IBM on > 04/18/2001 06:33 PM --------------------------- > > Akio Kido@IBMJP > 04/16/2001 09:13 PM > > To: Mark VanderWiele/Austin/IBM@IBMUS > cc: George Kraft/Austin/IBM@IBMUS > From: Akio Kido/Japan/IBM@IBMJP > Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > > Hi, Mark. Sorry for my delaied response. ( I was on business trip on last > week and restricted access to IBM network ). > > Annex B of LI18NUX2000 Globalization specification specified the list of > locales that should be supported by > LI18NUX2000 confomant distribution. Please refer to > http://www.li18nux.org/li18nux2k/ > > As far as I checked the LI18NUX2000, the following locales are in the > LI18NUX2000 but not in the list > attached. > > arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, > gvGB, knIN, > kwGB, psIN, ruUA, sdIN, shYU, srYU. > > Best regards, > Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) > 1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) > E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > > From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > > To: Akio Kido/Japan/IBM@IBMJP > cc: George Kraft/Austin/IBM@IBMUS > From: Mark VanderWiele/Austin/IBM@IBMUS > Subject: Re: UPDF open standard for locales > > > > Kido-san: The following list all the way at the bottom of this note is a > proposed list to identify translations in the Universal Printer Driver > Format standard being worked on by the Printer Working Group (www.pwg.org). > Please verify its completeness, Forward to other IBM interested parties, & > and or propose a better source. I am told you may be working on an I18N > standard for locals. Is this true? Is there another list I should be > looking at? > > Thank you, > > Regards, > Mark VanderWiele > IBM, Linux Technology Center > 512-838-4779, t/l 678 > MARKV@IBMUS > email: markv@us.ibm.com > From sommer at granitesystems.com Thu Apr 19 09:05:53 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales In-Reply-To: Message-ID: <4.2.0.58.20010419082535.0095fe50@mailbox.bellatlantic.net> Here's the translation of the locales that Mark listed: arIN-Arabic-India arSD-Arabic-Sudan deBE-German-Belgium enBE-English-Belgium enBW-English-Botswana enHK-English-Hong_Kong enIN-English-India enSG-English-Singapore enZW-English-Zimbabwe esGT-Spanish-Guatemala (this was in the original list) esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original list) faIN-Farsi-India glES-Galician-Spain (from the Linux web site, not Mark's list) gvGB-Manx_Gaelic-United_Kingdon knIN-Kannada-India (this was in the original list) kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) psIN-Pashto-India ruUA-Russian-Ukraine sdIN-Sindhi-India shYU-Serbo-Croatian-Yugoslavia srYU-Serbian-Yugoslavia I couldn't find the country SU but looking at the Linux web site, I figured it was a typo and supposed to be SD. enZA was in the original list but from the Linux web site I found that enZW was missing. I couldn't find the language fs but found that faIN was missing. I don't think we should include kwGB since Cornish isn't in the ISO language list. Jim At 4/18/01 08:07 PM, Mark VanderWiele wrote: >Norbert: I will try to get the following information into the desired >format. However, I wanted to let you know that the Linux globaization work >is tackling the same problem and has another locals list. They have >identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >your list of locals. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com >---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >04/18/2001 06:33 PM --------------------------- > >Akio Kido@IBMJP >04/16/2001 09:13 PM > >To: Mark VanderWiele/Austin/IBM@IBMUS >cc: George Kraft/Austin/IBM@IBMUS >From: Akio Kido/Japan/IBM@IBMJP >Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > >Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >week and restricted access to IBM network ). > >Annex B of LI18NUX2000 Globalization specification specified the list of >locales that should be supported by >LI18NUX2000 confomant distribution. Please refer to >http://www.li18nux.org/li18nux2k/ > >As far as I checked the LI18NUX2000, the following locales are in the >LI18NUX2000 but not in the list >attached. > >arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >gvGB, knIN, >kwGB, psIN, ruUA, sdIN, shYU, srYU. > >Best regards, >Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > >From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > >To: Akio Kido/Japan/IBM@IBMJP >cc: George Kraft/Austin/IBM@IBMUS >From: Mark VanderWiele/Austin/IBM@IBMUS >Subject: Re: UPDF open standard for locales > > > >Kido-san: The following list all the way at the bottom of this note is a >proposed list to identify translations in the Universal Printer Driver >Format standard being worked on by the Printer Working Group (www.pwg.org). >Please verify its completeness, Forward to other IBM interested parties, & >and or propose a better source. I am told you may be working on an I18N >standard for locals. Is this true? Is there another list I should be >looking at? > >Thank you, > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From markv at us.ibm.com Thu Apr 19 14:57:36 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:11 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: Akio: What should we do about kw its not in the ISO languages? Also, was SU really SD. see info below. Jim: Thank You. Regards, Mark VanderWiele IBM, Linux Technology Center 512-838-4779, t/l 678 MARKV@IBMUS email: markv@us.ibm.com Jim Sommer on 04/19/2001 08:05:53 AM To: Mark VanderWiele/Austin/IBM@IBMUS, norbertschade@oaktech.com, cc: Subject: Re: UPD> Re: UPDF open standard for locales Here's the translation of the locales that Mark listed: arIN-Arabic-India arSD-Arabic-Sudan deBE-German-Belgium enBE-English-Belgium enBW-English-Botswana enHK-English-Hong_Kong enIN-English-India enSG-English-Singapore enZW-English-Zimbabwe esGT-Spanish-Guatemala (this was in the original list) esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original list) faIN-Farsi-India glES-Galician-Spain (from the Linux web site, not Mark's list) gvGB-Manx_Gaelic-United_Kingdon knIN-Kannada-India (this was in the original list) kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) psIN-Pashto-India ruUA-Russian-Ukraine sdIN-Sindhi-India shYU-Serbo-Croatian-Yugoslavia srYU-Serbian-Yugoslavia I couldn't find the country SU but looking at the Linux web site, I figured it was a typo and supposed to be SD. enZA was in the original list but from the Linux web site I found that enZW was missing. I couldn't find the language fs but found that faIN was missing. I don't think we should include kwGB since Cornish isn't in the ISO language list. Jim At 4/18/01 08:07 PM, Mark VanderWiele wrote: >Norbert: I will try to get the following information into the desired >format. However, I wanted to let you know that the Linux globaization work >is tackling the same problem and has another locals list. They have >identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >your list of locals. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com >---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >04/18/2001 06:33 PM --------------------------- > >Akio Kido@IBMJP >04/16/2001 09:13 PM > >To: Mark VanderWiele/Austin/IBM@IBMUS >cc: George Kraft/Austin/IBM@IBMUS >From: Akio Kido/Japan/IBM@IBMJP >Subject: Re: UPDF open standard for locales (Document link: Mark > VanderWiele) > >Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >week and restricted access to IBM network ). > >Annex B of LI18NUX2000 Globalization specification specified the list of >locales that should be supported by >LI18NUX2000 confomant distribution. Please refer to >http://www.li18nux.org/li18nux2k/ > >As far as I checked the LI18NUX2000, the following locales are in the >LI18NUX2000 but not in the list >attached. > >arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >gvGB, knIN, >kwGB, psIN, ruUA, sdIN, shYU, srYU. > >Best regards, >Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 > > >From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 > >To: Akio Kido/Japan/IBM@IBMJP >cc: George Kraft/Austin/IBM@IBMUS >From: Mark VanderWiele/Austin/IBM@IBMUS >Subject: Re: UPDF open standard for locales > > > >Kido-san: The following list all the way at the bottom of this note is a >proposed list to identify translations in the Universal Printer Driver >Format standard being worked on by the Printer Working Group (www.pwg.org). >Please verify its completeness, Forward to other IBM interested parties, & >and or propose a better source. I am told you may be working on an I18N >standard for locals. Is this true? Is there another list I should be >looking at? > >Thank you, > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com From norbertschade at mediaone.net Mon Apr 23 08:00:08 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> new files Message-ID: <000d01c0cbec$f187c0a0$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 10742 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 14400 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 8150.xml Type: text/xml Size: 917 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDFDeviceConfiguration-HPLaserJet8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 14089 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/757717ff/UPDF-0001.obj From norbertschade at mediaone.net Mon Apr 23 09:06:10 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> wrong file Message-ID: <002001c0cbf6$2b21c280$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 15785 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/3096d71b/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml From norbertschade at oaktech.com Mon Apr 23 10:43:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> telecon last Friday Message-ID: <004c01c0cc03$bdf91600$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/2397446a/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Apr 23 11:13:31 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> comments on newest editings Message-ID: <005f01c0cc07$f56a84d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/2f62eef4/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Apr 23 16:15:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> short cuts Message-ID: <001401c0cc32$242cc9c0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010423/289a00a8/NorbertSchade-0001.vcf From norbertschade at oaktech.com Tue Apr 24 09:39:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:11 2009 Subject: UPD> UPDF update on web site Message-ID: <001b01c0ccc3$f9158500$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010424/4d2286e1/NorbertSchade-0001.vcf From Jim.Lo at Sun.COM Wed Apr 25 19:31:14 2001 From: Jim.Lo at Sun.COM (Jim Lo) Date: Wed May 6 14:05:12 2009 Subject: UPD> Re: UPDF open standard for locales Message-ID: <200104252331.QAA12372@mpk07.Eng.Sun.COM> Hi, Given a database about which popular ISO-639 languages are spoken in those ISO-3166 countries, attached (Locales.jimlo.txt) for your reference please find the following two tables automatically generated by the attached program (LocaleLang.java): Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) The format of the table 2 is intentionally conforming to that used in the http://www.li18nux.org/li18nux2k/ for the ease of comparison. There are 438 predefined locales (compared to 130 in li18nux2k) as a result of simply a real-life country/language combination. Hope it helps. rgds, Jim Lo Internet Appliance Group Sun Microsystems, Inc. ............................. Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) 1: Andorra (AD: fr es) French Spanish 2: United Arab Emirates (AE: ar en) Arabic English 3: Afghanistan (AF: ps) Pashto (Pushto) 4: AG (AG: en) English 5: Anguilla (AI: rn) Kirundi 6: Albania (AL: sq) Albanian 7: Armenia (AM: hy ru) Armenian Russian 8: Netherlands Antilles (AN: nl en) Dutch English 9: Angola (AO: pt) Portuguese 10: AQ (AQ:) 11: Argentina (AR: es) Spanish 12: AS (AS: en sm) English Samoan 13: Austria (AT: de) German 14: Australia (AU: en) English 15: Aruba (AW: nl en) Dutch English 16: Azerbaijan (AZ: az hy ru) Azerbaijani Armenian Russian 17: Bosnia and Herzegovina (BA: sr sh hr sl mk sq) Serbian Serbo-Croatian Croatian Slovenian Macedonian Albanian 18: Barbados (BB: en) English 19: Bangladesh (BD: bn hi bh en) Bengali Hindi Bihari English 20: Belgium (BE: fr nl de) French Dutch German 21: Burkina Faso (BF: fr) French 22: Bulgaria (BG: bg tr) Bulgarian Turkish 23: Bahrain (BH: ar en) Arabic English 24: Burundi (BI: rn fr sw) Kirundi French Swahili 25: Benin (BJ: fr) French 26: Bermuda (BM: en) English 27: Brunei (BN: ms en zh) Malay English Chinese 28: Bolivia (BO: es ay qu) Spanish Aymara Quechua 29: Brazil (BR: pt) Portuguese 30: Bahamas (BS: en) English 31: Bhutan (BT: dz en ne) Bhutani English Nepali 32: BV (BV: no) Norwegian 33: Botswana (BW: en tn) English Setswana 34: Belarus (BY: be ru) Byelorussian Russian 35: Belize (BZ: en es) English Spanish 36: Canada (CA: en fr) English French 37: CC (CC: en) English 38: Central African Republic (CF: fr sg) French Sangho 39: Congo (CG: fr) French 40: Switzerland (CH: fr de it rm) French German Italian Rhaeto-Romance 41: C?te d'Ivoire (CI: fr) French 42: CK (CK: mi en) Maori English 43: Chile (CL: es) Spanish 44: Cameroon (CM: en fr) English French 45: China (CN: zh bo) Chinese Tibetan 46: Colombia (CO: es) Spanish 47: Costa Rica (CR: es) Spanish 48: Cuba (CU: es) Spanish 49: Cape Verde (CV: pt) Portuguese 50: CX (CX: en) English 51: Cyprus (CY: el tr en) Greek Turkish English 52: Czech Republic (CZ: cs sk) Czech Slovak 53: Germany (DE: de) German 54: Djibouti (DJ: ar fr so) Arabic French Somali 55: Denmark (DK: da) Danish 56: Dominica (DM: en fr) English French 57: Dominican Republic (DO: es) Spanish 58: Algeria (DZ: ar fr) Arabic French 59: Ecuador (EC: es qu) Spanish Quechua 60: Estonia (EE: et ru) Estonian Russian 61: Egypt (EG: ar en fr) Arabic English French 62: Western Sahara (EH: ar fr it) Arabic French Italian 63: Eritrea (ER: am ti ar en it) Amharic Tigrinya Arabic English Italian 64: Spain (ES: es eu ca gl) Spanish Basque Catalan Galician 65: Ethiopia (ET: am ar en) Amharic Arabic English 66: Finland (FI: fi sv) Finnish Swedish 67: Fiji (FJ: en fj hi) English Fiji Hindi 68: FK (FK: en) English 69: Micronesia (FM: en) English 70: FO (FO: fo da) Faroese Danish 71: France (FR: fr eu br co) French Basque Breton Corsican 72: FX (FX: fr) French 73: Gabon (GA: fr) French 74: United Kingdom (GB: en gd cy) English Scots Gaelic Welsh 75: GD (GD: en fr) English French 76: Georgia (GE: ka hy ru) Georgian Armenian Russian 77: French Guiana (GF: fr) French 78: Ghana (GH: en) English 79: GI (GI: en es) English Spanish 80: GL (GL: da ik kl) Danish Inupiak Greenlandic 81: Gambia (GM: en wo) English Wolof 82: Guinea (GN: fr) French 83: Guadeloupe (GP: fr en) French English 84: Equatorial Guinea (GQ: es) Spanish 85: Greece (GR: el) Greek 86: GS (GS:) 87: Guatemala (GT: es) Spanish 88: GU (GU: en) English 89: Guinea-Bissau (GW: pt) Portuguese 90: Guyana (GY: en hi ur) English Hindi Urdu 91: Hong Kong (HK: zh en) Chinese English 92: HM (HM:) 93: Honduras (HN: es) Spanish 94: Croatia (HR: hr) Croatian 95: Haiti (HT: fr) French 96: Hungary (HU: hu) Hungarian 97: Indonesia (ID: in en nl) Indonesian English Dutch 98: Ireland (IE: en ga) English Irish 99: Israel (IL: iw ar ji) Hebrew Arabic Yiddish 100: India (IN: hi en gu kn ks ml mr ne or pa sa ta te) Hindi English Gujarati Kannada Kashmiri Malayalam Marathi Nepali Oriya Punjabi Sanskrit Tamil Telugu 101: IO (IO: en) English 102: Iraq (IQ: ar ku tk) Arabic Kurdish Turkmen 103: Iran (IR: fa ar ku) Persian Arabic Kurdish 104: Iceland (IS: is) Icelandic 105: Italy (IT: it fr de) Italian French German 106: Jamaica (JM: en) English 107: Jordan (JO: ar) Arabic 108: Japan (JP: ja) Japanese 109: Kenya (KE: en sw) English Swahili 110: Kyrgyzstan (KG: ky) Kirghiz 111: Cambodia (KH: km) Cambodian 112: Kiribati (KI: en) English 113: Comoros (KM: fr ar) French Arabic 114: KN (KN: en) English 115: North Korea (KP: ko) Korean 116: South Korea (KR: ko) Korean 117: Kuwait (KW: ar en) Arabic English 118: KY (KY: en) English 119: Kazakhstan (KZ: kk ru) Kazakh Russian 120: Laos (LA: lo fr) Laothian French 121: Lebanon (LB: ar en fr) Arabic English French 122: LC (LC: en fr) English French 123: Liechtenstein (LI: de) German 124: Sri Lanka (LK: ta si en) Tamil Sinhalese English 125: Liberia (LR: en) English 126: Lesotho (LS: st en) Sesotho English 127: Lithuania (LT: lt ru pl) Lithuanian Russian Polish 128: Luxembourg (LU: fr de) French German 129: Latvia (LV: lv lt ru) Latvian (Lettish) Lithuanian Russian 130: Libya (LY: ar en it) Arabic English Italian 131: Morocco (MA: ar fr es) Arabic French Spanish 132: Monaco (MC: fr en it) French English Italian 133: Moldova (MD: mo ro bg) Moldavian Romanian Bulgarian 134: Madagascar (MG: mg en fr) Malagasy English French 135: MH (MH:) 136: Macedonia (MK: mk sh tr) Macedonian Serbo-Croatian Turkish 137: Mali (ML: fr) French 138: Myanmar (MM: my) Burmese 139: Mongolia (MN: mn ru) Mongolian Russian 140: MO (MO: zh pt) Chinese Portuguese 141: MP (MP:) 142: Martinique (MQ: fr) French 143: Mauritania (MR: ar fr) Arabic French 144: Montserrat (MS: en) English 145: Malta (MT: mt en it) Maltese English Italian 146: Mauritius (MU: en fr hi) English French Hindi 147: MV (MV:) 148: MW (MW: en) English 149: Mexico (MX: es) Spanish 150: Malaysia (MY: ms en) Malay English 151: Mozambique (MZ: pt) Portuguese 152: Namibia (NA: en af de) English Afrikaans German 153: New Caledonia (NC:) 154: Niger (NE: fr ha) French Hausa 155: NF (NF: en) English 156: Nigeria (NG: en ha yo) English Hausa Yoruba 157: Nicaragua (NI: es) Spanish 158: Netherlands (NL: nl fy) Dutch Frisian 159: Norway (NO: no) Norwegian 160: Nepal (NP: ne) Nepali 161: NR (NR: na en) Nauru English 162: Niue (NU: en) English 163: New Zealand (NZ: en mi) English Maori 164: Oman (OM: ar en) Arabic English 165: Panama (PA: es en) Spanish English 166: Peru (PE: es qu ay) Spanish Quechua Aymara 167: French Polynesia (PF: fr) French 168: Papua New Guinea (PG: en) English 169: Philippines (PH: en tl es) English Tagalog Spanish 170: Pakistan (PK: ur en ps pa sd) Urdu English Pashto (Pushto) Punjabi Sindhi 171: Poland (PL: pl) Polish 172: PM (PM: fr en) French English 173: PN (PN: en) English 174: Puerto Rico (PR: es en) Spanish English 175: Portugal (PT: pt) Portuguese 176: PW (PW: en) English 177: Paraguay (PY: es gn) Spanish Guarani 178: Qatar (QA: ar en) Arabic English 179: RE (RE: fr ta) French Tamil 180: Romania (RO: ro hu) Romanian Hungarian 181: Russia (RU: ru) Russian 182: Rwanda (RW: en fr rw) English French Kinyarwanda 183: Saudi Arabia (SA: ar) Arabic 184: SB (SB: en) English 185: Seychelles (SC: en fr) English French 186: Sudan (SD: ar su) Arabic Sundanese 187: Sweden (SE: sv) Swedish 188: Singapore (SG: zh en ms ta) Chinese English Malay Tamil 189: SH (SH: en) English 190: Slovenia (SI: sl) Slovenian 191: SJ (SJ: no) Norwegian 192: Slovakia (SK: sk hu pl sh) Slovak Hungarian Polish Serbo-Croatian 193: Sierra Leone (SL: en) English 194: SM (SM: it) Italian 195: Senegal (SN: fr) French 196: Somalia (SO: ar en it so) Arabic English Italian Somali 197: Suriname (SR: nl en es hi) Dutch English Spanish Hindi 198: ST (ST: pt) Portuguese 199: El Salvador (SV: es) Spanish 200: Syria (SY: ar) Arabic 201: Swaziland (SZ: en ss) English Siswati 202: TC (TC: en) English 203: Chad (TD: fr ar) French Arabic 204: French Southern Territories (TF: fr) French 205: Togo (TG: fr) French 206: Thailand (TH: th) Thai 207: Tajikistan (TJ: tg ru uz) Tajik Russian Uzbek 208: Tokelau (TK: en mi) English Maori 209: Turkmenistan (TM: tk ru) Turkmen Russian 210: Tunisia (TN: ar) Arabic 211: Tonga (TO: en to) English Tonga 212: East Timor (TP:) 213: Turkey (TR: tr ku) Turkish Kurdish 214: Trinidad and Tobago (TT: en) English 215: TV (TV: en) English 216: Taiwan (TW: zh) Chinese 217: Tanzania (TZ: en sw) English Swahili 218: Ukraine (UA: uk ru) Ukrainian Russian 219: Uganda (UG: en sw) English Swahili 220: UM (UM: en) English 221: United States (US: en es) English Spanish 222: Uruguay (UY: es) Spanish 223: Uzbekistan (UZ: uz ru) Uzbek Russian 224: Vatican (VA: la it) Latin Italian 225: VC (VC: en) English 226: Venezuela (VE: es) Spanish 227: British Virgin Islands (VG: en) English 228: U.S. Virgin Islands (VI: en) English 229: Vietnam (VN: vi zh fr) Vietnamese Chinese French 230: Vanuatu (VU: en fr bi) English French Bislama 231: WF (WF: fr) French 232: WS (WS: en sm) English Samoan 233: Yemen (YE: ar) Arabic 234: Mayotte (YT: fr mg sw) French Malagasy Swahili 235: Yugoslavia (YU: sr sh mk hu) Serbian Serbo-Croatian Macedonian Hungarian 236: South Africa (ZA: af en) Afrikaans English 237: Zambia (ZM: en) English 238: Zaire (ZR: fr sw) French Swahili 239: Zimbabwe (ZW: en sn) English Shona aa Afar ab Abkhazian Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) 1: af_NA Afrikaans Namibia 2: af_ZA South Africa 3: am_ER Amharic Eritrea 4: am_ET Ethiopia 5: ar_AE Arabic United Arab Emirates 6: ar_BH Bahrain 7: ar_DJ Djibouti 8: ar_DZ Algeria 9: ar_EG Egypt 10: ar_EH Western Sahara 11: ar_ER Eritrea 12: ar_ET Ethiopia 13: ar_IL Israel 14: ar_IQ Iraq 15: ar_IR Iran 16: ar_JO Jordan 17: ar_KM Comoros 18: ar_KW Kuwait 19: ar_LB Lebanon 20: ar_LY Libya 21: ar_MA Morocco 22: ar_MR Mauritania 23: ar_OM Oman 24: ar_QA Qatar 25: ar_SA Saudi Arabia 26: ar_SD Sudan 27: ar_SO Somalia 28: ar_SY Syria 29: ar_TD Chad 30: ar_TN Tunisia 31: ar_YE Yemen as Assamese 32: ay_BO Aymara Bolivia 33: ay_PE Peru 34: az_AZ Azerbaijani Azerbaijan ba Bashkir 35: be_BY Byelorussian Belarus 36: bg_BG Bulgarian Bulgaria 37: bg_MD Moldova 38: bh_BD Bihari Bangladesh 39: bi_VU Bislama Vanuatu 40: bn_BD Bengali Bangladesh 41: bo_CN Tibetan China 42: br_FR Breton France 43: ca_ES Catalan Spain 44: co_FR Corsican France 45: cs_CZ Czech Czech Republic 46: cy_GB Welsh United Kingdom 47: da_DK Danish Denmark 48: da_FO FO 49: da_GL GL 50: de_AT German Austria 51: de_BE Belgium 52: de_CH Switzerland 53: de_DE Germany 54: de_IT Italy 55: de_LI Liechtenstein 56: de_LU Luxembourg 57: de_NA Namibia 58: dz_BT Bhutani Bhutan 59: el_CY Greek Cyprus 60: el_GR Greece 61: en_AE English United Arab Emirates 62: en_AG AG 63: en_AN Netherlands Antilles 64: en_AS AS 65: en_AU Australia 66: en_AW Aruba 67: en_BB Barbados 68: en_BD Bangladesh 69: en_BH Bahrain 70: en_BM Bermuda 71: en_BN Brunei 72: en_BS Bahamas 73: en_BT Bhutan 74: en_BW Botswana 75: en_BZ Belize 76: en_CA Canada 77: en_CC CC 78: en_CK CK 79: en_CM Cameroon 80: en_CX CX 81: en_CY Cyprus 82: en_DM Dominica 83: en_EG Egypt 84: en_ER Eritrea 85: en_ET Ethiopia 86: en_FJ Fiji 87: en_FK FK 88: en_FM Micronesia 89: en_GB United Kingdom 90: en_GD GD 91: en_GH Ghana 92: en_GI GI 93: en_GM Gambia 94: en_GP Guadeloupe 95: en_GU GU 96: en_GY Guyana 97: en_HK Hong Kong 98: en_ID Indonesia 99: en_IE Ireland 100: en_IN India 101: en_IO IO 102: en_JM Jamaica 103: en_KE Kenya 104: en_KI Kiribati 105: en_KN KN 106: en_KW Kuwait 107: en_KY KY 108: en_LB Lebanon 109: en_LC LC 110: en_LK Sri Lanka 111: en_LR Liberia 112: en_LS Lesotho 113: en_LY Libya 114: en_MC Monaco 115: en_MG Madagascar 116: en_MS Montserrat 117: en_MT Malta 118: en_MU Mauritius 119: en_MW MW 120: en_MY Malaysia 121: en_NA Namibia 122: en_NF NF 123: en_NG Nigeria 124: en_NR NR 125: en_NU Niue 126: en_NZ New Zealand 127: en_OM Oman 128: en_PA Panama 129: en_PG Papua New Guinea 130: en_PH Philippines 131: en_PK Pakistan 132: en_PM PM 133: en_PN PN 134: en_PR Puerto Rico 135: en_PW PW 136: en_QA Qatar 137: en_RW Rwanda 138: en_SB SB 139: en_SC Seychelles 140: en_SG Singapore 141: en_SH SH 142: en_SL Sierra Leone 143: en_SO Somalia 144: en_SR Suriname 145: en_SZ Swaziland 146: en_TC TC 147: en_TK Tokelau 148: en_TO Tonga 149: en_TT Trinidad and Tobago 150: en_TV TV 151: en_TZ Tanzania 152: en_UG Uganda 153: en_UM UM 154: en_US United States 155: en_VC VC 156: en_VG British Virgin Islands 157: en_VI U.S. Virgin Islands 158: en_VU Vanuatu 159: en_WS WS 160: en_ZA South Africa 161: en_ZM Zambia 162: en_ZW Zimbabwe eo Esperanto 163: es_AD Spanish Andorra 164: es_AR Argentina 165: es_BO Bolivia 166: es_BZ Belize 167: es_CL Chile 168: es_CO Colombia 169: es_CR Costa Rica 170: es_CU Cuba 171: es_DO Dominican Republic 172: es_EC Ecuador 173: es_ES Spain 174: es_GI GI 175: es_GQ Equatorial Guinea 176: es_GT Guatemala 177: es_HN Honduras 178: es_MA Morocco 179: es_MX Mexico 180: es_NI Nicaragua 181: es_PA Panama 182: es_PE Peru 183: es_PH Philippines 184: es_PR Puerto Rico 185: es_PY Paraguay 186: es_SR Suriname 187: es_SV El Salvador 188: es_US United States 189: es_UY Uruguay 190: es_VE Venezuela 191: et_EE Estonian Estonia 192: eu_ES Basque Spain 193: eu_FR France 194: fa_IR Persian Iran 195: fi_FI Finnish Finland 196: fj_FJ Fiji Fiji 197: fo_FO Faroese FO 198: fr_AD French Andorra 199: fr_BE Belgium 200: fr_BF Burkina Faso 201: fr_BI Burundi 202: fr_BJ Benin 203: fr_CA Canada 204: fr_CF Central African Republic 205: fr_CG Congo 206: fr_CH Switzerland 207: fr_CI C?te d'Ivoire 208: fr_CM Cameroon 209: fr_DJ Djibouti 210: fr_DM Dominica 211: fr_DZ Algeria 212: fr_EG Egypt 213: fr_EH Western Sahara 214: fr_FR France 215: fr_FX FX 216: fr_GA Gabon 217: fr_GD GD 218: fr_GF French Guiana 219: fr_GN Guinea 220: fr_GP Guadeloupe 221: fr_HT Haiti 222: fr_IT Italy 223: fr_KM Comoros 224: fr_LA Laos 225: fr_LB Lebanon 226: fr_LC LC 227: fr_LU Luxembourg 228: fr_MA Morocco 229: fr_MC Monaco 230: fr_MG Madagascar 231: fr_ML Mali 232: fr_MQ Martinique 233: fr_MR Mauritania 234: fr_MU Mauritius 235: fr_NE Niger 236: fr_PF French Polynesia 237: fr_PM PM 238: fr_RE RE 239: fr_RW Rwanda 240: fr_SC Seychelles 241: fr_SN Senegal 242: fr_TD Chad 243: fr_TF French Southern Territories 244: fr_TG Togo 245: fr_VN Vietnam 246: fr_VU Vanuatu 247: fr_WF WF 248: fr_YT Mayotte 249: fr_ZR Zaire 250: fy_NL Frisian Netherlands 251: ga_IE Irish Ireland 252: gd_GB Scots Gaelic United Kingdom 253: gl_ES Galician Spain 254: gn_PY Guarani Paraguay 255: gu_IN Gujarati India 256: ha_NE Hausa Niger 257: ha_NG Nigeria he Hebrew 258: hi_BD Hindi Bangladesh 259: hi_FJ Fiji 260: hi_GY Guyana 261: hi_IN India 262: hi_MU Mauritius 263: hi_SR Suriname 264: hr_BA Croatian Bosnia and Herzegovina 265: hr_HR Croatia 266: hu_HU Hungarian Hungary 267: hu_RO Romania 268: hu_SK Slovakia 269: hu_YU Yugoslavia 270: hy_AM Armenian Armenia 271: hy_AZ Azerbaijan 272: hy_GE Georgia ia Interlingua id Indonesian ie Interlingue 273: ik_GL Inupiak GL 274: in_ID Indonesian Indonesia 275: is_IS Icelandic Iceland 276: it_CH Italian Switzerland 277: it_EH Western Sahara 278: it_ER Eritrea 279: it_IT Italy 280: it_LY Libya 281: it_MC Monaco 282: it_MT Malta 283: it_SM SM 284: it_SO Somalia 285: it_VA Vatican iu Inuktitut 286: iw_IL Hebrew Israel 287: ja_JP Japanese Japan 288: ji_IL Yiddish Israel jw Javanese 289: ka_GE Georgian Georgia 290: kk_KZ Kazakh Kazakhstan 291: kl_GL Greenlandic GL 292: km_KH Cambodian Cambodia 293: kn_IN Kannada India 294: ko_KP Korean North Korea 295: ko_KR South Korea 296: ks_IN Kashmiri India 297: ku_IQ Kurdish Iraq 298: ku_IR Iran 299: ku_TR Turkey 300: ky_KG Kirghiz Kyrgyzstan 301: la_VA Latin Vatican ln Lingala 302: lo_LA Laothian Laos 303: lt_LT Lithuanian Lithuania 304: lt_LV Latvia 305: lv_LV Latvian (Lettish) Latvia 306: mg_MG Malagasy Madagascar 307: mg_YT Mayotte 308: mi_CK Maori CK 309: mi_NZ New Zealand 310: mi_TK Tokelau 311: mk_BA Macedonian Bosnia and Herzegovina 312: mk_MK Macedonia 313: mk_YU Yugoslavia 314: ml_IN Malayalam India 315: mn_MN Mongolian Mongolia 316: mo_MD Moldavian Moldova 317: mr_IN Marathi India 318: ms_BN Malay Brunei 319: ms_MY Malaysia 320: ms_SG Singapore 321: mt_MT Maltese Malta 322: my_MM Burmese Myanmar 323: na_NR Nauru NR 324: ne_BT Nepali Bhutan 325: ne_IN India 326: ne_NP Nepal 327: nl_AN Dutch Netherlands Antilles 328: nl_AW Aruba 329: nl_BE Belgium 330: nl_ID Indonesia 331: nl_NL Netherlands 332: nl_SR Suriname 333: no_BV Norwegian BV 334: no_NO Norway 335: no_SJ SJ oc Occitan om Oromo (Afan) 336: or_IN Oriya India 337: pa_IN Punjabi India 338: pa_PK Pakistan 339: pl_LT Polish Lithuania 340: pl_PL Poland 341: pl_SK Slovakia 342: ps_AF Pashto (Pushto) Afghanistan 343: ps_PK Pakistan 344: pt_AO Portuguese Angola 345: pt_BR Brazil 346: pt_CV Cape Verde 347: pt_GW Guinea-Bissau 348: pt_MO MO 349: pt_MZ Mozambique 350: pt_PT Portugal 351: pt_ST ST 352: qu_BO Quechua Bolivia 353: qu_EC Ecuador 354: qu_PE Peru 355: rm_CH Rhaeto-Romance Switzerland 356: rn_AI Kirundi Anguilla 357: rn_BI Burundi 358: ro_MD Romanian Moldova 359: ro_RO Romania 360: ru_AM Russian Armenia 361: ru_AZ Azerbaijan 362: ru_BY Belarus 363: ru_EE Estonia 364: ru_GE Georgia 365: ru_KZ Kazakhstan 366: ru_LT Lithuania 367: ru_LV Latvia 368: ru_MN Mongolia 369: ru_RU Russia 370: ru_TJ Tajikistan 371: ru_TM Turkmenistan 372: ru_UA Ukraine 373: ru_UZ Uzbekistan 374: rw_RW Kinyarwanda Rwanda 375: sa_IN Sanskrit India 376: sd_PK Sindhi Pakistan 377: sg_CF Sangho Central African Republic 378: sh_BA Serbo-Croatian Bosnia and Herzegovina 379: sh_MK Macedonia 380: sh_SK Slovakia 381: sh_YU Yugoslavia 382: si_LK Sinhalese Sri Lanka 383: sk_CZ Slovak Czech Republic 384: sk_SK Slovakia 385: sl_BA Slovenian Bosnia and Herzegovina 386: sl_SI Slovenia 387: sm_AS Samoan AS 388: sm_WS WS 389: sn_ZW Shona Zimbabwe 390: so_DJ Somali Djibouti 391: so_SO Somalia 392: sq_AL Albanian Albania 393: sq_BA Bosnia and Herzegovina 394: sr_BA Serbian Bosnia and Herzegovina 395: sr_YU Yugoslavia 396: ss_SZ Siswati Swaziland 397: st_LS Sesotho Lesotho 398: su_SD Sundanese Sudan 399: sv_FI Swedish Finland 400: sv_SE Sweden 401: sw_BI Swahili Burundi 402: sw_KE Kenya 403: sw_TZ Tanzania 404: sw_UG Uganda 405: sw_YT Mayotte 406: sw_ZR Zaire 407: ta_IN Tamil India 408: ta_LK Sri Lanka 409: ta_RE RE 410: ta_SG Singapore 411: te_IN Telugu India 412: tg_TJ Tajik Tajikistan 413: th_TH Thai Thailand 414: ti_ER Tigrinya Eritrea 415: tk_IQ Turkmen Iraq 416: tk_TM Turkmenistan 417: tl_PH Tagalog Philippines 418: tn_BW Setswana Botswana 419: to_TO Tonga Tonga 420: tr_BG Turkish Bulgaria 421: tr_CY Cyprus 422: tr_MK Macedonia 423: tr_TR Turkey ts Tsonga tt Tatar tw Twi ug Uighur 424: uk_UA Ukrainian Ukraine 425: ur_GY Urdu Guyana 426: ur_PK Pakistan 427: uz_TJ Uzbek Tajikistan 428: uz_UZ Uzbekistan 429: vi_VN Vietnamese Vietnam vo Volapuk 430: wo_GM Wolof Gambia xh Xhosa yi Yiddish 431: yo_NG Yoruba Nigeria za Zhuang 432: zh_BN Chinese Brunei 433: zh_CN China 434: zh_HK Hong Kong 435: zh_MO MO 436: zh_SG Singapore 437: zh_TW Taiwan 438: zh_VN Vietnam zu Zulu --------------------------------------------------------- >Importance: Normal >Subject: Re: UPD> Re: UPDF open standard for locales >To: "Akio Kido" >Cc: norbertschade@oaktech.com, , Jim Sommer >From: "Mark VanderWiele" >Date: Thu, 19 Apr 2001 13:57:36 -0500 >X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.6 |December 14, 2000) at 04/19/2001 02:56:03 PM >MIME-Version: 1.0 > > >Akio: What should we do about kw its not in the ISO languages? Also, was >SU really SD. see info below. > >Jim: Thank You. > >Regards, >Mark VanderWiele >IBM, Linux Technology Center >512-838-4779, t/l 678 >MARKV@IBMUS >email: markv@us.ibm.com > > >Jim Sommer on 04/19/2001 08:05:53 AM > >To: Mark VanderWiele/Austin/IBM@IBMUS, norbertschade@oaktech.com, > >cc: >Subject: Re: UPD> Re: UPDF open standard for locales > > > >Here's the translation of the locales that Mark listed: > >arIN-Arabic-India >arSD-Arabic-Sudan >deBE-German-Belgium >enBE-English-Belgium >enBW-English-Botswana >enHK-English-Hong_Kong >enIN-English-India >enSG-English-Singapore >enZW-English-Zimbabwe >esGT-Spanish-Guatemala (this was in the original list) >esHN-Spanish-Honduras (this was incorrectly listed as esHM in the original >list) >faIN-Farsi-India >glES-Galician-Spain (from the Linux web site, not Mark's list) >gvGB-Manx_Gaelic-United_Kingdon >knIN-Kannada-India (this was in the original list) >kwGB-Cornish-United_Kingdom (kw is not in the ISO language list) >psIN-Pashto-India >ruUA-Russian-Ukraine >sdIN-Sindhi-India >shYU-Serbo-Croatian-Yugoslavia >srYU-Serbian-Yugoslavia > >I couldn't find the country SU but looking at the Linux web site, I figured >it was a typo and supposed to be SD. > >enZA was in the original list but from the Linux web site I found that enZW >was missing. > >I couldn't find the language fs but found that faIN was missing. > >I don't think we should include kwGB since Cornish isn't in the ISO >language list. > >Jim > >At 4/18/01 08:07 PM, Mark VanderWiele wrote: >>Norbert: I will try to get the following information into the desired >>format. However, I wanted to let you know that the Linux globaization >work >>is tackling the same problem and has another locals list. They have >>identified arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, >>esHN, fsIN, gvGB, knIN,kwGB, psIN, ruUA, sdIN, shYU, srYU as missing in >>your list of locals. >> >>Regards, >>Mark VanderWiele >>IBM, Linux Technology Center >>512-838-4779, t/l 678 >>MARKV@IBMUS >>email: markv@us.ibm.com >>---------------------- Forwarded by Mark VanderWiele/Austin/IBM on >>04/18/2001 06:33 PM --------------------------- >> >>Akio Kido@IBMJP >>04/16/2001 09:13 PM >> >>To: Mark VanderWiele/Austin/IBM@IBMUS >>cc: George Kraft/Austin/IBM@IBMUS >>From: Akio Kido/Japan/IBM@IBMJP >>Subject: Re: UPDF open standard for locales (Document link: Mark >> VanderWiele) >> >>Hi, Mark. Sorry for my delaied response. ( I was on business trip on last >>week and restricted access to IBM network ). >> >>Annex B of LI18NUX2000 Globalization specification specified the list of >>locales that should be supported by >>LI18NUX2000 confomant distribution. Please refer to >>http://www.li18nux.org/li18nux2k/ >> >>As far as I checked the LI18NUX2000, the following locales are in the >>LI18NUX2000 but not in the list >>attached. >> >>arIN, arSU, deBE, enBE, enBW, enHK, enIN, enSG, enZA, esGT, esHN, fsIN, >>gvGB, knIN, >>kwGB, psIN, ruUA, sdIN, shYU, srYU. >> >>Best regards, >>Akio Kido (Globalization CoC, Yamato, IBM & Co-chair person of Li18nux) >>1623-14, Shimotsuruma, Yamato-shi, Kanagawa-ken 242, Japan (LAB-SA4) >>E-mail: kido@jp.ibm.com Tel: +81-46-215-5436 FAX: +81-46-272-3352 >> >> >>From: Mark VanderWiele@IBMUS on 2001/04/13 09:10 >> >>To: Akio Kido/Japan/IBM@IBMJP >>cc: George Kraft/Austin/IBM@IBMUS >>From: Mark VanderWiele/Austin/IBM@IBMUS >>Subject: Re: UPDF open standard for locales >> >> >> >>Kido-san: The following list all the way at the bottom of this note is a >>proposed list to identify translations in the Universal Printer Driver >>Format standard being worked on by the Printer Working Group >(www.pwg.org). >>Please verify its completeness, Forward to other IBM interested parties, & >>and or propose a better source. I am told you may be working on an I18N >>standard for locals. Is this true? Is there another list I should be >>looking at? >> >>Thank you, >> >>Regards, >>Mark VanderWiele >>IBM, Linux Technology Center >>512-838-4779, t/l 678 >>MARKV@IBMUS >>email: markv@us.ibm.com > > > -------------- next part -------------- Table 1 -- Languages spoken in any particular ISO-3166 country (official languages are listed first) 1: Andorra (AD: fr es) French Spanish 2: United Arab Emirates (AE: ar en) Arabic English 3: Afghanistan (AF: ps) Pashto (Pushto) 4: AG (AG: en) English 5: Anguilla (AI: rn) Kirundi 6: Albania (AL: sq) Albanian 7: Armenia (AM: hy ru) Armenian Russian 8: Netherlands Antilles (AN: nl en) Dutch English 9: Angola (AO: pt) Portuguese 10: AQ (AQ:) 11: Argentina (AR: es) Spanish 12: AS (AS: en sm) English Samoan 13: Austria (AT: de) German 14: Australia (AU: en) English 15: Aruba (AW: nl en) Dutch English 16: Azerbaijan (AZ: az hy ru) Azerbaijani Armenian Russian 17: Bosnia and Herzegovina (BA: sr sh hr sl mk sq) Serbian Serbo-Croatian Croatian Slovenian Macedonian Albanian 18: Barbados (BB: en) English 19: Bangladesh (BD: bn hi bh en) Bengali Hindi Bihari English 20: Belgium (BE: fr nl de) French Dutch German 21: Burkina Faso (BF: fr) French 22: Bulgaria (BG: bg tr) Bulgarian Turkish 23: Bahrain (BH: ar en) Arabic English 24: Burundi (BI: rn fr sw) Kirundi French Swahili 25: Benin (BJ: fr) French 26: Bermuda (BM: en) English 27: Brunei (BN: ms en zh) Malay English Chinese 28: Bolivia (BO: es ay qu) Spanish Aymara Quechua 29: Brazil (BR: pt) Portuguese 30: Bahamas (BS: en) English 31: Bhutan (BT: dz en ne) Bhutani English Nepali 32: BV (BV: no) Norwegian 33: Botswana (BW: en tn) English Setswana 34: Belarus (BY: be ru) Byelorussian Russian 35: Belize (BZ: en es) English Spanish 36: Canada (CA: en fr) English French 37: CC (CC: en) English 38: Central African Republic (CF: fr sg) French Sangho 39: Congo (CG: fr) French 40: Switzerland (CH: fr de it rm) French German Italian Rhaeto-Romance 41: C?te d'Ivoire (CI: fr) French 42: CK (CK: mi en) Maori English 43: Chile (CL: es) Spanish 44: Cameroon (CM: en fr) English French 45: China (CN: zh bo) Chinese Tibetan 46: Colombia (CO: es) Spanish 47: Costa Rica (CR: es) Spanish 48: Cuba (CU: es) Spanish 49: Cape Verde (CV: pt) Portuguese 50: CX (CX: en) English 51: Cyprus (CY: el tr en) Greek Turkish English 52: Czech Republic (CZ: cs sk) Czech Slovak 53: Germany (DE: de) German 54: Djibouti (DJ: ar fr so) Arabic French Somali 55: Denmark (DK: da) Danish 56: Dominica (DM: en fr) English French 57: Dominican Republic (DO: es) Spanish 58: Algeria (DZ: ar fr) Arabic French 59: Ecuador (EC: es qu) Spanish Quechua 60: Estonia (EE: et ru) Estonian Russian 61: Egypt (EG: ar en fr) Arabic English French 62: Western Sahara (EH: ar fr it) Arabic French Italian 63: Eritrea (ER: am ti ar en it) Amharic Tigrinya Arabic English Italian 64: Spain (ES: es eu ca gl) Spanish Basque Catalan Galician 65: Ethiopia (ET: am ar en) Amharic Arabic English 66: Finland (FI: fi sv) Finnish Swedish 67: Fiji (FJ: en fj hi) English Fiji Hindi 68: FK (FK: en) English 69: Micronesia (FM: en) English 70: FO (FO: fo da) Faroese Danish 71: France (FR: fr eu br co) French Basque Breton Corsican 72: FX (FX: fr) French 73: Gabon (GA: fr) French 74: United Kingdom (GB: en gd cy) English Scots Gaelic Welsh 75: GD (GD: en fr) English French 76: Georgia (GE: ka hy ru) Georgian Armenian Russian 77: French Guiana (GF: fr) French 78: Ghana (GH: en) English 79: GI (GI: en es) English Spanish 80: GL (GL: da ik kl) Danish Inupiak Greenlandic 81: Gambia (GM: en wo) English Wolof 82: Guinea (GN: fr) French 83: Guadeloupe (GP: fr en) French English 84: Equatorial Guinea (GQ: es) Spanish 85: Greece (GR: el) Greek 86: GS (GS:) 87: Guatemala (GT: es) Spanish 88: GU (GU: en) English 89: Guinea-Bissau (GW: pt) Portuguese 90: Guyana (GY: en hi ur) English Hindi Urdu 91: Hong Kong (HK: zh en) Chinese English 92: HM (HM:) 93: Honduras (HN: es) Spanish 94: Croatia (HR: hr) Croatian 95: Haiti (HT: fr) French 96: Hungary (HU: hu) Hungarian 97: Indonesia (ID: in en nl) Indonesian English Dutch 98: Ireland (IE: en ga) English Irish 99: Israel (IL: iw ar ji) Hebrew Arabic Yiddish 100: India (IN: hi en gu kn ks ml mr ne or pa sa ta te) Hindi English Gujarati Kannada Kashmiri Malayalam Marathi Nepali Oriya Punjabi Sanskrit Tamil Telugu 101: IO (IO: en) English 102: Iraq (IQ: ar ku tk) Arabic Kurdish Turkmen 103: Iran (IR: fa ar ku) Persian Arabic Kurdish 104: Iceland (IS: is) Icelandic 105: Italy (IT: it fr de) Italian French German 106: Jamaica (JM: en) English 107: Jordan (JO: ar) Arabic 108: Japan (JP: ja) Japanese 109: Kenya (KE: en sw) English Swahili 110: Kyrgyzstan (KG: ky) Kirghiz 111: Cambodia (KH: km) Cambodian 112: Kiribati (KI: en) English 113: Comoros (KM: fr ar) French Arabic 114: KN (KN: en) English 115: North Korea (KP: ko) Korean 116: South Korea (KR: ko) Korean 117: Kuwait (KW: ar en) Arabic English 118: KY (KY: en) English 119: Kazakhstan (KZ: kk ru) Kazakh Russian 120: Laos (LA: lo fr) Laothian French 121: Lebanon (LB: ar en fr) Arabic English French 122: LC (LC: en fr) English French 123: Liechtenstein (LI: de) German 124: Sri Lanka (LK: ta si en) Tamil Sinhalese English 125: Liberia (LR: en) English 126: Lesotho (LS: st en) Sesotho English 127: Lithuania (LT: lt ru pl) Lithuanian Russian Polish 128: Luxembourg (LU: fr de) French German 129: Latvia (LV: lv lt ru) Latvian (Lettish) Lithuanian Russian 130: Libya (LY: ar en it) Arabic English Italian 131: Morocco (MA: ar fr es) Arabic French Spanish 132: Monaco (MC: fr en it) French English Italian 133: Moldova (MD: mo ro bg) Moldavian Romanian Bulgarian 134: Madagascar (MG: mg en fr) Malagasy English French 135: MH (MH:) 136: Macedonia (MK: mk sh tr) Macedonian Serbo-Croatian Turkish 137: Mali (ML: fr) French 138: Myanmar (MM: my) Burmese 139: Mongolia (MN: mn ru) Mongolian Russian 140: MO (MO: zh pt) Chinese Portuguese 141: MP (MP:) 142: Martinique (MQ: fr) French 143: Mauritania (MR: ar fr) Arabic French 144: Montserrat (MS: en) English 145: Malta (MT: mt en it) Maltese English Italian 146: Mauritius (MU: en fr hi) English French Hindi 147: MV (MV:) 148: MW (MW: en) English 149: Mexico (MX: es) Spanish 150: Malaysia (MY: ms en) Malay English 151: Mozambique (MZ: pt) Portuguese 152: Namibia (NA: en af de) English Afrikaans German 153: New Caledonia (NC:) 154: Niger (NE: fr ha) French Hausa 155: NF (NF: en) English 156: Nigeria (NG: en ha yo) English Hausa Yoruba 157: Nicaragua (NI: es) Spanish 158: Netherlands (NL: nl fy) Dutch Frisian 159: Norway (NO: no) Norwegian 160: Nepal (NP: ne) Nepali 161: NR (NR: na en) Nauru English 162: Niue (NU: en) English 163: New Zealand (NZ: en mi) English Maori 164: Oman (OM: ar en) Arabic English 165: Panama (PA: es en) Spanish English 166: Peru (PE: es qu ay) Spanish Quechua Aymara 167: French Polynesia (PF: fr) French 168: Papua New Guinea (PG: en) English 169: Philippines (PH: en tl es) English Tagalog Spanish 170: Pakistan (PK: ur en ps pa sd) Urdu English Pashto (Pushto) Punjabi Sindhi 171: Poland (PL: pl) Polish 172: PM (PM: fr en) French English 173: PN (PN: en) English 174: Puerto Rico (PR: es en) Spanish English 175: Portugal (PT: pt) Portuguese 176: PW (PW: en) English 177: Paraguay (PY: es gn) Spanish Guarani 178: Qatar (QA: ar en) Arabic English 179: RE (RE: fr ta) French Tamil 180: Romania (RO: ro hu) Romanian Hungarian 181: Russia (RU: ru) Russian 182: Rwanda (RW: en fr rw) English French Kinyarwanda 183: Saudi Arabia (SA: ar) Arabic 184: SB (SB: en) English 185: Seychelles (SC: en fr) English French 186: Sudan (SD: ar su) Arabic Sundanese 187: Sweden (SE: sv) Swedish 188: Singapore (SG: zh en ms ta) Chinese English Malay Tamil 189: SH (SH: en) English 190: Slovenia (SI: sl) Slovenian 191: SJ (SJ: no) Norwegian 192: Slovakia (SK: sk hu pl sh) Slovak Hungarian Polish Serbo-Croatian 193: Sierra Leone (SL: en) English 194: SM (SM: it) Italian 195: Senegal (SN: fr) French 196: Somalia (SO: ar en it so) Arabic English Italian Somali 197: Suriname (SR: nl en es hi) Dutch English Spanish Hindi 198: ST (ST: pt) Portuguese 199: El Salvador (SV: es) Spanish 200: Syria (SY: ar) Arabic 201: Swaziland (SZ: en ss) English Siswati 202: TC (TC: en) English 203: Chad (TD: fr ar) French Arabic 204: French Southern Territories (TF: fr) French 205: Togo (TG: fr) French 206: Thailand (TH: th) Thai 207: Tajikistan (TJ: tg ru uz) Tajik Russian Uzbek 208: Tokelau (TK: en mi) English Maori 209: Turkmenistan (TM: tk ru) Turkmen Russian 210: Tunisia (TN: ar) Arabic 211: Tonga (TO: en to) English Tonga 212: East Timor (TP:) 213: Turkey (TR: tr ku) Turkish Kurdish 214: Trinidad and Tobago (TT: en) English 215: TV (TV: en) English 216: Taiwan (TW: zh) Chinese 217: Tanzania (TZ: en sw) English Swahili 218: Ukraine (UA: uk ru) Ukrainian Russian 219: Uganda (UG: en sw) English Swahili 220: UM (UM: en) English 221: United States (US: en es) English Spanish 222: Uruguay (UY: es) Spanish 223: Uzbekistan (UZ: uz ru) Uzbek Russian 224: Vatican (VA: la it) Latin Italian 225: VC (VC: en) English 226: Venezuela (VE: es) Spanish 227: British Virgin Islands (VG: en) English 228: U.S. Virgin Islands (VI: en) English 229: Vietnam (VN: vi zh fr) Vietnamese Chinese French 230: Vanuatu (VU: en fr bi) English French Bislama 231: WF (WF: fr) French 232: WS (WS: en sm) English Samoan 233: Yemen (YE: ar) Arabic 234: Mayotte (YT: fr mg sw) French Malagasy Swahili 235: Yugoslavia (YU: sr sh mk hu) Serbian Serbo-Croatian Macedonian Hungarian 236: South Africa (ZA: af en) Afrikaans English 237: Zambia (ZM: en) English 238: Zaire (ZR: fr sw) French Swahili 239: Zimbabwe (ZW: en sn) English Shona aa Afar ab Abkhazian Table 2 -- Countries where any particular ISO-639 language is spoken (old codes: iw,ji,in; new codes: he, yi,id) 1: af_NA Afrikaans Namibia 2: af_ZA South Africa 3: am_ER Amharic Eritrea 4: am_ET Ethiopia 5: ar_AE Arabic United Arab Emirates 6: ar_BH Bahrain 7: ar_DJ Djibouti 8: ar_DZ Algeria 9: ar_EG Egypt 10: ar_EH Western Sahara 11: ar_ER Eritrea 12: ar_ET Ethiopia 13: ar_IL Israel 14: ar_IQ Iraq 15: ar_IR Iran 16: ar_JO Jordan 17: ar_KM Comoros 18: ar_KW Kuwait 19: ar_LB Lebanon 20: ar_LY Libya 21: ar_MA Morocco 22: ar_MR Mauritania 23: ar_OM Oman 24: ar_QA Qatar 25: ar_SA Saudi Arabia 26: ar_SD Sudan 27: ar_SO Somalia 28: ar_SY Syria 29: ar_TD Chad 30: ar_TN Tunisia 31: ar_YE Yemen as Assamese 32: ay_BO Aymara Bolivia 33: ay_PE Peru 34: az_AZ Azerbaijani Azerbaijan ba Bashkir 35: be_BY Byelorussian Belarus 36: bg_BG Bulgarian Bulgaria 37: bg_MD Moldova 38: bh_BD Bihari Bangladesh 39: bi_VU Bislama Vanuatu 40: bn_BD Bengali Bangladesh 41: bo_CN Tibetan China 42: br_FR Breton France 43: ca_ES Catalan Spain 44: co_FR Corsican France 45: cs_CZ Czech Czech Republic 46: cy_GB Welsh United Kingdom 47: da_DK Danish Denmark 48: da_FO FO 49: da_GL GL 50: de_AT German Austria 51: de_BE Belgium 52: de_CH Switzerland 53: de_DE Germany 54: de_IT Italy 55: de_LI Liechtenstein 56: de_LU Luxembourg 57: de_NA Namibia 58: dz_BT Bhutani Bhutan 59: el_CY Greek Cyprus 60: el_GR Greece 61: en_AE English United Arab Emirates 62: en_AG AG 63: en_AN Netherlands Antilles 64: en_AS AS 65: en_AU Australia 66: en_AW Aruba 67: en_BB Barbados 68: en_BD Bangladesh 69: en_BH Bahrain 70: en_BM Bermuda 71: en_BN Brunei 72: en_BS Bahamas 73: en_BT Bhutan 74: en_BW Botswana 75: en_BZ Belize 76: en_CA Canada 77: en_CC CC 78: en_CK CK 79: en_CM Cameroon 80: en_CX CX 81: en_CY Cyprus 82: en_DM Dominica 83: en_EG Egypt 84: en_ER Eritrea 85: en_ET Ethiopia 86: en_FJ Fiji 87: en_FK FK 88: en_FM Micronesia 89: en_GB United Kingdom 90: en_GD GD 91: en_GH Ghana 92: en_GI GI 93: en_GM Gambia 94: en_GP Guadeloupe 95: en_GU GU 96: en_GY Guyana 97: en_HK Hong Kong 98: en_ID Indonesia 99: en_IE Ireland 100: en_IN India 101: en_IO IO 102: en_JM Jamaica 103: en_KE Kenya 104: en_KI Kiribati 105: en_KN KN 106: en_KW Kuwait 107: en_KY KY 108: en_LB Lebanon 109: en_LC LC 110: en_LK Sri Lanka 111: en_LR Liberia 112: en_LS Lesotho 113: en_LY Libya 114: en_MC Monaco 115: en_MG Madagascar 116: en_MS Montserrat 117: en_MT Malta 118: en_MU Mauritius 119: en_MW MW 120: en_MY Malaysia 121: en_NA Namibia 122: en_NF NF 123: en_NG Nigeria 124: en_NR NR 125: en_NU Niue 126: en_NZ New Zealand 127: en_OM Oman 128: en_PA Panama 129: en_PG Papua New Guinea 130: en_PH Philippines 131: en_PK Pakistan 132: en_PM PM 133: en_PN PN 134: en_PR Puerto Rico 135: en_PW PW 136: en_QA Qatar 137: en_RW Rwanda 138: en_SB SB 139: en_SC Seychelles 140: en_SG Singapore 141: en_SH SH 142: en_SL Sierra Leone 143: en_SO Somalia 144: en_SR Suriname 145: en_SZ Swaziland 146: en_TC TC 147: en_TK Tokelau 148: en_TO Tonga 149: en_TT Trinidad and Tobago 150: en_TV TV 151: en_TZ Tanzania 152: en_UG Uganda 153: en_UM UM 154: en_US United States 155: en_VC VC 156: en_VG British Virgin Islands 157: en_VI U.S. Virgin Islands 158: en_VU Vanuatu 159: en_WS WS 160: en_ZA South Africa 161: en_ZM Zambia 162: en_ZW Zimbabwe eo Esperanto 163: es_AD Spanish Andorra 164: es_AR Argentina 165: es_BO Bolivia 166: es_BZ Belize 167: es_CL Chile 168: es_CO Colombia 169: es_CR Costa Rica 170: es_CU Cuba 171: es_DO Dominican Republic 172: es_EC Ecuador 173: es_ES Spain 174: es_GI GI 175: es_GQ Equatorial Guinea 176: es_GT Guatemala 177: es_HN Honduras 178: es_MA Morocco 179: es_MX Mexico 180: es_NI Nicaragua 181: es_PA Panama 182: es_PE Peru 183: es_PH Philippines 184: es_PR Puerto Rico 185: es_PY Paraguay 186: es_SR Suriname 187: es_SV El Salvador 188: es_US United States 189: es_UY Uruguay 190: es_VE Venezuela 191: et_EE Estonian Estonia 192: eu_ES Basque Spain 193: eu_FR France 194: fa_IR Persian Iran 195: fi_FI Finnish Finland 196: fj_FJ Fiji Fiji 197: fo_FO Faroese FO 198: fr_AD French Andorra 199: fr_BE Belgium 200: fr_BF Burkina Faso 201: fr_BI Burundi 202: fr_BJ Benin 203: fr_CA Canada 204: fr_CF Central African Republic 205: fr_CG Congo 206: fr_CH Switzerland 207: fr_CI C?te d'Ivoire 208: fr_CM Cameroon 209: fr_DJ Djibouti 210: fr_DM Dominica 211: fr_DZ Algeria 212: fr_EG Egypt 213: fr_EH Western Sahara 214: fr_FR France 215: fr_FX FX 216: fr_GA Gabon 217: fr_GD GD 218: fr_GF French Guiana 219: fr_GN Guinea 220: fr_GP Guadeloupe 221: fr_HT Haiti 222: fr_IT Italy 223: fr_KM Comoros 224: fr_LA Laos 225: fr_LB Lebanon 226: fr_LC LC 227: fr_LU Luxembourg 228: fr_MA Morocco 229: fr_MC Monaco 230: fr_MG Madagascar 231: fr_ML Mali 232: fr_MQ Martinique 233: fr_MR Mauritania 234: fr_MU Mauritius 235: fr_NE Niger 236: fr_PF French Polynesia 237: fr_PM PM 238: fr_RE RE 239: fr_RW Rwanda 240: fr_SC Seychelles 241: fr_SN Senegal 242: fr_TD Chad 243: fr_TF French Southern Territories 244: fr_TG Togo 245: fr_VN Vietnam 246: fr_VU Vanuatu 247: fr_WF WF 248: fr_YT Mayotte 249: fr_ZR Zaire 250: fy_NL Frisian Netherlands 251: ga_IE Irish Ireland 252: gd_GB Scots Gaelic United Kingdom 253: gl_ES Galician Spain 254: gn_PY Guarani Paraguay 255: gu_IN Gujarati India 256: ha_NE Hausa Niger 257: ha_NG Nigeria he Hebrew 258: hi_BD Hindi Bangladesh 259: hi_FJ Fiji 260: hi_GY Guyana 261: hi_IN India 262: hi_MU Mauritius 263: hi_SR Suriname 264: hr_BA Croatian Bosnia and Herzegovina 265: hr_HR Croatia 266: hu_HU Hungarian Hungary 267: hu_RO Romania 268: hu_SK Slovakia 269: hu_YU Yugoslavia 270: hy_AM Armenian Armenia 271: hy_AZ Azerbaijan 272: hy_GE Georgia ia Interlingua id Indonesian ie Interlingue 273: ik_GL Inupiak GL 274: in_ID Indonesian Indonesia 275: is_IS Icelandic Iceland 276: it_CH Italian Switzerland 277: it_EH Western Sahara 278: it_ER Eritrea 279: it_IT Italy 280: it_LY Libya 281: it_MC Monaco 282: it_MT Malta 283: it_SM SM 284: it_SO Somalia 285: it_VA Vatican iu Inuktitut 286: iw_IL Hebrew Israel 287: ja_JP Japanese Japan 288: ji_IL Yiddish Israel jw Javanese 289: ka_GE Georgian Georgia 290: kk_KZ Kazakh Kazakhstan 291: kl_GL Greenlandic GL 292: km_KH Cambodian Cambodia 293: kn_IN Kannada India 294: ko_KP Korean North Korea 295: ko_KR South Korea 296: ks_IN Kashmiri India 297: ku_IQ Kurdish Iraq 298: ku_IR Iran 299: ku_TR Turkey 300: ky_KG Kirghiz Kyrgyzstan 301: la_VA Latin Vatican ln Lingala 302: lo_LA Laothian Laos 303: lt_LT Lithuanian Lithuania 304: lt_LV Latvia 305: lv_LV Latvian (Lettish) Latvia 306: mg_MG Malagasy Madagascar 307: mg_YT Mayotte 308: mi_CK Maori CK 309: mi_NZ New Zealand 310: mi_TK Tokelau 311: mk_BA Macedonian Bosnia and Herzegovina 312: mk_MK Macedonia 313: mk_YU Yugoslavia 314: ml_IN Malayalam India 315: mn_MN Mongolian Mongolia 316: mo_MD Moldavian Moldova 317: mr_IN Marathi India 318: ms_BN Malay Brunei 319: ms_MY Malaysia 320: ms_SG Singapore 321: mt_MT Maltese Malta 322: my_MM Burmese Myanmar 323: na_NR Nauru NR 324: ne_BT Nepali Bhutan 325: ne_IN India 326: ne_NP Nepal 327: nl_AN Dutch Netherlands Antilles 328: nl_AW Aruba 329: nl_BE Belgium 330: nl_ID Indonesia 331: nl_NL Netherlands 332: nl_SR Suriname 333: no_BV Norwegian BV 334: no_NO Norway 335: no_SJ SJ oc Occitan om Oromo (Afan) 336: or_IN Oriya India 337: pa_IN Punjabi India 338: pa_PK Pakistan 339: pl_LT Polish Lithuania 340: pl_PL Poland 341: pl_SK Slovakia 342: ps_AF Pashto (Pushto) Afghanistan 343: ps_PK Pakistan 344: pt_AO Portuguese Angola 345: pt_BR Brazil 346: pt_CV Cape Verde 347: pt_GW Guinea-Bissau 348: pt_MO MO 349: pt_MZ Mozambique 350: pt_PT Portugal 351: pt_ST ST 352: qu_BO Quechua Bolivia 353: qu_EC Ecuador 354: qu_PE Peru 355: rm_CH Rhaeto-Romance Switzerland 356: rn_AI Kirundi Anguilla 357: rn_BI Burundi 358: ro_MD Romanian Moldova 359: ro_RO Romania 360: ru_AM Russian Armenia 361: ru_AZ Azerbaijan 362: ru_BY Belarus 363: ru_EE Estonia 364: ru_GE Georgia 365: ru_KZ Kazakhstan 366: ru_LT Lithuania 367: ru_LV Latvia 368: ru_MN Mongolia 369: ru_RU Russia 370: ru_TJ Tajikistan 371: ru_TM Turkmenistan 372: ru_UA Ukraine 373: ru_UZ Uzbekistan 374: rw_RW Kinyarwanda Rwanda 375: sa_IN Sanskrit India 376: sd_PK Sindhi Pakistan 377: sg_CF Sangho Central African Republic 378: sh_BA Serbo-Croatian Bosnia and Herzegovina 379: sh_MK Macedonia 380: sh_SK Slovakia 381: sh_YU Yugoslavia 382: si_LK Sinhalese Sri Lanka 383: sk_CZ Slovak Czech Republic 384: sk_SK Slovakia 385: sl_BA Slovenian Bosnia and Herzegovina 386: sl_SI Slovenia 387: sm_AS Samoan AS 388: sm_WS WS 389: sn_ZW Shona Zimbabwe 390: so_DJ Somali Djibouti 391: so_SO Somalia 392: sq_AL Albanian Albania 393: sq_BA Bosnia and Herzegovina 394: sr_BA Serbian Bosnia and Herzegovina 395: sr_YU Yugoslavia 396: ss_SZ Siswati Swaziland 397: st_LS Sesotho Lesotho 398: su_SD Sundanese Sudan 399: sv_FI Swedish Finland 400: sv_SE Sweden 401: sw_BI Swahili Burundi 402: sw_KE Kenya 403: sw_TZ Tanzania 404: sw_UG Uganda 405: sw_YT Mayotte 406: sw_ZR Zaire 407: ta_IN Tamil India 408: ta_LK Sri Lanka 409: ta_RE RE 410: ta_SG Singapore 411: te_IN Telugu India 412: tg_TJ Tajik Tajikistan 413: th_TH Thai Thailand 414: ti_ER Tigrinya Eritrea 415: tk_IQ Turkmen Iraq 416: tk_TM Turkmenistan 417: tl_PH Tagalog Philippines 418: tn_BW Setswana Botswana 419: to_TO Tonga Tonga 420: tr_BG Turkish Bulgaria 421: tr_CY Cyprus 422: tr_MK Macedonia 423: tr_TR Turkey ts Tsonga tt Tatar tw Twi ug Uighur 424: uk_UA Ukrainian Ukraine 425: ur_GY Urdu Guyana 426: ur_PK Pakistan 427: uz_TJ Uzbek Tajikistan 428: uz_UZ Uzbekistan 429: vi_VN Vietnamese Vietnam vo Volapuk 430: wo_GM Wolof Gambia xh Xhosa yi Yiddish 431: yo_NG Yoruba Nigeria za Zhuang 432: zh_BN Chinese Brunei 433: zh_CN China 434: zh_HK Hong Kong 435: zh_MO MO 436: zh_SG Singapore 437: zh_TW Taiwan 438: zh_VN Vietnam zu Zulu -------------- next part -------------- -------------- next part -------------- import java.util.*; public class LocaleLang { public static void main(String[] args) { String[] isoCountries = Locale.getISOCountries(); String[] isoLanguages = Locale.getISOLanguages(); Hashtable lang2ctryMapping = new Hashtable(isoLanguages.length); StringBuffer[] ctry2LangLists = new StringBuffer[isoCountries.length]; //(country: {language}+) in ISO for (int i = 0; i < isoCountries.length; ++i) { ctry2LangLists[i] = new StringBuffer(); String country = isoCountries[i]; ctry2LangLists[i].append(country + ":" ); String[] languages = Locale_getLanguagesForCountry(country); for (int j = 0; j < languages.length; ++j) { String language = languages[j]; ctry2LangLists[i].append(" " + language); } } //DisplayCountry (country: {language}+) // {DisplayLanguage}+ for (int i = 0; i < isoCountries.length; ++i) { String country = isoCountries[i]; System.out.print(rightJustified(""+(i+1), 3) + ": "); System.out.print(new Locale("", country).getDisplayCountry()); System.out.println(" (" + ctry2LangLists[i] + ")"); String[] languages = Locale_getLanguagesForCountry(country); for (int j = 0; j < languages.length; ++j) { String language = languages[j]; System.out.println(" " + new Locale(language, country).getDisplayLanguage()); Vector lang2CtryVec = (Vector) lang2ctryMapping.get(language); if (lang2CtryVec == null) { lang2CtryVec = new Vector(); } lang2CtryVec.addElement(country); lang2ctryMapping.put(language, lang2CtryVec); } System.out.println(); } //language1_country1 DisplayLanguage1 DisplayCountry1 //language1_country2 DisplayCountry2 //... int cnt = 0; for (int i = 0; i < isoLanguages.length; ++i) { String lang = isoLanguages[i]; Vector lang2CtryVec = (Vector) lang2ctryMapping.get(lang); if (lang2CtryVec == null) { System.out.print(" " + lang + " "); String dispLang = new Locale(lang, "").getDisplayLanguage(); System.out.println(dispLang); System.out.println(); } else { for (int j = 0; j < lang2CtryVec.size(); ++j) { System.out.print(rightJustified(""+(++cnt), 3) + ": "); String ctry = (String) lang2CtryVec.elementAt(j); System.out.print(lang + "_" + ctry + " "); String dispLang = ""; if (j == 0) { dispLang = new Locale(lang, ctry).getDisplayLanguage(); } System.out.print(leftJustified(dispLang, 15) + " "); System.out.println(new Locale(lang, ctry).getDisplayCountry()); } System.out.println(); } } } //main private static String leftJustified(String str, final int len) { return justified(str, len, true); } private static String rightJustified(String str, final int len) { return justified(str, len, false); } private static String justified(String str, final int len, boolean left) { StringBuffer sb = new StringBuffer(str); final int size = str.length(); for (int i = 0; i < (len - size); ++i) { if (left) { sb.append(" "); } else { sb.insert(0, " "); } } return sb.toString(); } private static Hashtable ctry2LangMapping = null; private static final String compressedCtry2LangMapping = "ADfresAEarenAFpsAGenAIrnALsqAMhyruANnlenAOptAResASensmATdeAUenAWnlenAZazhyru" + "BAsrshhrslmksqBBenBDbnhibhenBEfrnldeBFfrBGbgtrBHarenBIrnfrswBJfrBMenBNmsenzh" + "BOesayquBRptBSenBTdzenneBVnoBWentnBYberuBZenesCAenfrCCenCFfrsgCGfrCHfrdeitrm" + "CIfrCKmienCLesCMenfrCNzhboCOesCResCUesCVptCXenCYeltrenCZcsskDEdeDJarfrsoDKda" + "DMenfrDOesDZarfrECesquEEetruEGarenfrEHarfritERamtiarenitESeseucaglETamaren" + "FIfisvFJenfjhiFKenFMenFOfodaFRfreubrcoFXfrGAfrGBengdcyGDenfrGEkahyruGFfrGHen" + "GIenesGLdaikklGMenwoGNfrGPfrenGQesGRelGTesGUenGWptGYenhiurHKzhenHNesHRhrHTfr" + "HUhuIDinennlIEengaILiwarjiINhienguknksmlmrneorpasatateIOenIQarkutkIRfaarku" + "ISisITitfrdeJMenJOarJPjaKEenswKGkyKHkmKIenKMfrarKNenKPkoKRkoKWarenKYenKZkkru" + "LAlofrLBarenfrLCenfrLIdeLKtasienLRenLSstenLTltruplLUfrdeLVlvltruLYarenit" + "MAarfresMCfrenitMDmorobgMGmgenfrMKmkshtrMLfrMMmyMNmnruMOzhptMQfrMRarfrMSen" + "MTmtenitMUenfrhiMWenMXesMYmsenMZptNAenafdeNEfrhaNFenNGenhayoNIesNLnlfyNOno" + "NPneNRnaenNUenNZenmiOMarenPAesenPEesquayPFfrPGenPHentlesPKurenpspasdPLplPMfren" + "PNenPResenPTptPWenPYesgnQAarenREfrtaROrohuRUruRWenfrrwSAarSBenSCenfrSDarsu" + "SEsvSGzhenmstaSHenSIslSJnoSKskhuplshSLenSMitSNfrSOarenitsoSRnleneshiSTptSVes" + "SYarSZenssTCenTDfrarTFfrTGfrTHthTJtgruuzTKenmiTMtkruTNarTOentoTRtrkuTTenTVen" + "TWzhTZenswUAukruUGenswUMenUSenesUYesUZuzruVAlaitVCenVEesVGenVIenVNvizhfr" + "VUenfrbiWFfrWSensmYEarYTfrmgswYUsrshmkhuZAafenZMenZRfrswZWensn"; private static String[] Locale_getLanguagesForCountry(String country) { // To save on the size of a static array in the .class file, we keep the // data around encoded into a String. The first time this function is called, // the String s parsed to produce a Hashtable, which is then used for all // lookups. if (ctry2LangMapping == null) { ctry2LangMapping = new Hashtable(); int i = 0; int j; while (i < compressedCtry2LangMapping.length()) { String key = compressedCtry2LangMapping.substring(i, i + 2); i += 2; for (j = i; j < compressedCtry2LangMapping.length(); j += 2) if (Character.isUpperCase(compressedCtry2LangMapping.charAt(j))) break; String compressedValues = compressedCtry2LangMapping.substring(i, j); String[] values = new String[compressedValues.length() / 2]; for (int k = 0; k < values.length; k++) values[k] = compressedValues.substring(k * 2, (k * 2) + 2); ctry2LangMapping.put(key, values); i = j; } } String[] result = (String[])ctry2LangMapping.get(country); if (result == null) result = new String[0]; return result; } } From norbertschade at oaktech.com Thu Apr 26 10:15:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> color brainstorming Message-ID: <009f01c0ce5b$68eecc40$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010426/f5296f6e/NorbertSchade-0001.vcf From Dale.Hubbard at AgfaMonotype.com Thu Apr 26 13:03:08 2001 From: Dale.Hubbard at AgfaMonotype.com (Hubbard, Dale) Date: Wed May 6 14:05:12 2009 Subject: UPD> color brainstorming Message-ID: In an ICC work flow the profile should say it all, but all data which identifies the specific situation in which the profile was made is welcome. Indeed stuff like dithering style, gamma, resolution, etc. Also I think it would be nice to add a ID (like a checksum) in both profile and data, so that a check is possible whether the profile matches its use. This may also be used as an ID to find the profile. ____________________________________________________ Dale Hubbard Director of OEM Product Development and Support Agfa Monotype Corporation 200 Ballardvale Street Wilmington, MA 01887-1069 Tel: 978-284-7091 Fax: 978-657-8268 e-mail: dale.hubbard@agfamonotype.com -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, April 26, 2001 10:16 AM To: UPD group Subject: UPD> color brainstorming I have started cleaning our current dtd for better preparation of color support. We need to do some more investigation, what kind of information we want to save and what information an IHV would make public anyhow, as everybody can read an XML file easily. So I intend a two-days brainstorming (today and tomorrow). Please contribute what you would like to see for color support and get your experts involved. I am looking for a simple, informal list of features (dithering matrixes, gamma correction formula, ICC file support and things like that). Hoping to get some feedback, I may do a sample implementation in our dtd structure over the week-end, which then can be discussed by some better experts than I am. But then they have something to start from. Just start throwing simple, short emails in with the subject 'color ideas'. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010426/dc8d7dda/attachment-0001.html From norbertschade at oaktech.com Mon Apr 30 15:20:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> manual duplex Message-ID: <001101c0d1aa$ac18b600$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010430/abc40c99/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Apr 30 15:31:01 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> watermarks Message-ID: <000d01c0d1ac$16da9de0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010430/f85db863/NorbertSchade-0001.vcf From sommer at granitesystems.com Mon Apr 30 19:53:50 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:12 2009 Subject: UPD> driver features In-Reply-To: <001101c0d1aa$ac18b600$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010430195011.0095c570@mailbox.bellatlantic.net> I agree that manual duplex and watermarks are driver features so they probably don't need to be specified in the UPDF. I would put N-Up in this category too. You can argue that some printers implement N-Up with a command, but some printers may do watermarks with a command as well. If a printer did implement watermarks or N-Up it would probably be with a PJL (or some other job language) command and therefore could probably be specified using one of the generic job language controls. Jim At 4/30/01 03:20 PM, Norbert Schade wrote: >Do we all agree that this is a pure driver feature, which we do not >describe in our format? >It's not as trivial, as it looks, as this feature has a number of >constraints and quite some user interface issues. But I'd like to stay >away from it, unless that is a real showstopper for somebody. > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010430/31f21125/attachment-0001.html From norbertschade at oaktech.com Tue May 1 10:39:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> locales Message-ID: <007401c0d24c$820b25d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/5de73cf4/NorbertSchade-0001.vcf From norbertschade at oaktech.com Tue May 1 11:19:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> duplex Message-ID: <001101c0d252$2dc54c70$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/c9ddaff1/NorbertSchade-0001.vcf From hastings at cp10.es.xerox.com Tue May 1 14:46:58 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:12 2009 Subject: UPD> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Message-ID: <918C79AB552BD211A2BD00805F15CE8504F78EA7@x-crt-es-ms1.cp10.es.xerox.com> Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From norbertschade at mediaone.net Tue May 1 19:29:51 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> Print Media Handling 010501 Message-ID: <001901c0d296$9f298680$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15105 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/516c9bc7/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 14775 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010501/516c9bc7/UPDFEntities-0001.obj From hastings at cp10.es.xerox.com Wed May 2 01:11:50 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:12 2009 Subject: UPD> RE: MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10-12 PDT (1-3 EDT) Message-ID: <918C79AB552BD211A2BD00805F15CE8504F78EF1@x-crt-es-ms1.cp10.es.xerox.com> I've received a number of private rankings for these 5 methods, so if any of you would prefer to just reply (NOT REPLY ALL) and send your preferences to me, instead of sending to the IPP DL, I'll combine all that I receive for the telecon. Thanks, Tom -----Original Message----- From: Hastings, Tom N Sent: Tuesday, May 01, 2001 11:47 To: ipp (E-mail) Cc: UPDF WG (E-mail); UPnP Print and Imaging WG (E-mail); Melinda Grant (E-mail) Subject: MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10-12 PDT (1-3 EDT) Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From don at lexmark.com Wed May 2 01:04:01 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:12 2009 Subject: UPD> Re: IPP> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Message-ID: <200105020510.BAA10334@interlock2.lexmark.com> We don't need any more alternatives. We need to close this NOW! ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * * * Director, Alliances and Standards * * Lexmark International * * 740 New Circle Rd C14/082-3 * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Hastings, Tom N" on 05/01/2001 02:46:58 PM To: "ipp (E-mail)" cc: "UPDF WG (E-mail)" , "UPnP Print and Imaging WG (E-mail)" , "Melinda Grant (E-mail)" (bcc: Don Wright/Lex/Lexmark) Subject: IPP> MED - telecon to decide on PWG Media Size syntax, Wed, May 2, 10- 12 PDT (1-3 EDT) Sorry for the posting to the many lists, but Ron and I as editors of the PWG Media Standardized Names standard want to reach consensus on the syntax for the dimensions at the telecon tommorrow, Wednesday, May 2. At last week's UPnP Imaging WG meeting in Portland it was agreed to use the PWG Media Standardized Names standard for additional value of the MediaType and MediaSize parameters of the CreateJob action, so we need to finish the PWG Media standard. Since there has not been a clear consensus on any method at the PWG Media meeting last week in Portland and all of the methods have not been considered together at the same time (in Portland, we only considered methods b and c below), we'd like to list the alternatives and see if we can reach consensus. The following syntaxes have been considered or proposed over time in the following order for the Media Size Self Describing Name: a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm, na-letter_8.5x11in b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000 c. Portland decision: iso_a4_210-297, na_letter_8.5-11 d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400 e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in Are there any other alternatives that we should add to the list? If you cannot attend the telecon, please send your rankings of these five methods to the ipp mailing list (see To: field above which is: ipp@pwg.org), in order not to flood people's email. In addition to ranking, please indicate any methods that you feel strongly in favor of or strongly against as well. Here are the telecon details: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# If you want to read the details of the PWG meeting last week on the PWG Media Standardized Names standard, see: ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.doc ftp://ftp.pwg.org/pub/pwg/media-sizes/media-name-minutes-010424.pdf Tom and Ron -----Original Message----- From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com] Sent: Monday, April 30, 2001 14:36 To: 'IETF-IPP' Subject: IPP> ADM - IPP Phone Conference on Wednesday, May 2. All, We will hold our next IPP Phone Conference on Wednesday, May 2. Main agenda points is to inform about the outcome of the PWG meeting last week. This means that we will review and continue discussion of the Media document, see input to PWG meeting last week plus minutes distributed by Tom Hastings last Friday. We will also review what happened in the IPP Fax meeting. Here is the dial-in information: Time: May 2, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST) Phone: 1-712-271-0309 (8*534-8273 for Xerox folks) Passcode: 98099# Carl-Uno Carl-Uno Manros Manager, Print Services Xerox Architecture Center - Xerox Corporation 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 Phone +1-310-333 8273, Fax +1-310-333 5514 Email: manros@cp10.es.xerox.com From norbertschade at oaktech.com Fri May 11 12:48:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> Fw: short cuts/ hot keys Message-ID: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> We need a little more input for that. Do we want it done as an attribute of a Locale_Element, which would be the right place? Do we want to specify a position within a UI string or do we want to enter the character for the hot key? If we specify hot keys, we certainly will not do it within the UI string (like adding a '&'). Please make a simple statement. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Monday, April 23, 2001 4:15 PM Subject: short cuts Do we want to support the definition of short cuts in the UI (e.g. select orientation control by pressing Alt+o)? Some may say that's historic, some may insist it's mandatory, some may say it's not up to UPDF to tell. I tend to belong to the first group, as everybody has a mouse by now. In some cases I work with the keyboard to be faster. But then I use tab and arrow keys. But I don't think it would be much of a deal to implement it. It would be part of a LocaleElement in the locale dtd. Comments? Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/842053d5/attachment-0001.html From norbertschade at oaktech.com Fri May 11 12:55:23 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> Parameter converter in UI strings Message-ID: <002501c0da3b$2ba0fbb0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/24073506/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri May 11 13:15:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> new device description Message-ID: <004301c0da3d$fd49b420$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/a277cc6d/NorbertSchade-0001.vcf -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 16902 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/a277cc6d/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml From norbertschade at oaktech.com Fri May 11 14:42:48 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> latest new device description Message-ID: <003101c0da4a$2ce64f20$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010511/97771594/NorbertSchade-0001.vcf From sommer at granitesystems.com Fri May 11 14:52:15 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:12 2009 Subject: UPD> Parameter converter in UI strings In-Reply-To: <002501c0da3b$2ba0fbb0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511144935.00967100@mailbox.bellatlantic.net> I have concerns about the performance impact of having to scan for dynamic changes every time something in the UI changes. The UI code could build tables to keep track of where dynamic strings exist but this seems like a lot of work just so someone doesn't have to create a few more UPDF localized strings. Jim At 5/11/01 12:55 PM, Norbert Schade wrote: >The Name_ID in the technical description is providing the reference to the >Locale_Element in the locale file. >In many cases the Locale_Element shows a term, which is to be shown >unproved in the UI. >Especially when there is a chance to specify only one record with a >formula for a feature instead of many records with single entries, it >seems very useful to be able to have the Parameter Converter (in case you >are not too familiar with it: the Parameter Converter helps converting >formulas to real entries) help to build the UI string. >Samples could be copies, zooming percentage, resolution, etc. >We are a little concerned about performance, as this has to happen >dynamically every time. >Let's discuss that on the distributor. Send your opinion to the group. > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/c38c791d/attachment-0001.html From sommer at granitesystems.com Fri May 11 14:54:57 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:12 2009 Subject: UPD> Fw: short cuts/ hot keys In-Reply-To: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511145225.00964320@mailbox.bellatlantic.net> I think each locale element should have an optional attribute for the keyboard short cut key. In the Windows world this is a standard feature and it shouldn't be up to the UI code to figure it out. I vote for an element that specifies the character that is to be the keyboard short cut. This allows the string writer to see which keys are being used as short cuts and avoid duplicates. Jim At 5/11/01 12:48 PM, you wrote: >We need a little more input for that. >Do we want it done as an attribute of a Locale_Element, which would be the >right place? >Do we want to specify a position within a UI string or do we want to enter >the character for the hot key? >If we specify hot keys, we certainly will not do it within the UI string >(like adding a '&'). >Please make a simple statement. >Regards >Norbert Schade > >----- Original Message ----- >From: Norbert Schade >To: UPD group >Sent: Monday, April 23, 2001 4:15 PM >Subject: short cuts > >Do we want to support the definition of short cuts in the UI (e.g. select >orientation control by pressing Alt+o)? >Some may say that's historic, some may insist it's mandatory, some may say >it's not up to UPDF to tell. > >I tend to belong to the first group, as everybody has a mouse by now. In >some cases I work with the keyboard to be faster. But then I use tab and >arrow keys. >But I don't think it would be much of a deal to implement it. >It would be part of a LocaleElement in the locale dtd. > >Comments? > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010511/13c468a7/attachment-0001.html From sommer at granitesystems.com Fri May 11 15:02:06 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:12 2009 Subject: UPD> Fw: short cuts/ hot keys In-Reply-To: <4.2.0.58.20010511145225.00964320@mailbox.bellatlantic.net> References: <001901c0da3a$293b89e0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010511150109.0095e8f0@mailbox.bellatlantic.net> I meant an attribute, not an element, that specifies the keyboard short cut. Jim At 5/11/01 02:54 PM, Jim Sommer wrote: >I think each locale element should have an optional attribute for the >keyboard short cut key. In the Windows world this is a standard feature >and it shouldn't be up to the UI code to figure it out. > >I vote for an element that specifies the character that is to be the >keyboard short cut. This allows the string writer to see which keys are >being used as short cuts and avoid duplicates. > >Jim From norbertschade at mediaone.net Mon May 14 12:04:23 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> new dtd version Message-ID: <000d01c0dc8f$8b2ba020$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15532 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 17187 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 15063 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010514/dc67f630/UPDF-0001.obj From norbertschade at oaktech.com Tue May 15 10:41:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> device resolution Message-ID: <001d01c0dd4d$12e4aad0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/37b6e295/NorbertSchade-0001.vcf From norbertschade at mediaone.net Tue May 15 19:59:21 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> positioning Message-ID: <000d01c0dd9b$10298600$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 15902 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 15041 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 8150 PCL5e.xml Type: text/xml Size: 17210 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010515/4f32211a/UPDFDeviceDescription-HPLaserJet8150PCL5e-0001.xml From hamzy at us.ibm.com Tue May 22 14:37:10 2001 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:12 2009 Subject: UPD> Ledger vs Tabloid Message-ID: Hello, The developer of apsfilter noticed a problem with Ledger and Tabloid forms. The UPDF document says that Ledger is 11x17. I have searched the web and noticed that there are three sets of beliefs. - Ledger is 11x17 - Ledger is 17x11 - Ledger is the same as Tabloid. and vice versa for Tabloid. There seems to be a lot of confusion. Ghostscript defines Ledger as 17x11 while Omni defines it as 11x17. Do any of you have any history on Ledger or Tabloid? Please reply directly as I am not subscribed to the mailing list. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at oaktech.com Thu May 31 14:26:21 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> start of UPDF sample implementation Message-ID: <001f01c0e9ff$315091f0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/8073df36/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu May 31 17:56:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:12 2009 Subject: UPD> changes in latest version from today Message-ID: <010901c0ea1c$9da08320$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/71303a2e/NorbertSchade-0001.vcf From norbertschade at mediaone.net Thu May 31 21:03:34 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> latest version of dtd and xml files Message-ID: <001f01c0ea36$af05cb60$f2755b18@ne.mediaone.net> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: application/octet-stream Size: 13078 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDF-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF CommandSequences.dtd Type: application/octet-stream Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFCommandSequences-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: application/octet-stream Size: 2112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFConstraints-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Configuration-HP LaserJet 9000.xml Type: text/xml Size: 913 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceConfiguration-HPLaserJet9000-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Device Description-HP LaserJet 9000 PCL5e.xml Type: text/xml Size: 15975 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceDescription-HPLaserJet9000PCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF DeviceConfiguration.dtd Type: application/octet-stream Size: 1339 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFDeviceConfiguration-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: application/octet-stream Size: 17153 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFEntities-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF FontHandling.dtd Type: application/octet-stream Size: 11480 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFFontHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 1139 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-deDE-HP LaserJet.xml Type: text/xml Size: 1858 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale-deDE-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale-enUS-HP LaserJet.xml Type: text/xml Size: 4861 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFLocale-enUS-HPLaserJet-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Option Configuration-HP Duplexing Unit PCL5e.xml Type: text/xml Size: 758 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFOptionConfiguration-HPDuplexingUnitPCL5e-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF OptionConfiguration.dtd Type: application/octet-stream Size: 1283 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFOptionConfiguration-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: application/octet-stream Size: 15027 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFPrintMediaHandling-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Command Sequences-HP LaserJet PCL5e.xml Type: text/xml Size: 2614 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010531/3af301ef/UPDFCommandSequences-HPLaserJetPCL5e-0001.xml From hastings at cp10.es.xerox.com Mon Jun 4 16:20:08 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:13 2009 Subject: UPD> Ledger vs Tabloid Message-ID: <918C79AB552BD211A2BD00805F15CE8504F799E9@x-crt-es-ms1.cp10.es.xerox.com> Mark, I'm guessing that Ledger is a landscape oriented medium, since a ledger is typically viewed landscape, while a tabloid (newspaper) is viewed portrait. I've also seen the conventions on boxes of paper in which the difference between 11x17 and 17x11 is significant: when it has fanfold tear off tractor feed holes. The 17x11 is landscape paper, with the fanfold separations being along the long (17 inch side). Note: in our PWG Media Size standard, we are NOT making a distinction between portrait and landscape media sizes, but are depending on something else to include the orientation when it is significant. Tom -----Original Message----- From: Mark Hamzy [mailto:hamzy@us.ibm.com] Sent: Tuesday, May 22, 2001 11:37 To: upd@pwg.org Subject: UPD> Ledger vs Tabloid Hello, The developer of apsfilter noticed a problem with Ledger and Tabloid forms. The UPDF document says that Ledger is 11x17. I have searched the web and noticed that there are three sets of beliefs. - Ledger is 11x17 - Ledger is 17x11 - Ledger is the same as Tabloid. and vice versa for Tabloid. There seems to be a lot of confusion. Ghostscript defines Ledger as 17x11 while Omni defines it as 11x17. Do any of you have any history on Ledger or Tabloid? Please reply directly as I am not subscribed to the mailing list. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From hastings at cp10.es.xerox.com Mon Jun 4 17:07:58 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:13 2009 Subject: UPD> changes in latest version from today Message-ID: <918C79AB552BD211A2BD00805F15CE8504F799ED@x-crt-es-ms1.cp10.es.xerox.com> Norbert, It took me quite a while to find out what you meant by "The UPDF version I put to the web today"? So I'm writing this note. First I went to the PWG web page: http://www.pwg.org/ which sent me to: http://www.pwg.org/updf/index.html The Documents link goes to version 0.51, which is two years old. Then I tried the Related Links URLs and did find the DTDs and Sample XML files. Perhaps, they could be given more prominence on the web page or renamed from "Related Links" to Current DTDs and Sample XML files", since they are the focus of the work, as I understand it. However, I'm still unable to bring up the XML files using Outlook. I get: The XML page cannot be displayed Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later. _____ Access is denied. Then I looked at ftp://ftp.pwg.org/pub/pwg/upd/ and saw no files in that directory, but did find three folders: Archive Current_Version minutes Under Current_Version I found two folders: DTD XML_Samples by the dates on those files, I suspect that they are the ones that you also attached below. However, sending out such a long list of attachments is a problem for at least two reasons: a. its a lot of data for the poor traveling folks who pick up email over hotel phone lines b. its a pain for those of us with fast connections to extract each of 15 files from our mail agents (I use Outlook). A more user friendly approach would be to simply send out the two urls: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/ ftp://ftp.pwg.org /pub/pwg/upd/Current_Version/XML_Samples/ Also if you could also put them into a single .zip file in the parent directory with a date in the file name, say: ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/ current-version-010531.zip and also send that URL. Then all of the files could be picked up in a single trip. Also XML files compress by large factors with ZIP and its easy to extract one or a bunch of files from the ZIP archive. What do others think? Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, May 31, 2001 14:57 To: UPD group Subject: UPD> changes in latest version from today The UPDF version I put to the web today has a number of improvements. We made the naming more consistent. A dot is no more allowed within a name of an element or an attribute. The dot will work as a separator when an element has to be specified by its complete or at least partial path like PrintCapabilities.Print_Features.DeviceResolutionList.DeviceResolution.Horiz ontalResolution. Some elements have got a prefix 'TBD_'. this indicates that the feature is not completely solved, under construction or it is just a reminder not to forget to work on that later. Your feedback on those features is appreciated, but it may change or even disappear during further development. We have split the locale identifier in the locale dtd now. There is a language and a separate country entry now. This allows almost every dreamable combination for the last polar bear living in the jungle. You will find that the sample data is much more consistent now, where we previously just threw in just something to show an entry. You may check the 'UI_String_xxx' references in name id attributes and the English locale as a sample. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010604/b988b877/attachment-0001.html From norbertschade at oaktech.com Wed Jun 6 14:03:09 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> heads up, XML experts Message-ID: <000d01c0eeb2$f21ba020$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010606/9536f3f8/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jun 6 14:22:37 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Ampercent Message-ID: <003701c0eeb5$a9f12ba0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010606/051331fa/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Jun 8 15:18:06 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Note 4: proper content changes after duplicating files Message-ID: <002501c0f04f$beea1b70$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010608/7900faf4/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Jun 11 14:44:43 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Note 4 of last Friday Message-ID: <001601c0f2a6$94631bf0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010611/613d6286/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jun 13 18:22:20 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: Fw: UPD> heads up, XML experts Message-ID: <001301c0f457$4fece070$551414ac@hsg.ma.oaktech.com> Friendly reminder. Can anybody help? This is important. ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:03 PM Subject: UPD> heads up, XML experts It looks as if some browsers (I use Internet Explorer) do not like XML declarations ( line starts: versions Message-ID: <000d01c0f4df$7d1a3dd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010614/c794bb50/NorbertSchade-0001.vcf From markv at us.ibm.com Thu Jun 14 19:57:11 2001 From: markv at us.ibm.com (Mark VanderWiele) Date: Wed May 6 14:05:13 2009 Subject: Fw: UPD> heads up, XML experts Message-ID: Norbert: Linux's (GNOME)LibXML does not like lines that start with (@pwg.org on 06/13/2001 05:22:20 PM Sent by: owner-upd@pwg.org To: "UPD group" cc: Subject: Fw: UPD> heads up, XML experts Friendly reminder. Can anybody help? This is important. ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:03 PM Subject: UPD> heads up, XML experts It looks as if some browsers (I use Internet Explorer) do not like XML declarations ( line starts: Fw: Ampercent Message-ID: <001901c0f5bc$fbdf5c30$551414ac@hsg.ma.oaktech.com> additional note: it has to be '&' or %H1(38). My XML Pro can read '&' as an ampercent, but insists on writing '&' when I save the command sequence file. So be careful. I'm not sure whether that is an application bug. Have mercy when I forget to change it from time to time, when I replace the files on the web page. I promise to concentrate as much as possible. Regards Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Wednesday, June 06, 2001 2:22 PM Subject: Ampercent If possible stay away from the ampercent! This limitation is due to XML. If you can't, use '&'. In the parameter converter you still could work with something like %H1(38). Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010615/51792c9c/attachment-0001.html From norbertschade at oaktech.com Fri Jun 15 13:52:28 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> driver features Message-ID: <000d01c0f5c3$f15a03d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010615/47c260e7/NorbertSchade-0001.vcf From sommer at granitesystems.com Fri Jun 15 15:56:21 2001 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:13 2009 Subject: UPD> driver features In-Reply-To: <000d01c0f5c3$f15a03d0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.2.0.58.20010615151332.009642d0@mailbox.bellatlantic.net> I would not group "Scale Patterns" and "Print Text as Black" with "Edge to Edge". Edge to edge (or full bleed) printing can not be added to a driver unless it is supported by the printer. Scale patterns, text as black, and render mode are functions implemented totally in the driver without any printer functionality. I don't think they belong in UPDF until we start addressing UI issues. Jim At 6/15/01 01:52 PM, Norbert Schade wrote: >Many drivers do not only show features, which cause any kind of command >sequence (JCL or PDL) to be sent to the printer, but provide some >settings, which change the behavior of the driver while rendering. The >driver must understand the setting, while for the generic features it just >can rely on information where to send what. >This group of features include items like 'Scale Patterns', 'Print Text as >Black', 'Edge to Edge Printing' (at the moment specified as a generic >feature - may change), 'Rendering Mode', etc. There may be more. Any >request to treat them as a group or list them at specific places? > >Another group includes entries for 'Width' or 'Height' like used in a >custom size dialog. Proposals here? > >The last group on my list includes pure UI elements like group boxes (may >be with titles), buttons to open another dialog, etc. We will ignore that >for now, probably completely in UPDF, level 1. Your opinion? > > >Regards >Norbert Schade >Principle Software Engineer >Host Software Group >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010615/6f03cbd1/attachment-0001.html From norbertschade at oaktech.com Fri Jun 15 15:59:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> summer schedule Message-ID: <005401c0f5d5$c1045660$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010615/079570b3/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Jun 18 11:14:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> connectors and extensible configuration Message-ID: <004e01c0f809$691a0180$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010618/d31c02e7/NorbertSchade-0001.vcf From norbertschade at oaktech.com Tue Jun 19 17:04:39 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> UPDF Functional Specification on UPDF web site Message-ID: <001101c0f903$74626f00$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010619/c00e7e55/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jun 20 13:08:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> UPDF Functional Specification Message-ID: <000d01c0f9ab$a3ad6eb0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010620/d7d6b97a/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Jun 21 10:25:24 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> EventHandlers Message-ID: <001201c0fa5e$026b2520$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010621/9b07699e/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Jun 22 10:18:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> merged ID list names, documentation style Message-ID: <003301c0fb26$44780820$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010622/471d68d6/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Jun 22 17:37:52 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> keeping up appearances Message-ID: <001101c0fb63$9724cf80$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010622/f39b00d5/NorbertSchade-0001.vcf From norbertschade at oaktech.com Tue Jun 26 16:09:42 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Movement from DTD to Schema Message-ID: <002301c0fe7b$f02ff080$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010626/3993a2d8/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jun 27 12:13:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> schema formats Message-ID: <006a01c0ff24$23d8a500$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010627/72d3f910/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jun 27 14:03:28 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> will schemas be implemented soon? Message-ID: <001701c0ff33$781e4ac0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010627/5fafc421/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Jun 28 13:54:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Connectors Message-ID: <007901c0fffb$63f245b0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010628/c1253e8a/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Jun 29 14:31:51 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Toronto: preliminary agenda Message-ID: <000d01c100c9$c3d160f0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010629/df426471/NorbertSchade-0001.vcf From peter.mcgregor at okiuk.co.uk Sun Jul 1 20:01:33 2001 From: peter.mcgregor at okiuk.co.uk (peter.mcgregor@okiuk.co.uk) Date: Wed May 6 14:05:13 2009 Subject: UPD> Peter McGregor/OEL/OKI_DATA_CORP/OKI_ELECTRIC/US is out of the office. Message-ID: <000357A5.N22183@okiuk.co.uk> I will be out of the office from 26/06/2001 until 18/07/2001. I will review all email on my return. From norbertschade at oaktech.com Fri Jul 6 17:57:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> Font specification Message-ID: <004201c10666$9ca78660$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010706/cf8625b6/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Jul 12 16:51:44 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:13 2009 Subject: UPD> constraints -> interdependencies Message-ID: <001d01c10b14$75f81a90$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010712/d0af50ed/NorbertSchade-0001.vcf From hastings at cp10.es.xerox.com Mon Jul 16 13:29:15 2001 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:14 2009 Subject: UPD> constraints -> interdependencies Message-ID: <918C79AB552BD211A2BD00805F15CE850532CCF1@x-crt-es-ms1.cp10.es.xerox.com> I like the terminology change from "constraints" to "interdependencies". The new term is much clearer what is meant, since the concept is about the relationship between the values of several attributes, not the list of possible values for a single attribute. Thanks, Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, July 12, 2001 13:52 To: UPD group Subject: UPD> constraints -> interdependencies In the sample implementation group we are close to constraints handling. That is the right time to make a simple change I've in mind for quite a while. We will change the wording in the whole constraints area. To speak of 'constraints' the way we do it is not correct. Constraints are describing the available entries of a list or so. See some of the XML tools. The term is exactly used in that way. So other than the fact we are doing it wrong, it is also confusing. >From now on we speak of interdependencies between features and mean the same as before. This will require some renaming of files, elements and attributes, not to speak of the documentation. In ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/ you can find a temporary documentation document 'UPDF Constraints.doc'. This is supposed to disappear soon, while the content is moving to the 'UPDF Functional Specification' (the big document growing these days step by step). In this final document it will be referred to as interdependencies only. We are not changing any structure nor any other design rules because of this. It's only a name change! I will start with the changes on Monday, 7/16/01. If you have any concern, let me know before. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010716/2a6903f8/attachment-0001.html From norbertschade at oaktech.com Tue Jul 17 14:20:50 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> Interdependencies Message-ID: <013001c10eed$356fc540$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010717/ebd5e7dd/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jul 18 12:53:51 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> Parameters in command sequences Message-ID: <00f001c10faa$38d1e020$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/c73bb2c1/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jul 18 17:14:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> color planes Message-ID: <006001c10fce$a00fe380$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/7713bc4e/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Jul 18 18:14:49 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> generic features and generic PDL output Message-ID: <00ac01c10fd7$0f5b6e00$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010718/caa99b68/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Jul 23 12:29:02 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> update of web site: Interdependencies, device fonts, docu Message-ID: <002b01c11394$95357280$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010723/bc9c04b6/NorbertSchade-0001.vcf From norbertschade at mediaone.net Tue Jul 24 20:34:13 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> Fw: UPDF introduction in 10 minutes Message-ID: <001401c114a1$8b2f2f20$f2755b18@ne.mediaone.net> Some time ago I proposed five additional marketing documents, which might be added to the UPDF web site. Candidates are: 1. The idea of UPDF. I have a small rough document available, which is not exactly on the level I'd like to see it and has to be reviewed. I'll bring with me to Toronto. I asking for help to do this. 2. UPDF introduction in 10 minutes. Find a proposal below. Except some typos I think this is my final proposal. I am asking for comments and editor's review from the field. 3. Comparison between GPD and UPDF. I am asking for help here. 4. Comparison between PPD and UPDF. I am asking for help here. 5. How to build your own UPDF description from an existing sample. Perhaps someone from the sample implementation group could do that, so that we have some different view how to do the task. All documents are supposed to be short (like two to four pages). We do not want to provide indepth information for every detail, but give a newcomer a chance to get the required information as compressed as possible. All documents have to be final before the fall conference. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: Norbert Schade Sent: Tuesday, July 24, 2001 8:00 PM Subject: UPDF introduction in 10 minutes UPDF (Universal Printer Description Format) is a data driven concept, which provides input parameters drivers need to render and output printer data. Q.: Is UPDF is new idea? A.: No, there are a other concepts, which try to accomplish a similar target. 1. There is PPD. This is a PostScript specific concept. In the view of many printer manufacturers and driver developers it has not evolved to nowadays needs. PPD are not based on XML. PPD do not support Unicode. Font handling is described outside the format. 2. GPD This is a Microsoft specific concept, which is dedicated to Microsoft platforms. GPD are not based on XML. GPD do not support Unicode. Font handling is described outside the format. 3. Proprietary formats. There are a number of company proprietary formats, which are all dedicated to a specific platform or driver system. Q.: So why UPDF? A.: UPDF describes all data a generic driver for enterprise printers needs. 1. The concept is based on XML. 2. It supports Unicode. 3. It is platform independent. Q.: What makes UPDF outstanding against other concepts? A.: It provides some core architecture, which allows the required complexity and flexibility. 1. There are the four pillars of UPDF. 1.1. The Parameter Converter. To be able to describe text based printer data as well as binary one, it needs a special syntax. The Parameter Converter is the solution for that, as it can describe text based and binary data, the reference to driver keywords, the reference to UPDF keywords and even conditional output. This functionality is not only used to specify PDL data, but is used all over the place in UPDF attributes. 1.2. Interdependencies. Interdependencies can easily be converted from other data concepts. The UPDF functionality is exceeding, as it allows more complex conditions by support of 'AND' and 'OR' combinations. It also allows other actions than just filtering like specifying conditional user interface messages. 1.3. Event handlers. The order of command sequences in different PDL differs. Event handlers allow specifying a large number of print events including Job start/end, PDL start/end as well as some feature specific events like the description of a raster graphic print sequence. 1.4. Composite features. Basic features like media size, media source, device resolution, etc. can be arbitrarily be assembled to composite features to allow the specification of high level features. Samples include predefined settings for subdialogs or driver defaults. 2. A driver default per locale is supported. 3. Device fonts are supported. 4. Localized user interface strings as well as messages are supported. 5. Extensible configuration. UPDF is prepared to describe devices and installable options known at the time the device is going to be launched as well as installable options, which will be launched at a later date. The device description can grow with the availability of installable options without the need of changing the original device description. 6. User group policies. Supervisors and system administrators are always looking for chances to specify user or user group specific descriptions on top of the device description. This includes driver settings different from driver defaults as well as additional features (based on the composite features functionality) to determine the appearance of driver features. This functionality allows presetting certain features or hiding certain features completely for certain users. Q.: Where will UPDF device description be available? A.: Because of its platform independency the description can be provide on storage media like CD or on web site and even in the device itself. Q.: When will UPDF be available to the public? A.: UPDF, level 1, is supposed to be introduced to the public in late fall 2001. Q.: Where can I get information about the current level of UPDF? A.: People interested in the current level can always look at the UPDF web site. The UPDF standard is embraced by the PWG (Printer Working Group) and can be accessed from www.pwg.org in the Internet. 1. UPDF is currently based on DTD (Document Type Definitions). That may change to schemas in the near future. The current level of dtd files can be accessed from ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/ 2. A UPDF reference sample with a XML description can be accessed from ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/XML_Samples/ 3. A functional specification documentation is growing these days. The current level can always be accessed from the UPDF web site. A direct link is ftp://ftp.pwg.org/pub/pwg/www/updf/UPDF_Functional_Specification.pdf Q.: What is the simplified architecture of UPDF? A.: The basic architecture is determined by a small number of XML files. 1. The unit configurations. 1.1. The device unit configuration. One file per device. This is the driver's data entry point! A driver will find references to the device description file, the command sequence file as well as to all locale files plus a few attributes. 1.1. The optional unit configuration. One file per optional unit. Similar structure to the device configuration. The driver will find the references specific to an optional unit plus a few attributes. During installation this information may be moved into the device configuration or a platform specific reference may maintain this information. 2. The device description. One file per device. This is the core UPDF file providing the overall device description. You will find a number of references to command sequences and localized user interface strings. It was a learning effect for the group that it might be better to separate the real PDL command sequences from the device description as well as the localization of user interface strings and messages. This leverages the work for PDL experts and translators, as they are not confronted with an overwhelming amount of information they are not interested in when doing there job. 3. Command sequences. One file per device description. This XML file holds all the PDL command sequences. A command sequence file may hold more than the command sequences used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description. 4. Localized user interface strings. One file per locale per device description. This XML file holds all the user interface strings for features and messages. A locale file may hold more than the user interface strings used by one device description to make it reusable. This is not a problem, as the references are totally maintained by the device description. Q.: Is an UPDF description supposed to be used in its original XML form? A.: This is left to the actual implementation. By watching the ongoing implementations it looks more that the XML information is converted into some platform specific format. That provides some significant performance advantages and seems to help with platform specific implementations. This may happen during installation. Q.: How would a developer create device font data? A.: This is left to the UPDF developer. Basically someone could do that manually by filling out the proper attributes. But we are assuming that conversion tools will be written to convert data already available for device fonts supported in other data concepts. We are also in touch with the major font vendors like AGFA and Bitstream to have them develop concerters for their own databases. Q.: Are there limitations in an UPDF description? A.: Yes, there are. To be able to finish a the current level we have limited ourselves not to support certain features, as there are: 1. Palette handling. It is currently discussed, whether this is required to be supported in level 1. 2. Raster compression. This is likely not supported in level 1, but is a candidate for the next level. 3. Vector graphic. UPDF describes raster graphic for every PDL supported. A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it. 4. Font download format. UPDF may support the specification of certain download command sequences, but it is not described the structure of a download format. A driver will find exact information about the PDL supported in a device description. So if a driver supports additional functionality for certain PDL, it can securely make use of it. 5. Application flags. As applications may work differently under different platforms, this is not considered a feature of UPDF. Q.: Are there certain assumptions UPDF makes? A.: Yes, there are. The current format of UPDF includes the support of JCL (Job Control Language). The format provides a list of keywords of a JCL like PJL, but it is not specifying the syntax of that JCL. There is supposed to be a JCL specific library available on the platform, which converts the keywords into proper JCL language. This concept has been chosen, as there are platform specific components available in a number of cases, which are designed to do exactly that task, and as some newer JCL (Bluetooth, JDF) are described in XML as well. And we don't want to describe that a second time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010724/6c590090/attachment-0001.html From norbertschade at oaktech.com Thu Aug 9 15:50:18 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> UPDF dtd to XML schema conversion Message-ID: <006501c1210c$842b9f20$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010809/393cb082/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Aug 9 16:17:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> changes during schema conversion Message-ID: <007101c12110$43cd5cd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010809/99619267/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Aug 10 15:32:59 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> XML schema definitions Message-ID: <000f01c121d3$43ab9960$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010810/631add46/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Aug 15 16:39:58 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> XML schema definition the selected format Message-ID: <001d01c125ca$734110b0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010815/eb512a3a/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Aug 16 13:23:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> upcoming conferences Message-ID: <001301c12678$3af96b40$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010816/34f7d2b1/NorbertSchade-0001.vcf From don at lexmark.com Thu Aug 16 13:34:35 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:14 2009 Subject: UPD> upcoming conferences Message-ID: <200108161734.NAA13573@interlock2.lexmark.com> Currently there are no plans to have a December meeting in LA. That was tentatively cancelled several meetings ago and there have been no efforts to revive it. ********************************************** * Don Wright don@lexmark.com * * Chair, Printer Working Group * * Chair, IEEE MSC * * Member, IEEE SA Board of Governors * * Member, IEEE-ISTO Board of Directors * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** "Norbert Schade" on 08/16/2001 01:23:56 PM To: "UPD group" cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> upcoming conferences I'd like to get an overview what meetings the UPDF may have in the medium-term future. It looks, as if this is the draft plan of PWG (schedule and locations may change): October 2001 (could be Seattle) December 2001 (Los Angeles) January 2002 ( could be Hawaii) March 2002 (could be Florida) Seeing the current level of the spec and the ongoing development it seems very reasonable to me to meet in October 2001. It is not planned to meet in Los Angeles. This could change on request or if we see more companies working on host implementations. The UPDF group will not be in Hawaii. We may have one or two teleconferences in the December/January time frame instead. We'll most likely will meet in March 2002. Any comments? I'd like to give Don Wright some indications late today for his scheduling work. Regards Norbert Schade Principle Software Engineer Host Software Group Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010816/c82ac283/att1-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: application/octet-stream Size: 458 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010816/c82ac283/NorbertSchade-0001.obj From norbertschade at oaktech.com Wed Aug 22 11:11:34 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> next steps Message-ID: <000d01c12b1c$bba05490$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010822/46802a52/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Aug 23 11:05:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> enumerations and IDs Message-ID: <000f01c12be5$1b3f1a30$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010823/535d7eb4/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Aug 23 11:24:45 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> web design Message-ID: <002101c12be7$bd510d90$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010823/d7d1d542/NorbertSchade-0001.vcf From hamzy at us.ibm.com Mon Sep 10 17:17:49 2001 From: hamzy at us.ibm.com (Mark Hamzy) Date: Wed May 6 14:05:14 2009 Subject: UPD> Point Of Sale printers. Message-ID: Hello, Have you considered Point Of Sale (POS) printers in UPDF? I am looking at a technical reference for one right now and it has an interesting feature. There are two rolls of paper in this printer and you can print to them in the following ways: - Print only on the left roll. This is torn off and given to the customer. - Print on the left roll and print a duplicate to the right roll. This roll is called a "journal" roll. - Image the form size to be twice the size of the roll. Any print data that does not fit onto the left roll is overflowed and printed on the right roll. This way you can print two different things at one time. Also, the roll paper is 228 pels wide at 90 dpi. This translates into a form size of 2.5333333333333333333333333333333... inches. The length of the form can be between 1/72 of an inch to an infinite length. Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ From norbertschade at oaktech.com Mon Sep 10 18:23:30 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> Point Of Sale printers. References: Message-ID: <000b01c13a47$38974010$551414ac@hsg.ma.oaktech.com> Mark, it's some time ago that I dealt with POS printers. But some problems sound familiar. No, we haven't thought about those printers in UPDF in detail. I guess we could more or less solve the media size. Assuming we only print on the left roll, I propose a width of 2.534 inch (x 90 = 228.06 pixel), as that would provide 228 pixel after any correct rounding. 2.54 inch may result in 229 pixels after rounding. Any value below 2.534 inch (like 2.5334 or 2.53334, etc.) would be correct as well, but not result in a different number of pixels. With the length it's the old problem with rolls. Operating systems like MS Windows like to know the length upfront. So my feeling is that the only way to go is to define quite a long size (be sure that traditional solutions used in OS's or apps can report it with 16 bit; 15 bit would even be safer). But with that narrow width you should be on the safe side with 12 inch length (one of the guidelines I used was to be able to print any character size on one page, where the width kind of limits the height. You'd come to a virtual but reasonable size of custom_pos_2.534x12in . You'd need something to find out if a page is the last page - as you would need for any kind of roll handling in these OS's. And then you'd need a flag to tell to stop after printing the last line of data on the last page and not feed until page end. We do not have such a flag yet. That would be a media source specific attribute I guess. The resolution values of 90 x 72 dpi work even fine with virtual units of 7200. Not a problem. Now the real problem might be the journal. I'd expect a special application to position everything properly for the double-size paper (you wouldn't print your letter here). Being afraid that the journal is not printed by a simple copy command, the driver would have to print every data twice (please confirm). That's certainly something we haven't thought about - and will not in short-term. That's my two cents. Perhaps somebody else has a better idea. Regards Norbert Schade ----- Original Message ----- From: "Mark Hamzy" To: Sent: Monday, September 10, 2001 5:17 PM Subject: UPD> Point Of Sale printers. > Hello, > > Have you considered Point Of Sale (POS) printers in UPDF? > I am looking at a technical reference for one right now and it has an > interesting feature. > There are two rolls of paper in this printer and you can print to them in > the following > ways: > - Print only on the left roll. This is torn off and given to the > customer. > - Print on the left roll and print a duplicate to the right roll. > This roll is called a "journal" roll. > - Image the form size to be twice the size of the roll. Any print > data that does not fit onto > the left roll is overflowed and printed on the right roll. This > way you can print two > different things at one time. > > Also, the roll paper is 228 pels wide at 90 dpi. This translates into a > form size of 2.5333333333333333333333333333333... inches. The length of > the form can be between 1/72 of an inch to an infinite length. > > Mark > > Take a look at the Linux Omni printer driver at > http://www.ibm.com/linux/ltc/projects/omni/ > From norbertschade at oaktech.com Wed Sep 12 17:49:46 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> some editing Message-ID: <001b01c13bd4$d6c42990$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010912/5c580b39/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Sep 13 09:50:26 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> compatibility, appearance Message-ID: <002f01c13c5b$0aff5280$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010913/04cba41a/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 11:27:14 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> changes done so far Message-ID: <000d01c13d31$bb614350$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/78046e44/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 12:56:33 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> item 9 Message-ID: <001d01c13d3e$3537a370$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/25e91974/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 13:14:29 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> item 15 Message-ID: <000f01c13d40$b68cb300$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/303beb97/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 14:36:12 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> item 11 Message-ID: <002301c13d4c$21495f30$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/61cb1c57/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 16:11:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> item 5 Message-ID: <005301c13d59$7b7a4980$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/bfd00258/NorbertSchade-0001.vcf From norbertschade at oaktech.com Fri Sep 14 16:23:21 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:14 2009 Subject: UPD> web site updated Message-ID: <003701c13d5b$19462430$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010914/dd120ea7/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Sep 20 09:26:47 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> file update Message-ID: <001501c141d7$e5f690c0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010920/ba92d0d5/NorbertSchade-0001.vcf From jsommer at bellatlantic.net Thu Sep 20 09:28:17 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> Items 5 and 11 Message-ID: <4.3.2.7.2.20010920092331.00a90c70@mailbox.bellatlantic.net> I want to throw in my 2 cents on these. Item 5 - Parameter Converter and UI Strings It would make my life easier if we didn't use the parameter converter for UI strings but I can see the usefulness of this function. If we do allow it, I think the place for it is in the Name_ID and not the string itself. My main reason it that this keeps our locale files clean for easy translation which was the whole point of moving the UI strings to separate files in the first place Item 11 - IDs Though I appreciate the concept behind making the classifying attributes unique, I think it creates two problems. 1) The UPDF becomes less readable. For instance, media sizes and margins would be separate items and you'd have to go to a third place to find how they are related. 2) Composite Features or Interdependencies would be required to do just a simple printer description. These are powerful and very useful features and, I imagine, every printer description will use at least one of them. However, in the course of creating a printer description or driver, it will be much easier to do the device description first and verify it. After that is complete, the user interface (composite features and interdependencies) can be considered. By separating margins from media sizes, they must be connected by either a composite feature or interdependencies. So, just to get something to print correctly, these functions would have to be implemented. Also, since either function could be used, there would be no common method of relating media size with margins. I think we'd create more problems than we'd fix by eliminating the unique IDs. Jim mailto:sommer@granitesystems.com 978-486-3068 From norbertschade at oaktech.com Thu Sep 27 17:51:08 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> Decision: items 11, 12 Message-ID: <001101c1479e$83f83050$551414ac@hsg.ma.oaktech.com> The decision is that we will keep it as it is. That means we will go on with a unique attribute called 'ID' plus one or more classifying attribute with other names like 'Predefined_ID' or 'Proprietary_ID' per feature. The defaults are decided as well. We will not save classifying attribute settings, but the unique ID of a feature. I have edited the current sample and added many more defaults. No generic features yet, as that is another open item. No generic PDL output features yet, as that is another open item. All files are on our web site. Regards Norbert Schade ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Friday, September 14, 2001 2:36 PM Subject: UPD> item 11 This is a very controversary item and probably the one with the most confusion about. 1. The attribute ID currently is the attribute uniquely identifying a certain record of an element like a feature, e.g. media size or device resolution. ID has to be unique per UPDF description, but can have any form (ID_5, Norbert_s_size, 234, size80, etc.). Generally it's useless to try to interpret ID. 2. Additionally to ID we have a number of classifying attributes with technical meaning. The entries in most if not all cases follow certain rules. They can be interpreted. Samples for classifying attributes are Predefined_ID/Proprietary_ID, KB, HorizontalResolution, etc. Excerpt for Predefined_ID/Proprietary_ID I tried to explain this a number of times. I'll try again. We need a way to sometimes select from a list of predefined keywords (like coming from the standardized media names specification or from our own UPDF specification), but still be able to enter another value. This requires an editable combo box. That's not possible under the XML applications I know of. So we built a work-around by specifying one attribute Predefined_ID, where all the predefined keywords are listed, plus another attribute Proprietary_ID, where somebody can enter an arbitrary value (if we haven't defined a list of keywords, you may only see the one attribute Proprietary_ID). If a feature uses both attributes, we understand them as one merged list. To do that we add one more predefined keyword to the list called 'proprietary-media-size' (or similar). The rule is to look for the keyword in Predefined_ID, but in case that attribute shows 'proprietary-media-size' (or similar) look in Proprietary_ID. By that mechanism we have created something like an editable combo box. That's why I show the two attributes together in most cases separated by a slash. I hope you're with me so far. In my world (and believe me I know it may not represent the whole world) I would save the unique ID in my driver, whenever I save the current setting of a feature. Under Windows that's done mainly in the registry, but another mechanism wouldn't make a difference for me. To the operating system or application I would always announce classifying attributes like I'd find in Predefined_ID/Proprietary_ID for media size or in HorizontalResolution and VerticalResolution for device resolution, etc. In interdependencies I would be allowed to work with the unique ID as well as with some classifying attributes (could be discussed). Classifying attributes may make some interdependencies shorter. Classifying attributes in my view are not necessarily (but often) unique. You may have a device resolution record for a true 600 dpi and another for a FastRes (600 dpi with another PJL command). Other cases with other features can be composed. That would mean the classifying attribute the driver/client announces to the application is not necessarily unique - for me not a problem. One of the discussions is to make the classifying attributes unique (and therefore perhaps be able to let the attribute ID go completely, as it would not be needed any more as an additional identifyer). I think the key statement of this email is that I'd save and work with the unique ID in my driver, but communicate classifying ID's with the OS/application. I said earlier that this item affects item 12. We have to decide whether we want to save defaults with the unique ID or differently. Regards Norbert Schade Principal Software Engineer Advanced Development / Connectivity Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010927/640dbdb1/attachment-0001.html From norbertschade at oaktech.com Fri Sep 28 09:59:56 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> variable entries in attributes Message-ID: <002301c14825$dac30bd0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20010928/30646bc6/NorbertSchade-0001.vcf From jsommer at bellatlantic.net Fri Sep 28 12:02:16 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> variable entries in attributes In-Reply-To: <002301c14825$dac30bd0$551414ac@hsg.ma.oaktech.com> Message-ID: <4.3.2.7.2.20010928105917.00aa6bc0@mailbox.bellatlantic.net> We've done a great job of making elements and attributes consistent. As I write my UPDF parser, I've found it very easy to generalize all the print media handling selections except for copies and zooming. These two are just different so we might as well just deal with them differently and in the clearest way we can. I think we should add the elements MinimumValue, MaximumValue, IncrementValue, and CommandSequence_ID to MediaCopiesList and MediaZoomingByPercentageList. We can then delete the elements MediaCopy and MediaPercentage. Finally, MediaCopiesList should be renamed MediaCopies and MediaZoomingByPercentageList should be renamed MediaZoomingByPercentage. I agree that we should change all enums so that they use the same predefined value ("proprietary-value") to indicate that a proprietary value is provided. This is another good step towards constistency. I think defaults should be done by unique ID except for copies and zooming. A unique ID just doesn't make sense so lets just specify the integer value. Finally, I propose that we create unique names for all values we want to use with defaults and interdependencies instead of using the dot syntax we previously discussed. It accomplishes the same thing but in a much more readable format. For instance lets just say that COPIES is used to specify the default value for copies in addition to being the name used in interdependencies when checking or setting values. This list makes it clear to both the UPDF creator and the UPDF driver what can be controlled. Since I've started talking about interdependencies, I'd also like to propose that our conditions be limited to "equal" and "not equal". I believe that all conditions can still be covered this way and it will make processing the interdependencies much easier. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20010928/e84150ea/attachment-0001.html From norbertschade at oaktech.com Mon Oct 1 12:50:42 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> latest discussions Message-ID: <003e01c14a99$356d45d0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/7ae55567/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Oct 1 13:01:03 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> legal info Message-ID: <002701c14a9a$a740b7e0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/b7ed4922/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Oct 1 15:17:54 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> item 13 Message-ID: <001101c14aad$c542ede0$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/238afd43/NorbertSchade-0001.vcf From norbertschade at oaktech.com Mon Oct 1 15:31:14 2001 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> item 5 Message-ID: <003d01c14aaf$a25cd690$551414ac@hsg.ma.oaktech.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 443 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20011001/b40e8f0e/NorbertSchade-0001.vcf From don at lexmark.com Wed Oct 3 14:49:14 2001 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:15 2009 Subject: UPD> test Message-ID: <200110031849.OAA17227@interlock2.lexmark.com> test... ignore ********************************************** * Don Wright don@lexmark.com * * * * Chair, IEEE MSC * * Member, IEEE SA Board of Governors * * Member, IEEE-ISTO Board of Directors * * * * Director, Alliances & Standards * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 859-825-4808 (phone) 603-963-8352 (fax) * ********************************************** From jsommer at bellatlantic.net Thu Oct 4 11:52:13 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> Unique ID: String->Integer Message-ID: <4.3.2.7.2.20011004113947.00aa5860@mailbox.bellatlantic.net> I had been just assigning consecutive integer values to each unique ID. This worked fine but I ran into some situations (installing/uninstalling options) where the integer ID changed for a specific unique ID string. This meant that any integer ID that I had saved in the driver was no longer valid. I was looking for an algorithm to convert the unique ID strings into unique ID integers. I don't really need all ID integers to be unique, just all those in the same list (MediaSizeList, MediaTypeList, etc) need to be unique. I also need them to be consistent even if new ID's are added or some disappear. Norbert suggested the algorithm used to generate the LPTENUM checksum. I hunted down the algorithm and found that it generates unique ID integers for all the ID strings in the sample implementation. I would be a little happier if it generated 32-bit ID integers, but so far it works fine. Here's the code: WORD wCRC16a[16]={ 0000000, 0140301, 0140601, 0000500, 0141401, 0001700, 0001200, 0141101, 0143001, 0003300, 0003600, 0143501, 0002400, 0142701, 0142201, 0002100, }; WORD wCRC16b[16]={ 0000000, 0146001, 0154001, 0012000, 0170001, 0036000, 0024000, 0162001, 0120001, 0066000, 0074000, 0132001, 0050000, 0116001, 0104001, 0043000, }; short Get_CRC_CheckSum(void *pBuffer, ULONG ulSize) { BYTE *pb; BYTE bTmp; ULONG ulSeed=0; for (pb=(BYTE *)pBuffer; ulSize; ulSize--, pb++) { bTmp=(BYTE)(((WORD)*pb)^((WORD)ulSeed)); // Xor CRC with new char ulSeed=((ulSeed)>>8) ^ wCRC16a[bTmp&0x0F] ^ wCRC16b[bTmp>>4]; } return (short)ulSeed; } The seed is set to 0 each time so that the ID will always be the same for a given string. If anyone has any comments or suggestions for a 32-bit CRC, I'd be happy hear. Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Thu Oct 4 15:12:35 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> item 10 Message-ID: <4.3.2.7.2.20011004151205.00aa1d10@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Monday, October 01, 2001 5:36 PM >Subject: item 10 > >last change for today. >Like for GenericPDLOutput features we wanted to get rid of the enumerated >feature list (generic feature 1, generic feature 2, etc.). Does not look >smart, blows it up unnecessarily, you do all the same a number of times >just under slightly different names. >So we added a Feature_ID to any GenericFeatureList (corresponds to any >other feature list like MediaSizeList), which identifies the feature. Now >we can name all the lists the same, as this Feature_ID gives us the chance >to differenciate between them. >This settles item 10. Of the long list of open items we have left numbers >8, 9, 14 and 15. Looks good to me for the last days. > >Please check it out. The mother sample has been changed accordingly. >You'll find all files on the web site in some minutes. > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/e4ba0f42/attachment-0001.html From jsommer at bellatlantic.net Thu Oct 4 15:12:55 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> item 15 Message-ID: <4.3.2.7.2.20011004151241.00aa7da0@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 9:38 AM >Subject: item 15 > >I have added an attribute CompatibleUPDF to all features on the level of >the xxxList. >That means somebody can declare a complete feature compatible to another >model. >It is not possible to declare single records of a feature compatible. >It is open where this attribute should refer to. Until further notice it >holds references to other device description files (no file extension). >Feedback appreciated. > >Purpose of this attribute: >1. Printer manufacturers may build a number of UPDF descriptions, where >especially within model families features are indentical. This reference >may save some testing and QA time. >2. If a developer connects to an internal database for printer data, this >reference can be used to avoid duplicating records. > >This settles item 15 until further input on the reference. > >Item 9 is considered more or less settled, as we haven't heard anything >since Toronto though I asked a number of times. I will keep that open >until Friday this week. >That leaves us with item 8 (group licence), where we have some proposal >from IBM, and item 14 (raster graphic and event handlers). >these are anyhow issues under current development. So I will not further >refer to the item list any more. It is considered done (with the exception >of current development for items 8 and 14). > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/609913b4/attachment-0001.html From jsommer at bellatlantic.net Thu Oct 4 15:13:19 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> consistent Predefined_ID, Proprietary_ID Message-ID: <4.3.2.7.2.20011004151302.00aa0c80@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 10:26 AM >Subject: consistent Predefined_ID, Proprietary_ID > >I wonder whether it would further help us, if we'd equip all features with >Predefined_ID/Proprietary_ID. >One reason we didn't so far is that some features need to classifying >attributes for a proper description. Samples are all features, which are >mainly described depending on horizontal and vertical resolution. >There is a solution, if we want. >We could specify some simple syntax, which we can more or less borrow from >the Media Standardized Names spec. >Checking device resolution the keywords could look like 'resolution_12x12' >(still related to the virtual units like 7200). So this would represent a >600 dpi resolution. >Haven't thought about it thoroughly, but just an idea. >Eventually we could end up with classifying Predefined_ID/Proprietary_ID >attributes in all features. > >any feeling? > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/a2f25420/attachment-0001.html From jsommer at bellatlantic.net Thu Oct 4 15:13:39 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> user group policies Message-ID: <4.3.2.7.2.20011004151323.00aa71d0@mailbox.bellatlantic.net> >From: Norbert Schade >To: UPD group >Sent: Tuesday, October 02, 2001 12:51 PM >Subject: user group policies > >Now that we have solved some bugging items, we can concentrate on the >future design again. >I'd like to do an outlook on user group policies that we all together >become a bit more familiar with it. >Assuming that normally a developer of the printer manufacturer would write >the complete set of an UPDF description, the result is a neutral >description of one specific model. >A number of users, especially large enterprises, like to go a step further >and specify some needs for themselves. >These specifications are normally set by supervisors or administrators. >They create sets for single users or user groups. >1. They may like to set user specific defaults differing from the original >IHV defaults. >These defaults should become active right during installation of the >driver/client and should not need any extra step by the user. He/she >should not even notice it. >2. Another nice-to-have feature might be to manipulate the complete user >interface. That could mean either hide certain entries of a UI control, >hide some controls completely or even create new controls. > >This is the area we call user group policies. >I'm going to make some statements as the first input. Please feel free to >contradict, change and add. So far we have not specified in detail, which >of the features we will be able to accomplish in UPDF, and especially in >UPDF level 1. > >Required features >1. Special defaults. >2. UI manipulation. >2.1. Manipulate entries of UI controls. >2.2. Manipulate the appearance of UI controls. >2.3. Add new UI controls. > >The first question is where do these users get their UPDF description >from. Normally it may be stored on a storage medium (CD, etc.), on a web >site or even in the printing device. Only on a storage medium there would >be the chance for a supervisor to edit files like the device configuration >xml file to add user group policies. >So for now we make the assumption that the supervisor will create >directories per user or user group to hold all files necessary for >installation. >We further assume that the supervisor has good to excellent knowledge >about UPDF and will be responsible for the intended changes. We only can >provide the structures. > >Feature 1 >There is a rather simple solution. When all files are copied somewhere, a >supervisor can change the locale files and especially the LocaleDefault >elements. No technical problem. >Though technically possible we may not recommend to add/remove complete >locales and make the proper changes in the configuration file. >As I hate somebody changing the original UPDF files, I'd could imagine >another approach. The only modifications to the original files should be >done to the unit configuration xml files (we could prepare that in the >schemas by adding an optional element, which we and the IHV normally would >never use). If the optional element for user group policies is present, it >holds all information the driver needs. May need some thinking. But now >the supervisor is able to add his own locale references, which hopefully >have been copied from the original ones first, and refer to anything else >he/she needs. We need common rules for that. > >Feature 2.1 >Hmmm. I'm a little hesitant here. The interdependencies would be the tool >to allow something like 'if this record of this feature is selected, >select that record of another feature'. 'hide this record' might be >something else a supervisor wants to do. We do have an Appearance >attribute on the feature level, but not one on the record level. >Add a new record for a feature seems difficult as well. I only can imagine >this to work with certain composite features like a global driver setting >control feature. Would be very difficult to specify. >Additionally I guess that all original interdependencies should still >work. So a new one should not interfer with any original. That needs some >concentration, if possible at all in any case. > >Feature 2.2 >Making certain UI controls disappear completely from the UI does not seem >to be such a technical problem. >I guess the UI dimensions would still be the same. There would just be >some holes. >As every feature has a default, they all have an active setting. That rule >is not broken, when the setting would change in the background by some >interdependency. > >Feature 2.3 >New controls can only be composite features! That's the only instance >where the driver might be prepared to face controls, which meaning it does >not understand - and need not. >The only reasonable control I can think of is a 'User Specific Setting' >control, set on top of all other controls as a composite feature. >All entries would have to be handled by the supervisor, of course. We >would not interfer with any original control. >There are still a number of questions like the default for this (or these) >control(s). And should it or they be localized? > >Anyhow, whatever UI manipulation we may have in mind, my point is it has >to be done outside the original UPDF description. > >Ok, I wanted to initiate that discussion before San Antonio and show that >I have some thoughts about it. >But that's not enough to get it going. > > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011004/252ce502/attachment-0001.html From jsommer at bellatlantic.net Fri Oct 5 11:37:51 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> Orientation/Rotation Message-ID: <4.3.2.7.2.20011005113010.00a9e380@mailbox.bellatlantic.net> We currently have one element for orientation that has the possible values of: 1) Portrait 2) Landscape 3) Rotated Portrait 4) Rotated Landscape In my mind we have really created a composite feature of orientation (portrait/landscape) and rotation (off/on). Generally, orientation is a setting that an application controls and cares about so that it formats data properly. Rotation is something that the driver cares about so that the image is put on to the paper properly. If a user has a media (like 3 hole punch) that must be loaded in the printer in the rotated direction to prevent jamming, then the user will want to select rotate regardless of the orientation that may be selected within an application. I propose that we split the current orientation selection into two - orientation and rotation. Comments? Jim mailto:sommer@granitesystems.com 978-486-3068 From jsommer at bellatlantic.net Fri Oct 5 15:58:05 2001 From: jsommer at bellatlantic.net (Jim Sommer) Date: Wed May 6 14:05:15 2009 Subject: UPD> legal info Message-ID: <4.3.2.7.2.20011005155725.00aaf3d0@mailbox.bellatlantic.net> >I've asked a number of times for statements on the Toronto request for >additional attributes for specifying strings for legal info. >There was no feedback so far. >So this is off the table, until I get a carefully prepared request with >samples again. >That settles item 9. > >Regards >Norbert Schade >Principal Software Engineer >Advanced Development / Connectivity >Oak Technology, Inc. >10 Presidential Way >Woburn, MA 01801 >USA >Phone: 1-781-638-7614 >Fax: 1-781-638-7555 >email: norbertschade@oaktech.com mailto:sommer@granitesystems.com 978-486-3068 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011005/1b3a0859/attachment-0001.html From norbertschade at mediaone.net Mon Oct 15 10:42:58 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> test 10.15.01 Message-ID: <000c01c15587$afdfa4e0$f2755b18@ne.mediaone.net> please ignore Norbert Schade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011015/45c31b91/attachment-0001.html From rvandekimmenade at nl.ibm.com Tue Oct 30 05:30:49 2001 From: rvandekimmenade at nl.ibm.com (Roger J van de Kimmenade) Date: Wed May 6 14:05:15 2009 Subject: UPD> UPDF Message-ID: Hello, My name is Roger van de Kimmenade and i am currently involved in a project making a controller for print and scan engines. I want to describe the printer characteristics and resources in a generic way, using XML. I looked onto internet and came to your site. My question: Do you already have some code, to read an XML file, using the UPDF.dtd file ? Met vriendelijke groet/with kind regards, Roger van de Kimmenade BIS/EBI Regional Development Center Eindhoven IBM Global Services Beukenlaan 149, 5616 VD, Eindhoven The Netherlands Tel: (+31)(0) 20 513 1739 Email: RvandeKimmenade@nl.ibm.com From norbertschade at mediaone.net Tue Oct 30 08:14:38 2001 From: norbertschade at mediaone.net (Norbert Schade) Date: Wed May 6 14:05:15 2009 Subject: UPD> composite features Message-ID: <001201c16144$d4538bc0$60765b18@ne.mediaone.net> We have added an attribute UserExtensible to the CompositeFeature element. Default of this boolean is true. If a composite feature is user extensible the user can assemble a new ComponentSet and those can be deleted again. ComponentSet elements created by the printer manufacturer can never be deleted. I have created one small sample for 'Media' so far, just to have something to show and discuss. Two predefined media records plus one for discussion purpose. Here I mainly assign a UI string for a new media created by the end user. Where else would we get that string from? Do we need that string (and therefore the record) at all? To keep everything consistent not only generic features get an ID to identify the feature, but all predefined features as well (fixed attribute) as composite features. Regards Norbert Schade Principal Software Engineer Advanced Development / Connectivity Oak Technology, Inc. 10 Presidential Way Woburn, MA 01801 USA Phone: 1-781-638-7614 Fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20011030/6408b715/attachment-0001.html