From sandram at boi.hp.com Mon Jan 31 17:31:39 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> New Orleans meeting Message-ID: I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From charles.a.adams at opbu.xerox.com Mon Jan 31 17:56:03 2000 From: charles.a.adams at opbu.xerox.com (charles.a.adams@opbu.xerox.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> New Orleans meeting Message-ID: <2B6C906F79BCD2119D1D00805F19A10DE57385@us-wv-m13.wv.tek.com> I also have been sucked into the depths of product development/management. But as I come back up for air I would like us to talk about constraints a bit. Nothing formal just want to hear more about Norbert's work. Chuck Adams Office Printing Business ... Xerox -----Original Message----- From: Sandra Matts [mailto:sandram@boi.hp.COM] Sent: Monday, January 31, 2000 2:32 PM To: Universal Printer Driver Subject: UPD> New Orleans meeting I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From don at lexmark.com Tue Feb 1 10:17:10 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> New Orleans meeting Message-ID: <200002011558.KAA20628@interlock2.lexmark.com> Any font experts willing to present to the group some background material to get this kicked off? ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** sandram%boi.hp.com@interlock.lexmark.com on 01/31/2000 05:31:39 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> New Orleans meeting I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From nschade at xionics.com Tue Feb 1 13:48:21 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> fonts Message-ID: <000201bf6ce4$fd691990$c31343ce@gca-2.xionics.com> I would not call myself the absolute font expert, but I know this and that. I invited Bitstream on January, 13th, to Oak (formerly Xionics, most of you may have heard that the merge now is public and legal) to talk about the subject. They were interested in visiting the group. I told them about the next meetings of our group especially mentioning New York. Don and Sandra, I hope that's in your sense. They may take the chance to represent themselves. With Bob Thomas, Director of Product Management, and Rob Solomon, Director of Type Engineering, and Shawn Flynn, Senior Software Engineer, on Bitstream's side and a colleague of mine as a font expert from the embedded side plus myself we had a nice group together and could cover a lot of items in little more than an hour on the management level as well as on the technical level. I introduced PWG and especially UPDF to them and told them my ideas about a font approach (we must start somewhere). 1.) I think we should take the IFIMETRICS structure from NT and check, whether this is the right superset for general font information. This includes Panose info. 2.) We have to add character set handling and 3.) character width information. I propose we will not tell about the scaling formula for calculating single char width explicitely in our XML file. I rather would expect that we assume the driver knows about certain font formats including their scaling formulas and we just reference that in a list. 4.) The relationship of system fonts to printer resident fonts with the complexity of font substitution unfortunately is another item in this area. I explained that I want us to investigate SVG and their font description more before we decide on a spec. Bitsteam generally agreed on all of that. They may even be interested to think about a tool to provide a XML file per font (only newer ones) shipped by Bitstream to be included easily into a complete UPDF. But that depends on how sophisticated and convincing our concept will be. That's probably something more for Sandra or Don. So I gave it a kick-off. The question for me now is: After coming back from other development today, will I spend the remaining days on constraints or prepare fonts further more. I am open to proposals. Norbert From sandra_matts at hp.com Tue Feb 1 15:19:04 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:48 2009 Subject: UPD> fonts Message-ID: That's a great start Norbert. Will these people be able to attend the New Orleans meeting or the next meeting in New York? Sandra -----Original Message----- From: Norbert Schade [mailto:nschade@xionics.com] Sent: Tuesday, February 01, 2000 11:48 AM To: UPD group Subject: UPD> fonts I would not call myself the absolute font expert, but I know this and that. I invited Bitstream on January, 13th, to Oak (formerly Xionics, most of you may have heard that the merge now is public and legal) to talk about the subject. They were interested in visiting the group. I told them about the next meetings of our group especially mentioning New York. Don and Sandra, I hope that's in your sense. They may take the chance to represent themselves. With Bob Thomas, Director of Product Management, and Rob Solomon, Director of Type Engineering, and Shawn Flynn, Senior Software Engineer, on Bitstream's side and a colleague of mine as a font expert from the embedded side plus myself we had a nice group together and could cover a lot of items in little more than an hour on the management level as well as on the technical level. I introduced PWG and especially UPDF to them and told them my ideas about a font approach (we must start somewhere). 1.) I think we should take the IFIMETRICS structure from NT and check, whether this is the right superset for general font information. This includes Panose info. 2.) We have to add character set handling and 3.) character width information. I propose we will not tell about the scaling formula for calculating single char width explicitely in our XML file. I rather would expect that we assume the driver knows about certain font formats including their scaling formulas and we just reference that in a list. 4.) The relationship of system fonts to printer resident fonts with the complexity of font substitution unfortunately is another item in this area. I explained that I want us to investigate SVG and their font description more before we decide on a spec. Bitsteam generally agreed on all of that. They may even be interested to think about a tool to provide a XML file per font (only newer ones) shipped by Bitstream to be included easily into a complete UPDF. But that depends on how sophisticated and convincing our concept will be. That's probably something more for Sandra or Don. So I gave it a kick-off. The question for me now is: After coming back from other development today, will I spend the remaining days on constraints or prepare fonts further more. I am open to proposals. Norbert From sandram at boi.hp.com Thu Feb 3 15:51:48 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> Request for Constraint paper In-Reply-To: <000201bf6ce4$fd691990$c31343ce@gca-2.xionics.com> Message-ID: Norbert and others: I did not get the constraint paper that Norbert wrote up for the last meeting. Can someone please email it to me in an attachment. I want to copy it to the ftp site. thanks, Sandra Matts From nschade at xionics.com Fri Feb 4 12:04:48 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> fonts Message-ID: <000801bf6f31$f21b0180$c31343ce@gca-2.xionics.com> We may reserve about two hours for some talk about fonts and I can accompany it with some notes. My problem is I don't know how much is common knowledge. We are all assumed to be printer experts somehow. So maybe everyone knows as much or even more than I do. But nonetheless I will be prepared for some items. So we can use this as a kind of an agenda to follow on. At the beginning of our font discussion I'd like a public and binding decision that every glyph will always and everywhere be identified as a Unicode in our spec. After that we may talk about resident fonts: 1. Common font description files for the host PFM, AFM, TFM 2. General font attributes I hope others will jump in here. We will talk about font description structures for drivers in different operating systems. I propose a description close to the IFIMETRICS we know from NT. Please send me and bring with you appropriate stuff for the Mac and Unix/Linux. 3. Character width tables One long list of pairs of Unicode and width values. I'd like to see values for bitmap fonts rather based on virtual units (7200 will work in many cases, but this could be set somewhere more in a global section of our spec) than on real resolution. I do not want to have two lists for one font in 300 and 600 dpi, not to talk about 1200. This will make the font description a bit more model independent and reusable. I hope to encourage font vendors by that to develop a tool for automatic creation of UPDF font description files for easy implementation into a UPDF file. That is exactly the kind of arguments companies like Bitstream are looking for. An interesting item may be to describe the width of some fonts used in Japan, which are mainly fixed pitch. Few glyphs are half width and few others, mainly the Latin section, are proportional. The danger is to create huge data files without really providing much information. Do we want it simple and large or small and effective, but with more work on the driver side? 4. Dynamic character selection Similar problem as above. Do we want fonts to be determined to one special character set used in the operating system? This may result in quite a large number of font descriptions just to support a typeface like Arial under different operating systems and different language versions (International, East European, Cyrillic, Japanese, etc.). We have to think about character set definitions and their effective use. And I want us to specify some common character sets in the DTD. Who can we use as a reference? The Unicode consortium? IEEE? A subitem here is when the font should be announced at all. Assuming a font description including Western and Eastern European characters would we expect to see the font showing up as Western AND Eastern, when the Eastern European option is not installed? That might be a nice battle. I have fought a lot already to make fonts 'dynamic'. 5. Font rotation Sometimes only some characters can be rotated. See Japanese market. Sometimes fonts can only rotated in 90 degree steps. The unit to describe angles in could be 3600. 6. Character composition table Maybe there is better name for it. But you want to be able to substitute some characters with accents by combining the basic character and the accent as another char. I want us to specify a common composition table in the DTD, which can be used as a base. 7. Kerning 8. Scaling formulas I do not want to translate C code into XML to specify the way the width of characters in a scalable Intellifont or other font format is done. So we need to decide which font formats and therefore scaling formulas we support. This can include an anticipation of how the driver is expected to calculate. I would not mind to show five lines of C code per scaling formula in the general explanation of the spec. 9. System fonts used to screen resident fonts To be honest: This is an area, where I get angry quickly. So keep me calm. Typical questions: How should the font be named? If there are four styles of a typeface will the font name of these four fonts have a suffix like 'Bold', 'Italic', 'BoldItalic' or so? We don't need to decide that and can leave it open. But I like to have a policy in cases like this, which then can build up some culture to avoid problems early. Do we say anything how characters should be handled, which may not be supported by standard system fonts? When system fonts will be shipped with the device can we assume they are installed? 10. Command sequences Generally I propose to select fonts by attribute and not by location. To describe the download of system fonts not represented by resident fonts is somehow different, but we could reuse some sections. Character sets and rotation are an issue here, too. Proposal: We concentrate on temporary download, not permanent. Otherwise we have to handle hard disk, Flash ROM and so on. I do not think we are on level to handle that already. Temporary will make it difficult enough. I do not want to describe each download method in detail, but create a reference list with exact target models, e.g. 'PCL 5 bitmap' references the PCL bitmap download understood by a HP LaserJet III. We may need to specify some values like 'maximum number of download fonts', 'download per page / per document', etc. Even with constraints (you remember I suggested not to use constraints for UI only) it might be impossible to describe something like 'do not use more than 30% of RAM for download, if less than 2MB are available'. So memory handling might be up to the driver. So the download section might be quite short. As I said I know this and that. This overview may give you enough reason to throw tomatoes and eggs. I know I left font substitution out. I think we will face huge data accumulation and compression automatically. Anything else I forgot? Norbert From sandram at boi.hp.com Fri Feb 4 16:11:19 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> minutes Message-ID: Hi All, I've copied minutes and the latest DTD and companion files to www.pwg.org. I'm in the process of copying the constraint doc from Norbert and the Visio file that shows the current hierarchical layout of the DTD file. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com 208-396-4755 phone -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1580 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000204/28c62578/winmail.bin From sandram at boi.hp.com Fri Feb 4 16:21:21 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> Tokyo meeting Message-ID: Hi All, I recently found out that I will not be able to attend the Tokyo meeting. The location is not the problem but the actual date of the meeting. Unfortunately, I cannot leave Boise during March and April. I am looking for someone to voluteer to chair the meeting on Thursday in Tokyo. Please respond if you would be willing to lead the meeting for that one day. If no one can lead the meeting, I will have to cancel the UPDF meeting on Thursday. thank-you, Sandra Matts -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1668 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000204/599659ba/winmail.bin From nschade at xionics.com Mon Feb 7 10:01:56 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: Fw: UPD> Tokyo meeting Message-ID: <001e01bf717c$47443900$c31343ce@gca-2.xionics.com> -----Original Message----- From: Norbert Schade To: Sandra Matts Date: Monday, February 07, 2000 10:01 AM Subject: Re: UPD> Tokyo meeting >Sandra, >my company is still thinking about the UPDF Tokoy meeting. >In case it will be cancelled at all, I strongly vote for two teleconferences >in April. >Additionally I'd like to select from one of two options in New York: >A. We will not stop our UPDF meeting right after lunch, but extend it to at >least 5pm. >B. We add a font day on Thursday, 2pm to 6pm, which would leave enough time >for travel in the morning for most of us. >By the way, I would accept both options the same time. Target of the New >York meeting then could be to finish discussions about fonts and >concentrating on writing it down in XML the weeks before San Francisco. >To accomplish that it would be necessary that several people take over some >tasks for fonts, especially in the OS specific area, contacting the Unicode >consortium or getting various one-byte character sets filled with Unicode in >their own company and other tasks, which will come up during our discussion >this Friday. If some people commit to that, I am ready to lead the font >section of the spec. >Norbert >-----Original Message----- >From: Sandra Matts >To: Universal Printer Driver >Date: Friday, February 04, 2000 5:13 PM >Subject: UPD> Tokyo meeting > > >>Hi All, >> I recently found out that I will not be able to attend >>the Tokyo meeting. The location is not the problem but >>the actual date of the meeting. Unfortunately, I cannot >>leave Boise during March and April. >> >> I am looking for someone to voluteer to chair >>the meeting on Thursday in Tokyo. Please respond >>if you would be willing to lead the meeting for that >>one day. >> >> If no one can lead the meeting, I will have >>to cancel the UPDF meeting on Thursday. >> >> >>thank-you, >>Sandra Matts >> > From don at lexmark.com Mon Feb 7 11:43:28 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> Tokyo UPDF Meeting Message-ID: <200002071827.NAA25594@interlock2.lexmark.com> I would be willing to lead the UPDF meeting in Tokyo _IF_ the agenda is done in advance. I can moderate and direct the discussion as necessary but others should be on the hook for the presentations and other material. ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From egglestn at lexmark.com Mon Feb 14 12:09:14 2000 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> Testing.... Message-ID: <200002141710.MAA07264@interlock2.lexmark.com> Testing upgrades to pwg.org. Please do not respond. Roger From nschade at xionics.com Tue Feb 15 16:23:42 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> command sequences Message-ID: <000401bf77fa$ef8d2fc0$c31343ce@gca-2.xionics.com> The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert From nschade at xionics.com Mon Feb 14 15:32:57 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> Unicode support Message-ID: <000701bf772a$ae135ea0$c31343ce@gca-2.xionics.com> It became apparent that we need a unique way of identifying characters when dealing with them in different operating systems with different configurations. The only option coming up was Unicode. It would be used in two areas: 1. Technical spec of fonts Especially the handling of character sets requires a neutral and consistent way to identify characters. 2. Dialogs Any Universal Printer Driver will have a dialog. Some other strings like font names will even be passed through to applications. It would be a huge problem to have different conditions for storing these strings based on different operating system character sets. While there seemed to be a wide consensus about the use of Unicode to accomplish that every company shall have the chance to discuss this internally and check current policies. It needs a little more investigation to find out about the appropriate encoding form. It will most probably be either UTF-8 or UTF-16. When searching in the Internet it looks as if UTF-8 is the current leader in industry standards. Saving the Unicode in the theoretic default value of four bytes is not an option. We'll wait til end of March 2000 for statements. After that there will be a time to vote on that. While chatting around I found a number of XML editors either available or under development, which support at least UTF-8. So this should not be a problem at all. Norbert From nschade at xionics.com Mon Feb 14 16:03:57 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> further input to font handling Message-ID: <000901bf772f$02afb0e0$c31343ce@gca-2.xionics.com> Having checked user defined character sets in PCL over the week-end I think this is a good direction to go. I explained why a UPD has to have the ability to define and download user defined character sets in PostScript (only one character set per font, only few predefined char sets). So we would add few sections to the driver development to extend this functionality to PCL. We can use Unicode in PCL character set definitions. This would make UPDF practically independent from character sets for device fonts. It saves time when creating the UPDF font section. It makes the font description significantly shorter. It may even be more efficient in performance. I realize that it can happen that we redefine a character set, which was already a perfect match as a predefined, in certain cases. The only challenge would be to add the necessary functionality for PCL. A future switch to direct Unicode support in the PDL would then be little more than a finger snip. I still believe that we need the character set functionality described last Friday for dynamic character selection additionally, as some fonts may come with only "almost" perfect match from the font vendor, as some PDL may not offer a dynamic user defined character set. But for PCL 5, PCL 6 and PostScript this will make our life easier - and of those, who will write the UPDF. Norbert From don at lexmark.com Thu Feb 17 10:20:49 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> command sequences Message-ID: <200002171521.KAA25429@interlock2.lexmark.com> It has been my assumption all along that we would have to include these command sequences. There's simply no way around it. Is it time to bite the bullet and start this process? ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/15/2000 04:23:42 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> command sequences The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert From don at lexmark.com Thu Feb 17 10:22:46 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> Unicode support Message-ID: <200002171545.KAA03138@interlock2.lexmark.com> I too believe UTF-8 is the way to go. ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/14/2000 03:32:57 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> Unicode support It became apparent that we need a unique way of identifying characters when dealing with them in different operating systems with different configurations. The only option coming up was Unicode. It would be used in two areas: 1. Technical spec of fonts Especially the handling of character sets requires a neutral and consistent way to identify characters. 2. Dialogs Any Universal Printer Driver will have a dialog. Some other strings like font names will even be passed through to applications. It would be a huge problem to have different conditions for storing these strings based on different operating system character sets. While there seemed to be a wide consensus about the use of Unicode to accomplish that every company shall have the chance to discuss this internally and check current policies. It needs a little more investigation to find out about the appropriate encoding form. It will most probably be either UTF-8 or UTF-16. When searching in the Internet it looks as if UTF-8 is the current leader in industry standards. Saving the Unicode in the theoretic default value of four bytes is not an option. We'll wait til end of March 2000 for statements. After that there will be a time to vote on that. While chatting around I found a number of XML editors either available or under development, which support at least UTF-8. So this should not be a problem at all. Norbert From cmanros at cp10.es.xerox.com Thu Feb 17 11:09:51 2000 From: cmanros at cp10.es.xerox.com (Manros, Carl-Uno B) Date: Wed May 6 14:04:48 2009 Subject: UPD> Unicode support Message-ID: <918C79AB552BD211A2BD00805F15CE8502A6043D@x-crt-es-ms1.cp10.es.xerox.com> All, I agree with Don, considering that UTF-8 is now mandated for all IETF standards that contain text, and hence has to supported in things like IPP. Carl-Uno > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Thursday, February 17, 2000 7:23 AM > To: nschade@xionics.com > Cc: upd@pwg.org > Subject: Re: UPD> Unicode support > > > I too believe UTF-8 is the way to go. > > ********************************************** > * Don Wright don@lexmark.com * > * Director, Strategic & Technical Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > > > nschade%xionics.com@interlock.lexmark.com on 02/14/2000 03:32:57 PM > > To: upd%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: UPD> Unicode support > > > > It became apparent that we need a unique way of identifying > characters when > dealing with them in different operating systems with different > configurations. > The only option coming up was Unicode. It would be used in two areas: > 1. Technical spec of fonts > Especially the handling of character sets requires a neutral > and consistent > way to identify characters. > 2. Dialogs > Any Universal Printer Driver will have a dialog. Some other > strings like > font names will even be passed through to applications. > It would be a huge problem to have different conditions for > storing these > strings based on different operating system character sets. > > While there seemed to be a wide consensus about the use of Unicode to > accomplish that every company shall have the chance to discuss this > internally and check current policies. > It needs a little more investigation to find out about the appropriate > encoding form. It will most probably be either UTF-8 or UTF-16. When > searching in the Internet it looks as if UTF-8 is the current > leader in > industry standards. Saving the Unicode in the theoretic > default value of > four bytes is not an option. > We'll wait til end of March 2000 for statements. After that > there will be a > time to vote on that. > > While chatting around I found a number of XML editors either > available or > under development, which support at least UTF-8. So this > should not be a > problem at all. > Norbert > > > > > From sandram at boi.hp.com Wed Feb 16 14:50:02 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> command sequences In-Reply-To: <000401bf77fa$ef8d2fc0$c31343ce@gca-2.xionics.com> Message-ID: For fonts I believe we can specify font sequences for PCL 5 and PCL 6 and it will work. However, for graphics commands using Raster and HP-GL/2, I think it will be a bit hard. I will have to do some prototyping (later) to see if it will work. For Fonts I think it is probably our only choice because of our tendencies to add proprietary escapes. Encoding escape sequences in XML may be hard. We can reference a binary file of escape sequences (Binary ENTITY) or we can use the pre-defined ISO-Latin-1 Character set. Using the latter would mean a driver has to decode Esc* (1B2Ah) to the binary equivalent 1B2A in hex and send that to the printer. Using a binary entity the driver would pull the entry from the file and send it to the printer with no decoding. I would lean towards the former so that the driver would not have to have as much intelligence. Also it may be difficult to enhance binary definitions if we require the driver to know their meaning. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com 208-396-4755 phone Boise, ID 83714 -----Original Message----- From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert Schade Sent: Tuesday, February 15, 2000 2:24 PM To: UPD group Subject: UPD> command sequences The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2920 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000216/a50de91d/winmail.bin From sandra_matts at hp.com Thu Feb 17 15:29:33 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:48 2009 Subject: FW: UPD> command sequences Message-ID: I sent this yesterday and it didn't make it. > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 12:50 PM > To: Universal Printer Driver > Subject: RE: UPD> command sequences > > For fonts I believe we can specify font sequences > for PCL 5 and PCL 6 and it will work. However, > for graphics commands using Raster and HP-GL/2, > I think it will be a bit hard. I will > have to do some prototyping (later) to see if it will > work. > > For Fonts I think it is probably our only choice > because of our tendencies to add proprietary > escapes. > > Encoding escape sequences in XML may be hard. We can > reference a binary file of escape sequences (Binary > ENTITY) or we can use the pre-defined ISO-Latin-1 > Character set. Using the latter would mean a driver > has to decode Esc* (1B2Ah) to the binary equivalent > 1B2A in hex and send that to the printer. Using > a binary entity the driver would pull the entry > from the file and send it to the printer with > no decoding. > > I would lean towards the former so that > the driver would not have to have as much intelligence. > Also it may be difficult to enhance binary definitions > if we require the driver to know their meaning. > > Sandra Matts > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Tuesday, February 15, 2000 2:24 PM > To: UPD group > Subject: UPD> command sequences > > > The more I think about it, the more I am convinced that we need command > sequences in the UPDF file. > It is simply an illusion that a driver uses a certain HP model as a > reference. I really think every clone and every port of a PDL to a > specific > model has its proprietary conditions and even improvements, which are not > 100% compatible with the target HP model. > >From my time in Germany, where we developed drivers for many different > companies, I know that a lot of proprietary command sequences have been > invented in the past and that there are tons of proprietary paper source, > paper size, print media, typeface, symbol set and other parameters. > Only very few models would work with a UPD, that anticipates the > correctness > of a print file. > > Beside the difficulties to describe binary print files - are there other > reasons to not specify command sequences in a UPDF? > Like marketing or policy reasons? > In case we solve the problems to describe that technically, has any > company > any other problem? > Norbert From sandra_matts at hp.com Thu Feb 17 15:32:24 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:48 2009 Subject: FW: UPD> command sequences Message-ID: > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Thursday, February 17, 2000 1:19 PM > To: sandra_matts@am.exch.hp.com > Subject: FW: UPD> command sequences > > > > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 12:50 PM > To: Universal Printer Driver > Subject: RE: UPD> command sequences > > For fonts I believe we can specify font sequences > for PCL 5 and PCL 6 and it will work. However, > for graphics commands using Raster and HP-GL/2, > I think it will be a bit hard. I will > have to do some prototyping (later) to see if it will > work. > > For Fonts I think it is probably our only choice > because of our tendencies to add proprietary > escapes. > > Encoding escape sequences in XML may be hard. We can > reference a binary file of escape sequences (Binary > ENTITY) or we can use the pre-defined ISO-Latin-1 > Character set. Using the latter would mean a driver > has to decode Esc* (1B2Ah) to the binary equivalent > 1B2A in hex and send that to the printer. Using > a binary entity the driver would pull the entry > from the file and send it to the printer with > no decoding. > > I would lean towards the former so that > the driver would not have to have as much intelligence. > Also it may be difficult to enhance binary definitions > if we require the driver to know their meaning. > > Sandra Matts > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Tuesday, February 15, 2000 2:24 PM > To: UPD group > Subject: UPD> command sequences > > > The more I think about it, the more I am convinced that we need command > sequences in the UPDF file. > It is simply an illusion that a driver uses a certain HP model as a > reference. I really think every clone and every port of a PDL to a > specific > model has its proprietary conditions and even improvements, which are not > 100% compatible with the target HP model. > >From my time in Germany, where we developed drivers for many different > companies, I know that a lot of proprietary command sequences have been > invented in the past and that there are tons of proprietary paper source, > paper size, print media, typeface, symbol set and other parameters. > Only very few models would work with a UPD, that anticipates the > correctness > of a print file. > > Beside the difficulties to describe binary print files - are there other > reasons to not specify command sequences in a UPDF? > Like marketing or policy reasons? > In case we solve the problems to describe that technically, has any > company > any other problem? > Norbert From sandram at boi.hp.com Wed Feb 16 16:01:46 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:04:48 2009 Subject: UPD> further input to font handling In-Reply-To: <000901bf772f$02afb0e0$c31343ce@gca-2.xionics.com> Message-ID: user defined character sets are limited to 256 characters. It can be typical for Asian docs to contain 1000-2000 unique characters. Therefore the driver has to maintain a list of font descriptor numbers and when it downloads a character, it has to search for it in the list of font descriptors. It is not a major problem. There are drivers today that manage this. I just want to make sure that people realize there some work involved in the driver to make it work. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com 208-396-4755 phone Boise, ID 83714 -----Original Message----- From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert Schade Sent: Monday, February 14, 2000 2:04 PM To: UPD group Subject: UPD> further input to font handling Having checked user defined character sets in PCL over the week-end I think this is a good direction to go. I explained why a UPD has to have the ability to define and download user defined character sets in PostScript (only one character set per font, only few predefined char sets). So we would add few sections to the driver development to extend this functionality to PCL. We can use Unicode in PCL character set definitions. This would make UPDF practically independent from character sets for device fonts. It saves time when creating the UPDF font section. It makes the font description significantly shorter. It may even be more efficient in performance. I realize that it can happen that we redefine a character set, which was already a perfect match as a predefined, in certain cases. The only challenge would be to add the necessary functionality for PCL. A future switch to direct Unicode support in the PDL would then be little more than a finger snip. I still believe that we need the character set functionality described last Friday for dynamic character selection additionally, as some fonts may come with only "almost" perfect match from the font vendor, as some PDL may not offer a dynamic user defined character set. But for PCL 5, PCL 6 and PostScript this will make our life easier - and of those, who will write the UPDF. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2824 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000216/8d7c96c2/winmail.bin From sandra_matts at hp.com Thu Feb 17 15:33:06 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:48 2009 Subject: FW: UPD> further input to font handling Message-ID: > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Thursday, February 17, 2000 1:19 PM > To: sandra_matts@am.exch.hp.com > Subject: FW: UPD> further input to font handling > > > > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 2:02 PM > To: UPD group > Subject: RE: UPD> further input to font handling > > user defined character sets are limited to 256 characters. It can > be typical for Asian docs to contain 1000-2000 unique > characters. Therefore the driver has to maintain a list of font > descriptor numbers and when it downloads a character, it has > to search for it in the list of font descriptors. It is not a major > problem. There are drivers today that manage this. I just > want to make sure that people realize there some work > involved in the driver to make it work. > > Sandra Matts > > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Monday, February 14, 2000 2:04 PM > To: UPD group > Subject: UPD> further input to font handling > > > Having checked user defined character sets in PCL over the week-end I > think > this is a good direction to go. > I explained why a UPD has to have the ability to define and download user > defined character sets in PostScript (only one character set per font, > only > few predefined char sets). So we would add few sections to the driver > development to extend this functionality to PCL. We can use Unicode in PCL > character set definitions. > This would make UPDF practically independent from character sets for > device > fonts. It saves time when creating the UPDF font section. It makes the > font > description significantly shorter. It may even be more efficient in > performance. > I realize that it can happen that we redefine a character set, which was > already a perfect match as a predefined, in certain cases. > The only challenge would be to add the necessary functionality for PCL. > A future switch to direct Unicode support in the PDL would then be little > more than a finger snip. > > I still believe that we need the character set functionality described > last > Friday for dynamic character selection additionally, as some fonts may > come > with only "almost" perfect match from the font vendor, as some PDL may not > offer a dynamic user defined character set. > > But for PCL 5, PCL 6 and PostScript this will make our life easier - and > of > those, who will write the UPDF. > > Norbert From nschade at xionics.com Fri Feb 18 10:03:20 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> command sequences Message-ID: <002b01bf7a21$4bbab560$c31343ce@gca-2.xionics.com> I think we are on a good way here. I second the idea not to specify vector language. This is typically identical in all PDL implementations. We may come up with a list of functionality and command sequences, which we expect the driver to know and activate depending on a certain target model. I need a little bit more time to start that. Items in the list can be: Vector language, bitmap download, outline download, etc. Raster graphic to be checked. The list of command sequences to be supported in UPDF includes: job language (to be checked with IPP), session and page settings (paper handling, etc.), font selection and others. This list should be specified in our spec. That is exactly the kind of policy I talk about from time to time to provide some orientation for driver developers. I see problems in reading fixed binary commands from a binary file. I'd like us to provide more flexibility here. We have a good chance to step ahead GPD here. We need to support formulas. The simpliest example is a command sequence for the height of scalable fonts. You will not list every point size. So you want to specify the height as a flexible parameter. I could imagine we can make it better than something like '%D', where the driver has to know that 'D' in the height command is the height. There are more complex sequences with several parameters and working with methods like '%D' would be kind of restrictive by only being able to work with the predefined values. To give an odd example: If a special printer model would expect the width instead of the height as the parameter in our above sample, you would not have any chance to specify it, as the driver is assuming without any doubt that '%D' is the height in the print file. That's why I call a method like '%D' working with predefined parameters, while something like '%Height' (or similar syntax, to be discussed) would provide what I call speaking variables / meaningful variable names (help me with my bad English). It is very useful to even be able to do some simple calculations. Let's say it would be necessary to do something in 1200dpi (current device resolution), although the application is sending in a value in 600dpi (current graphic resolution). To stay with '%Height' sample this could then be '%Height*2'. The main issue to care for is the variable length of the name/formula. But then you can feed the driver with nearly any kind of command sequence description. I'd like that to be on the agenda for the next conference I'll be joining (Tokyo or New York). The item should be called 'parameter converter'. Generally I think very much that we are heading the right direction with command sequences in the meantime. Norbert From don at lexmark.com Fri Feb 18 13:07:31 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:48 2009 Subject: UPD> command sequences Message-ID: <200002181808.NAA17860@interlock2.lexmark.com> On the subject of Vector Language.... I don't think we should assume that every printer uses the same language or that all printers use a language from some predefined set. We must consider the case where a printer has a unique and proprietary language. How would the UPD know about it? How should the UPDF tell the driver about it? Is this a separate XML file or one that is included by the UPDF? ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/18/2000 10:03:20 AM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> command sequences I think we are on a good way here. I second the idea not to specify vector language. This is typically identical in all PDL implementations. We may come up with a list of functionality and command sequences, which we expect the driver to know and activate depending on a certain target model. I need a little bit more time to start that. Items in the list can be: Vector language, bitmap download, outline download, etc. Raster graphic to be checked. The list of command sequences to be supported in UPDF includes: job language (to be checked with IPP), session and page settings (paper handling, etc.), font selection and others. This list should be specified in our spec. That is exactly the kind of policy I talk about from time to time to provide some orientation for driver developers. I see problems in reading fixed binary commands from a binary file. I'd like us to provide more flexibility here. We have a good chance to step ahead GPD here. We need to support formulas. The simpliest example is a command sequence for the height of scalable fonts. You will not list every point size. So you want to specify the height as a flexible parameter. I could imagine we can make it better than something like '%D', where the driver has to know that 'D' in the height command is the height. There are more complex sequences with several parameters and working with methods like '%D' would be kind of restrictive by only being able to work with the predefined values. To give an odd example: If a special printer model would expect the width instead of the height as the parameter in our above sample, you would not have any chance to specify it, as the driver is assuming without any doubt that '%D' is the height in the print file. That's why I call a method like '%D' working with predefined parameters, while something like '%Height' (or similar syntax, to be discussed) would provide what I call speaking variables / meaningful variable names (help me with my bad English). It is very useful to even be able to do some simple calculations. Let's say it would be necessary to do something in 1200dpi (current device resolution), although the application is sending in a value in 600dpi (current graphic resolution). To stay with '%Height' sample this could then be '%Height*2'. The main issue to care for is the variable length of the name/formula. But then you can feed the driver with nearly any kind of command sequence description. I'd like that to be on the agenda for the next conference I'll be joining (Tokyo or New York). The item should be called 'parameter converter'. Generally I think very much that we are heading the right direction with command sequences in the meantime. Norbert From nschade at xionics.com Thu Mar 9 15:32:55 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> How many UPD? Message-ID: <000901bf8a06$a6b54e40$c31343ce@gca-2.xionics.com> I do expect the number of drivers per operating system to fall significantly. But I do not expect that there will be one master driver per operating system, which will be able to read and use all UPDF in the world. So the question I'd like to raise is: Do we expect any UPD to understand any UPDF? Can a UPD reject certain UPDF's though the syntax is correct? The background of the question is deeper than it looks like the first second. Do we want the world to use the UPDF format to describe printers, while accepting that different companies may write different UPD's for that purpose? I consider it as a good direction to push the format first. I know a number of PDL's outside PostScript and PCL, which possibly can be described by a well architectured UPDF. But I would not expect that companies, who push these PDL's, will write a driver with a big PostScript and PCL section additionally. On the other side I do not expect that the first UPD's, e.g. if one would be written by HP, will be able to support every variant in the POS (point on sale) or other special markets. So I suggest that there will be fields in the UPDF, which allows a driver to check, whether it is really able to work with a certain UPDF (some info about the PDL to decide the UPD can support the appropriate vector language etc.). These fields must be supervised to avoid nonsense. I do not think that Oak would need these fields in the near future, but I feel it's somehow following an open concept and can help the format in its worldwide acceptance. I would like to see this item discussed in Tokyo and New York. Even if we disagree, it will be better to talk about it. Norbert From nschade at xionics.com Fri Mar 10 16:05:21 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> Font handling DTD Message-ID: <000901bf8ad4$82adeec0$c31343ce@gca-2.xionics.com> All, in New Orleans I said I will continue working on fonts. This is the result so far. The structure of element types is pretty much complete except FontDownload. I do not expect to change the DeviceFonts section by myself a lot. So I'll see what feedback will come in. The next step will be to define the attributes. As you can see they are all empty yet. Further steps will be some documentation to show that IFIMETRICS structures can be created by this structure. I really would like to hear from the Apple guy I met several times at the meetings, if this is providing all info he needs. We will have some discussion whether it is possible or useful to support device fonts on a Unix machine at all. I am tending not to announce them at all there, as I do not yet see how the system will screen them without installing the corresponding screen fonts together with the driver. For those of you, who do not have a DTD editor like XML authority I added a GIF file, which you could insert into a WinWord document that you can watch the overview instead of single lines in a simple text editor. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling.dtd Type: text/dtd Size: 4621 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000310/523a3bd9/fonthandling.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram.gif Type: image/gif Size: 48090 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000310/523a3bd9/diagram.gif From nschade at xionics.com Mon Mar 13 14:23:32 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> resident fonts in UPDF Message-ID: <000301bf8d21$9efa3c60$c31343ce@gca-2.xionics.com> After further investigation of different concepts I think that UnitsPerEm and DesignUnits are identical. I will remove DesignUnits in the next version. From motoyama at blackhole.str.ricoh.com Wed Mar 15 10:42:13 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:04:48 2009 Subject: UPD> Font Message-ID: <200003151542.HAA23238@blackhole.str.ricoh.com> I am new to this list. However, I noticed that Font is discussed and encoded into SGML (XML). ISO 9541 is a font standard in which SGML encoding is given. Will this standard help? T. Motoyama From motoyama at blackhole.str.ricoh.com Wed Mar 15 10:43:40 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:04:48 2009 Subject: UPD> Font Message-ID: <200003151543.HAA23244@blackhole.str.ricoh.com> I am new to this list. However, I noticed that Font is discussed and encoded into SGML (XML). ISO 9541 is a font standard in which SGML encoding is given. Will this standard help? T. Motoyama From nschade at xionics.com Wed Mar 15 11:01:10 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:48 2009 Subject: UPD> Font Message-ID: <001201bf8e97$aec64ae0$c31343ce@gca-2.xionics.com> I busy today, but I definitely will have a look tomorrow. Motoyama-san, you have an Internet site? Norbert -----Original Message----- From: T. Motoyama +1-408-954-5445 To: upd@pwg.org Date: Wednesday, March 15, 2000 10:46 AM Subject: UPD> Font > >I am new to this list. However, I noticed that Font is discussed and >encoded into SGML (XML). ISO 9541 is a font standard in which SGML >encoding is given. Will this standard help? > >T. Motoyama > From motoyama at blackhole.str.ricoh.com Wed Mar 15 11:12:37 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:04:49 2009 Subject: UPD> ISO 9541 Message-ID: <200003151612.IAA23330@blackhole.str.ricoh.com> Norbert: Anything to do with ISO is hard. I think you have to get the standard from ANSI (www.ansi.org). It is three volumes standard and will cost you good $$$. However, they contains detailed attributes for multi-national fonts. This standard will save a lot of time to handle the international characters. T. Motoyama From sandra_matts at hp.com Wed Mar 15 16:02:05 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> New York mtg Message-ID: Don has asked me to send out a notice concerning the UPDF meeting in New York. Due to scheduling conflicts he wants the meeting to take place on Friday - our usual day. We had discussed having it on Tuesday of that week. Hopefully people have not made travel plans yet since it is a couple of months yet. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com (208) 396-4755 phone From sandra_matts at hp.com Thu Mar 16 10:49:04 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> Tokyo meeting Message-ID: If anyone is planning on attending the Tokyo for the UPDF meeting and has agenda items, please send them to Don Wright. Currently we are still working on the Font encoding in XML and that will be the main agenda item in New York in May. thank-you, Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From nschade at xionics.com Mon Mar 27 11:24:54 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> ISO 9541 Message-ID: <001301bf9808$fbd9d2a0$c31343ce@gca-2.xionics.com> I had a chance to have a short look at it. This spec consists of three parts: general architecture, ways to code it (Interchange format) and Glyph shape representation. I don't think we care about part 3 too much. Part 2 tells about ASN and SGML coding and minimum font resources and should be easy to understand. Part 1 is the main description of the architecture and the structures and parameters. This would be the main reference. I have some comments and questions: 1. I want to find out how much this spec is a living spec. Where is it used? I would not called it exactly Windows conform, although that shouldn't be our only view. Perhaps some people from operating systems and/or font development have some more info. Motoyama-san, what do you know about that? Are you working with it regularly? Can somebody provide a DTD and an XML file based on that DTD? 2. the spec is from the early nineties. A bigger part of the architecture is handling font classification, which nowadays is realized by Panose in many environments. I favor Panose. 3. Unicode is not mentioned in the sections I have seen. 4. I do not find anything about character sets in the spec, neither of operating systems nor of devices. 5. The spec seems to be stronger concerning alignments of international characters. 6. Parameters looks somehow familiar, although I haven't studied in detail yet. I have to study more, but my conclusion up to now is: We will not fulfill the spec 100%, as today's requirements are not all covered. So we will not be compatible. The question is whether we want to lean towards it. What advantages would that have? What extra effort (at least reading and thinking about it and then comparing in detail, what we can take over)? We may want to decide that in the very near future. But we need more info and a broader base for the decision. Norbert From motoyama at blackhole.str.ricoh.com Mon Mar 27 11:57:22 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:04:49 2009 Subject: UPD> ISO 9541 Message-ID: <200003271657.IAA00627@blackhole.str.ricoh.com> The specification is published and under 5 year review cycle. However, the glyph registration may be handled by Unicode group. I am not sure the status of glyph registration. Mike Ksar of HP was involved to use the font registration to publish 10646. I just suggested to take a look at the specification and to use the usable part. If you think ISO 9541 is too old or not practical, I suggest not to use it. The character sets were different issues. The specification only handled glyphs and how to may them to code was never addressed. The collection of glyphs was internation including oriental launguages such as Chinese and Korean. I think Alabic was included too. Tetsuro From nschade at xionics.com Mon Mar 27 16:30:31 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> True Type fonts Message-ID: <000301bf9833$ae085940$c31343ce@gca-2.xionics.com> As it came up today: 1. Shall we just use the True Type format to describe the device fonts by eliminating the glyph descriptions and everything else we don't need? I think the answer in this case is no, as it is a binary format. 2. Shall we convert the remainder of the True Type format to XML? would we have all the info we are looking for? How much data would that be per font? I do not know. I'm not an expert in writing TT fonts. Perhaps someone else can provide more feedback. Norbert From nschade at xionics.com Tue Mar 28 16:55:19 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> character sets in device fonts Message-ID: <000d01bf9900$4f30a120$c31343ce@gca-2.xionics.com> You may want to find out about the reasons why I designed the character set handling the way I introduced it almost three weeks ago. See some explanations in the following section. Character selection in device fonts The target format of this spec concerning device fonts ? in case they survive in the longterm run ? is based on Unicode handling. That means a character would be identified by its Unicode. Character sets would become redundant. As long as this is not reality, we need character sets. I keeping away more and more from thinking in terms of 1-byte and 2-byte character sets. I?ve learnt that a set is a more or less arbitrary collection of characters. But the fact is that character sets are needed to identify characters in a font. DeviceCharacterSets I want to realize some rules when defining ways to identify characters in the device: 1. I do not see any reason to specify all predefined character sets of a PDL with all characters. The ideal solution would be to specify each character exactly once, whatever the used character set for that character is. 2. As the ideal solution could have a serious impact on the print file size and especially on the performance and as PDL?s nowadays have a number of character sets, which are at least close to operating system character sets, I consider it useful to specify some character sets used in the PDL with all characters. Those character sets will be the ones used as primary and secondary sets in the CharacterSetIdentification. This avoids unnecessary switching and the next character will most likely be found more quickly. This could result in a device font with several Windows character sets plus some sets with only few characters, which are really new ones compared to the primary/secondary sets. This would allow to list all characters without an overwhelming amount of data. Targets of this priority is to list all characters while allowing some redundancy for performance advantages. 3. If operating system character sets are not available in the numbers needed and if user defined character sets are supported that could be the alternative. We can discuss whether this should be the top priority. This approach offers the easiest switch from character sets to real Unicode handling in the device. Then there would not be any DeviceCharacterSets section. It is to be investigated, whether these DeviceCharacterSets should be specified outside the individual font specification, as many if not most of them will appear in many fonts. The font specific section would then only list, which character sets are available, not the ranges. It should be a target to avoid redundancy where possible. But in this case we would loose the independency of each font specification. Ranges I think ranges are at least an alternative to matrix definitions. The problem with matrix definitions always is to handle 1-byte (16x16 matrix) and multibyte character sets. To list each character with its Unicode and the corresponding binary output would create long lists in many cases, while not each pair of data is not really providing new information. A range from U+0020 to U+007E for example could just show the binary output for the first Unicode. The binary values for all following characters in that range can easily be calculated. This is a kind of compression therefore. CharacterSetIdentification After having defined all necessary DeviceCharacterSets we can think about how to tell, which operating system character sets the font can fulfill. So for any OS char set there might be a device char set with the perfect match. This one would be listed as primary and that?s it. In case it?s just the best one available and very good, but not perfect, it would still be listed as primary, but one or more other could be added as secondary sets. I assume that the search for a character would always start in the character where the driver found the last character, then in the primary and then in the secondary sets. This should provide a good performance with a maximum of flexibility. CharacterSubstitutionTables can provide further help in the search process. To be investigated, whether characters, which are not listed in either the primary or the secondary sets, can be used for that OS char set at all. I hope I made it clear enough that this structure would support one Arial font for all OS char sets and not one per OS char set like realized in most of today's drivers. Norbert From don at lexmark.com Wed Mar 29 23:31:40 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:49 2009 Subject: UPD> Tokyo meeting Message-ID: <200003300434.XAA17628@interlock2.lexmark.com> I've seen nor heard any interest from the US side in participating in a conference call during the UPDF meeting in Tokyo. That meeting will start on Thursday at 9AM Tokyo time or Wednesday evening at 8PM eastern time (I believe). Unless I hear from some people very very very soon (today 3/30), there will be no conference call. If there are more than 1 that respond, I need someone on the US side to set up a dial in number. ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From sandra_matts at hp.com Mon Apr 17 11:28:43 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> UPDF Chair Message-ID: Hi All, This May will be the two year mark of my job chairing the UPDF portion of the PWG. There have been alot of changes during the two years at HP and I am now part of a different organization. My new management has decided that I must give up the chairperson. It takes up quite a bit of my time just to prepare for the meetings. Also travel to the meetings and then attending the meetings takes up almost a full week. New York will be my last meeting as chair. I will still be able to participate but only as a regular member. I put it out to the group to see if another person wants to take over the chair. Please resond with thoughts, ideas. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From sandra_matts at hp.com Mon May 8 16:38:47 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> agenda for UPDF meeting Message-ID: Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From sandra_matts at hp.com Mon May 8 16:56:10 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> Font Message-ID: Sorry this is so late. I'm catching up on old email. I looked at ISO 9541 and it appears to be a Type 1 PostScript font format. I want to look at it for ideas but I want to make sure that our font.dtd is PDL independent. Sandra -----Original Message----- From: Norbert Schade [mailto:nschade@xionics.com] Sent: Wednesday, March 15, 2000 9:01 AM To: T. Motoyama +1-408-954-5445 Cc: UPD group Subject: Re: UPD> Font I busy today, but I definitely will have a look tomorrow. Motoyama-san, you have an Internet site? Norbert -----Original Message----- From: T. Motoyama +1-408-954-5445 To: upd@pwg.org Date: Wednesday, March 15, 2000 10:46 AM Subject: UPD> Font > >I am new to this list. However, I noticed that Font is discussed and >encoded into SGML (XML). ISO 9541 is a font standard in which SGML >encoding is given. Will this standard help? > >T. Motoyama > From lfarrell at cissc.canon.com Mon May 8 17:14:53 2000 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:04:49 2009 Subject: UPD> agenda for UPDF meeting Message-ID: <6C940F5153E5D211937A0090274E8D8B11E8A9@cissc002.cisoc.canon.com> Sandra, Since you have announced that this will be your last meeting as Chair, we should probably include an agenda item to address the future of the group [leadership]. lee ====================================== Lee Farrell Canon Information Systems 110 Innovation Drive Irvine, CA 92612 ph: (949) 856-7163 fax: (949) 856-7510 lfarrell@cis.canon.com ====================================== -----Original Message----- From: MATTS,SANDRA (HP-Boise,ex1) [mailto:sandra_matts@hp.com] Sent: Monday, May 08, 2000 1:39 PM To: Universal Printer Driver (E-mail) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From nschade at xionics.com Tue May 9 15:12:22 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> UPDF future Message-ID: <006001bfb9ea$85b85840$c31343ce@gca-2.xionics.com> I thought about it a while after HP's statement to step back from the chair. For better readability I add the original WinWord file, which is the same text. UPDF marketing and development directions as considered by Norbert Schade, Oak Imaging Group How much do companies want to be involved? ? Actions ? Always be on top of the information level ? New development ? Competion ? Provide Christmas wish list ? Provide problem list ? Become an expert for discussions ? PDLs ? Operating systems ? Driver delevopment concepts (PPD, GPD, etc.) ? Specification issues (XML, stylesheets, etc.) ? Contribute to specification ? Provide feedback ? Companies ? Hewlett-Packard ? Canon ? Oak Technologies ? others Development of a Universal Printer Data Format ? Develop sections of the spec ? Commit to it in a list attached with a schedule ? Provide section-wise explanations in the spec about the way a driver is supposed to use the data. ? Provide section-wise explanations in the spec why the data is specified as it is. ? Feedback ? Regular representatives of meetings ? Experts at home ? Subscribers (publish and set schedules) ? Other companies contacted by the group (like font companies some months ago) ? Compare with existing standards regularly Results of a UPDF development other than the format itself ? Develop a Universal Font Description Format as a 100 percent subsection of UPDF ? Prove problem awareness ? Prove solution expertise ? Isolate and discuss common driver development problem areas ? Be a contact to operating system developers ? Provide a list of useful and required extensions to existing develoment systems (e.g. spooler requirements like job respool or page order). ? Recommend certain driver conceptional approaches ? Be a contact to application developers ? Recommend certain handling of driver features (e.g. duplex) A UPDF spec will be written at least three times ? As a draft ? After the expert check ? During driver development Conclusion: The UPDF group has to decide about its future. If Hewlett-Packard is no more interested in playing a major role (completely independent from the person Sandra Matts) concerning the spec and a driver, this would be a serious political indication. If not more people become active developers of the spec and generally support the group, we have to ask ourselves about productivity and determination. This includes the establishment of experts in the group and in the background of the group. We need at least a full day (eight hours) meeting time. A smaller requirement is that we need a XML consultant. Finally I think the chair is a more personal decision. First we have to care for some productive conditions of the group. I hope we can see some more signs of devotion to the job by more people. Otherwise credibility will become a problem. Sincerely Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF marketing and development directions.doc Type: application/msword Size: 22528 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000509/d5e5d7f7/UPDFmarketinganddevelopmentdirections.doc From don at lexmark.com Wed May 10 15:17:13 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:04:49 2009 Subject: UPD> agenda for UPDF meeting Message-ID: <200005101924.PAA09739@interlock2.lexmark.com> While I don't have XML for it, I think adding the PDL strings should be a high priority item on the list. This is core to the concept of a UPD... it has to be able to know how to do all the basic things for text, images, positioning, etc. ********************************************** * 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) * * (Former area code until 10/1 was 606) * ********************************************** sandra_matts%hp.com@interlock.lexmark.com on 05/08/2000 04:38:47 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From hastings at cp10.es.xerox.com Wed May 10 19:58:45 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:49 2009 Subject: UPD> agenda for UPDF meeting [PDL strings] Message-ID: <918C79AB552BD211A2BD00805F15CE85031F4A40@x-crt-es-ms1.cp10.es.xerox.com> I agree with Don about adding the PDL strings to the UPDF agenda. I'd also like to make sure that there is sufficient distinctions in the UPDF specification for specifying where the PDL strings go in the payload, so that the UPDF can indicate the placement of the PDL data as being up front or as it occurs on the page, etc. We have looked at the similar PPD mechanism for positioning IPP Job Template attributes, like "media", "copies", and "finishings" in the payload up front and it is almost, but not quite, sufficient for generating conforming 'application/ipp' MIME Media type data. It would be good if a UPDF file could have sufficient flexibility to be able to produce an application/ipp payload for a Print-Job request including the IPP operation attributes and the IPP Job Template attributes in front of the PDL data in the payload. Thanks, Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Wednesday, May 10, 2000 12:17 To: sandra_matts@hp.com Cc: upd@pwg.org Subject: Re: UPD> agenda for UPDF meeting While I don't have XML for it, I think adding the PDL strings should be a high priority item on the list. This is core to the concept of a UPD... it has to be able to know how to do all the basic things for text, images, positioning, etc. ********************************************** * 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) * * (Former area code until 10/1 was 606) * ********************************************** sandra_matts%hp.com@interlock.lexmark.com on 05/08/2000 04:38:47 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From norbertschade at oaktech.com Mon May 22 11:53:26 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> documents from NY meeting Message-ID: <000d01bfc405$de47ef00$c31343ce@gca-2.xionics.com> Hi, find the documents I brought as printed versions attached. The DTD files are available as GIF, too, to make it easier to import them into WinWord for printing. I'm going to work on the font handling DTD the next days, including a draft spec for it. I will establish a small font expert group. Up to now major members will be in alphabetical order AGFA (Dale Hubbard), Bitstream (Shawn Flynn), IBM (Mark VanderWiele) and Oak (Norbert Schade). The people mentioned in brackets may be the developers or can also work as coordinators to other more technical experts. This will result in an e-mail group and probably some teleconferences over the next months. If anyone wants to be added to that list, please tell me. I require feedback from other PWG companies from time to time. The first soliciting may be around June, 12. Please be prepared that your font experts can spend some time investigating, whether the current spec will hold all info needed for any kind of driver development. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling 1.dtd Type: text/dtd Size: 5621 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/fonthandling1.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Font handling.gif Type: image/gif Size: 26856 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/Fonthandling.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: paper handling.dtd Type: text/dtd Size: 3994 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/paperhandling.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Paper handling.gif Type: image/gif Size: 16337 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/Paperhandling.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: task schedule 2000.xls Type: application/vnd.ms-excel Size: 14336 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/taskschedule2000.xls -------------- next part -------------- A non-text attachment was scrubbed... Name: TT IFI Comparison.doc Type: application/msword Size: 29184 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/TTIFIComparison.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF marketing and development directions.doc Type: application/msword Size: 23040 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/UPDFmarketinganddevelopmentdirections.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF meeting New York.doc Type: application/msword Size: 24576 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/UPDFmeetingNewYork.doc From norbertschade at oaktech.com Fri May 26 12:39:20 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> new e-mail address Message-ID: <000501bfc730$f14a4fc0$c31343ce@gca-2.xionics.com> my new e-mail address is norbertschade@oaktech.com. please make necessary adjustments. the old address will work a while. Norbert From sandra_matts at hp.com Fri May 26 13:39:23 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:04:49 2009 Subject: UPD> new e-mail address Message-ID: I also have a new email. Please send email to sandra_matts@hp.com thanks, Sandra Matts -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Friday, May 26, 2000 10:39 AM To: UPD group Subject: UPD> new e-mail address my new e-mail address is norbertschade@oaktech.com. please make necessary adjustments. the old address will work a while. Norbert From hastings at cp10.es.xerox.com Mon Jun 19 21:05:29 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:49 2009 Subject: UPD> Jim Flowers' email address (editor of ISO 9541 font standard) Message-ID: <918C79AB552BD211A2BD00805F15CE8503496A1C@x-crt-es-ms1.cp10.es.xerox.com> Jim Flowers offered to answer questions about the ISO 9541 font standard of which he was once the editor. His email address is: flowers@aligninc.com Tom -----Original Message----- From: Jim Flowers [mailto:flowers@aligninc.com] Sent: Thursday, June 01, 2000 07:26 To: Rick Landau; Hastings, Tom N Cc: Jim Flowers Subject: Re: Do you know Jim Flowers email address? Yes this email address still works. How are you guys doing? I'm still consulting through my company Align, about to hire on some people to more effectively work on large B2B web sites. I focus on server-side Java these days, although I just finished up a font server-related project for Sun's SunPCi product. Tom, I haven't done anything remotely *font* in many years, particularly related to the ISO font standard. Part 3 (I think) of the standard when shapes are defined IS Type 1 specific, although it probably allows other formats--this part happened after I was booted by the working group chair. I'd be happy to answer any direct questions that you have, but I'm not in a position to work on standardization any more. -Jim > ----- Original Message ----- > From: Hastings, Tom N > To: Rick Landau > Cc: Hastings, Tom > Sent: Tuesday, 2000/05/30 14:16 > Subject: Do you know Jim Flowers email address? > > > > Rick, > > > > > > > > The Printer Working Group (PWG) has a Universal Printer Driver Format > (UPDF) > > project which has just started to consider an XML encoded font metrics > > module. I got them to look at ISO 9541 that Jim authored. But the > chairman > > (from HP) thinks that it is Type 1 PostScript format. Probably because it > > doesn't have all of the wierdness of HP fonts. I would be extremely > > surprised if the ISO standard was for Postscript type1 fonts. > > > > > > > > I wanted to see if Jim was interested in helping the group. There are a > > number of font venders from the Boston area (Bit Stream and Agfa) that are > > joining in. > > > > > > > > Thanks, > > > > Tom > > > > -----Original Message----- > > > > From: MATTS,SANDRA (HP-Boise,ex1) [mailto:sandra_matts@hp.com] > > > > Sent: Monday, May 08, 2000 13:56 > > > > To: Universal Printer Driver (E-mail) > > > > Subject: RE: UPD> Font > > > > > > > > Sorry this is so late. I'm catching up on old email. > > > > I looked at ISO 9541 and it appears to be a Type 1 PostScript > > > > font format. I want to look at it for ideas but I want > > > > to make sure that our font.dtd is PDL independent. > > > > Sandra > > > > -----Original Message----- > > > > From: Norbert Schade [mailto:nschade@xionics.com] > > > > Sent: Wednesday, March 15, 2000 9:01 AM > > > > To: T. Motoyama +1-408-954-5445 > > > > Cc: UPD group > > > > Subject: Re: UPD> Font > > > > > > > > I busy today, but I definitely will have a look tomorrow. > > > > Motoyama-san, you have an Internet site? > > > > Norbert > > > > -----Original Message----- > > > > From: T. Motoyama +1-408-954-5445 > > > > To: upd@pwg.org > > > > Date: Wednesday, March 15, 2000 10:46 AM > > > > Subject: UPD> Font > > > > > > > > > > > > > >I am new to this list. However, I noticed that Font is discussed and > > > > >encoded into SGML (XML). ISO 9541 is a font standard in which SGML > > > > >encoding is given. Will this standard help? > > > > > > > > > >T. Motoyama > > > > > > > > From norbertschade at oaktech.com Fri Jul 7 16:57:11 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> Universal Device Font Description Message-ID: <000901bfe855$ec6269c0$510714ac@nschade-w2.xionics.com> All, find attached some files. This is the output of the small group working on a Universal Device Font Description Format. It is pretty complete already except for the download. This will be the base for Monday's UPDF meeting. I will have some printed versions with me. See you there. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: Font handling.gif Type: image/gif Size: 32268 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/Fonthandling.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling.dtd Type: text/dtd Size: 7765 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/fonthandling.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Universal Device Font Description Format.doc Type: application/msword Size: 99840 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/UniversalDeviceFontDescriptionFormat.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Parameter Converter.doc Type: application/msword Size: 26112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/ParameterConverter.doc From hastings at cp10.es.xerox.com Sat Jul 8 15:39:28 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:49 2009 Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts Message-ID: <918C79AB552BD211A2BD00805F15CE8503753B75@x-crt-es-ms1.cp10.es.xerox.com> This note is an idea for possible collaboration of the UPDF and IPP work. Attached is the first draft of an IPP extension for a Resource object and operations to get the attributes and/or opaque data. The Get-Resources operation includes a filter mechanism that uses the attributes defined for the Resource. Here is the Abstract: This IPP Get Resource document specifies an extension to IPP/1.0 [RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document extends the current closed IPP object model with a passive polymorphic object that is intended to satisfy most needs for new object types in the long-term evolution of IPP via an extensible object framework. This document defines: Resource object (passive polymorphic object); Resource get operations (e.g., Get-Resource-Attributes); Resource attributes (e.g., "resource-name"); new Printer attributes (e.g., "resource-type-supported"); Resource type of Driver (a morph of the Resource object); methods for supporting 'driver download' to IPP Client systems. The Resource object has a number of REQUIRED and OPTIONAL attributes that are independent of the resource type. We envision that one such resource type would be 'font'. Each resource type would also define additional attributes that are specific to that resource type. One of the Resource attributes is resource-document-formats (1setOf mimeMediaType) which indicates which document-formats each Resource instance is defined for, e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client could filter on the "resource-document-format" attribute to list, say, only the PostScript fonts. The resource data for a Resource object instance is envisioned being a collection of files, packaged as a single file, using, say, zip. Thus font metrics and font data could be separately represented. The IPP WG needs review by the UPDF WG to see if the basic mechanism is a good foundation for fonts and would meet your requirements for defining the 'font' resource type. For example, the attributes for different types of fonts needs to be different (we understand that the attributes for PostScript fonts and PCL fonts have something in common, but a lot that is different). Questions for the UPDF WG: 1. Is the basic framework sufficient for fonts? 2. Would you like to define the attributes for a 'font' resource-type? 3. For which document-formats? 4. What about other resources, such as device constraints? <> -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF and IPP - resource object.doc Type: application/msword Size: 105984 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000708/de527498/UPDFandIPP-resourceobject.doc From hastings at cp10.es.xerox.com Sun Jul 9 13:31:58 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:49 2009 Subject: UPD> More on UPDF and IPP Collaboration Message-ID: <918C79AB552BD211A2BD00805F15CE8503753B79@x-crt-es-ms1.cp10.es.xerox.com> I wasn't very clear in my previous note about UPDF and IPP Collaboration. 1. Firstly, there are lots more areas for collaboration that just fonts. It should be possible for a driver that interprets a UPDF file to generate an 'application/ipp' MIME type payload for a Print-Job request that conforms to IPP/1.1. Also a UPDF file for IPP/1.0. See (1) and and (2) RFCs 2566 and 2565, respectively. 2. For fonts, the area of collaboration is to have a semantic description of the font attributes, such as the ones that describe the font and the ones that describe the font metrics. This semantic description would have several parts: a. Attributes that are common to all fonts b. Attributes that apply to a particular document format, such as Postscript or PCL 3. Then these semantic description documents would have separate encoding documents: a. IPP encoding for use in the Get-Resource-Attributes, Get-Resource-Data, and Get-Resources operation requests and responses. b. XML encoding for use by font vendors when publishing their fonts and for use in a UPDF file for use by Printer vendors when publish their UPDF Printer Description files. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Saturday, July 08, 2000 12:39 To: upd Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts This note is an idea for possible collaboration of the UPDF and IPP work. Attached is the first draft of an IPP extension for a Resource object and operations to get the attributes and/or opaque data. The Get-Resources operation includes a filter mechanism that uses the attributes defined for the Resource. Here is the Abstract: This IPP Get Resource document specifies an extension to IPP/1.0 [RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document extends the current closed IPP object model with a passive polymorphic object that is intended to satisfy most needs for new object types in the long-term evolution of IPP via an extensible object framework. This document defines: Resource object (passive polymorphic object); Resource get operations (e.g., Get-Resource-Attributes); Resource attributes (e.g., "resource-name"); new Printer attributes (e.g., "resource-type-supported"); Resource type of Driver (a morph of the Resource object); methods for supporting 'driver download' to IPP Client systems. The Resource object has a number of REQUIRED and OPTIONAL attributes that are independent of the resource type. We envision that one such resource type would be 'font'. Each resource type would also define additional attributes that are specific to that resource type. One of the Resource attributes is resource-document-formats (1setOf mimeMediaType) which indicates which document-formats each Resource instance is defined for, e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client could filter on the "resource-document-format" attribute to list, say, only the PostScript fonts. The resource data for a Resource object instance is envisioned being a collection of files, packaged as a single file, using, say, zip. Thus font metrics and font data could be separately represented. The IPP WG needs review by the UPDF WG to see if the basic mechanism is a good foundation for fonts and would meet your requirements for defining the 'font' resource type. For example, the attributes for different types of fonts needs to be different (we understand that the attributes for PostScript fonts and PCL fonts have something in common, but a lot that is different). Questions for the UPDF WG: 1. Is the basic framework sufficient for fonts? 2. Would you like to define the attributes for a 'font' resource-type? 3. For which document-formats? 4. What about other resources, such as device constraints? <> From norbertschade at oaktech.com Thu Jul 27 11:26:37 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> Unicode tables Message-ID: <002401bff7df$0e4abd10$510714ac@nschade-w2.xionics.com> who can provide reliable Unicode based character set tables for the OSCharacterSets section of the Universal Device Font Description Format? I'm in direct contact with Apple. I may get something directly from them. I'm looking for MS Windows and Unix/Linux based tables. Although our format will only refer to these tables with the CharacterSetID field, we need a clear reference that there is no doubt about the character identifiers. I think about either listing them in the specification document, which will make it huge, or refer to that info somewhere. Feedback appreciated. I'm trying to contact the Unicode Consortium. This is a path I'm running parallel. But I made bad experience with them in the past. Norbert From david.roach at unisys.com Thu Jul 27 11:50:40 2000 From: david.roach at unisys.com (Roach, David L.) Date: Wed May 6 14:04:49 2009 Subject: UPD> Unicode tables (Resend) Message-ID: <31DAD5F069E5D31189A20060973CE25504EB82@US-PL-EXCH-2> See the official Unicode Online Data site, at "http://www.unicode.org/unicode/onlinedat/online.html". This page includes links to various cross-mapping table, including most (if not all) the MS Windows character sets. Dave Roach > -----Original Message----- > From: "Norbert Schade" @UNISYS > Sent: Thursday, July 27, 2000 11:27 AM > To: "UPD group" ; "Dale Hubbard" > ; "Shawn M. Flynn" ; > "Norbert Schade" ; "Mark VanderWiele" > > Subject: UPD> Unicode tables > > <<...>> > who can provide reliable Unicode based character set tables for the > OSCharacterSets section of the Universal Device Font Description Format? > I'm in direct contact with Apple. I may get something directly from them. > I'm looking for MS Windows and Unix/Linux based tables. > Although our format will only refer to these tables with the > CharacterSetID > field, we need a clear reference that there is no doubt about the > character > identifiers. > I think about either listing them in the specification document, which > will > make it huge, or refer to that info somewhere. Feedback appreciated. > I'm trying to contact the Unicode Consortium. This is a path I'm running > parallel. But I made bad experience with them in the past. > Norbert > From norbertschade at oaktech.com Tue Aug 22 10:48:46 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> company move Message-ID: <003101c00c48$12f923b0$510714ac@nschade-w2.xionics.com> Oak Technology, Imaging Group, has moved from Burlington to Woburn. Although the old and the new building are only in a distance of about 10 miles, some things have changed: Oak Technology, Inc. Imaging Group Attn.: Norbert Schade 10 Presidential Way Woburn, MA 01801-1041 Phones Reception: 781-638-7500 Direct: 781-638-7614 Fax: 781-638-7555 email: norbertschade@oaktech.com Oak web site: www.oaktech.com Attention!!! Due to the strike of the telephone company Verizon (previously Bell Atlantic) there are serious delays in the installations of the new phone system. We only provide an emergency system these days. It will be very tough to reach me on the phone and the direct call is not yet working at all. We expect improvements the next days and hope to break water end of next week. In case you want to talk to me, please use email. Regards Norbert Schade From norbertschade at oaktech.com Tue Sep 5 17:29:35 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> Chicago agenda Message-ID: <001601c01780$63a53cc0$510714ac@nschade-w2.xionics.com> The UPDF day is Monday, Sept 11. The conference will start at 8.30am and last to about 5.30pm. We will agree on a lunch break. I hope I'll be in the conference room in time, as I arrive shortly before 8am at the airport following the schedule. The Boston conference (UPDF day around October 26) is considered a bigger event for the UPDF group, as some things, which needed serious preparation, grow together. To aim at that major event we will have three sessions in Chicago: 1. Constraints The discussion was started some time ago, but not finished. I will send some material later today or tomorrow morning to enable everybody to study it ahead. We will have DTD files as well as XML files. Statements to decide: 1.1. Conditions for constraints can be combined with AND and/or OR. By nesting conditions recursively the number of levels and the complexity possible is practically indefinite. This allows a very flat architecture concerning the features of a printer model, as all dependencies and interdependencies will be handled as constraints. 1.2. Constraints will support the default action Filter. Should it support messages? See proposals. 1.3. Constraints can also be used to handle conditional selections. Select is considered an additional action. 1.4. Constraints are mainly known as an instrument to avoid conflicts in the user interface of the driver's dialog. The current proposal is supposed to be able to set conditions on almost any combination of fields. Those constraints can also be used when composing print files. We will take samples from paper handling, as that is known as an area full of constraints. 2. Overall architecture The discussion about constraints will automatically lead to a more global conversation about the overall architecture. In case constraints work perfectly we may be able to flatten out the architecture a bit. 2.1. Installable Options We will see that constraints have serious impact on the handling of installable options. 2.2. General extensibility How easy should it be to add an installable option or new locale without touching the original files? This will be a discussion about a file structure. 2.3. Although a Universal Printer Data Description is considered platform independent it should provide all information the operating system is expecting. What operating systems are exactly to be considered? 2.4. Linux How much can the UPDF group help the Linux guys to implement an application and a printing interface? Do we want to be involved? Do they want to be involved? 3. Font handling 3.1. Open questions about the font handling concept so far. 3.2. We want to prepare at least one sample implementation of a device resident font. This sample font(s) should be demonstrated in Boston. We want to get information about how easy it will be to create the information automatically, how big such a standard font may be in XML and how this information can be used best during install and runtime. Regards Norbert Schade From norbertschade at oaktech.com Tue Sep 5 18:09:23 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: Fw: UPD> Chicago agenda Message-ID: <001b01c01785$f2cd3d80$510714ac@nschade-w2.xionics.com> Please add mapping lists to item 2.3. to be able to convert the incoming values of communication protocols like IPP to operating system specific flags. -----Original Message----- From: Norbert Schade To: UPD group Date: Tuesday, September 05, 2000 5:32 PM Subject: UPD> Chicago agenda >The UPDF day is Monday, Sept 11. >The conference will start at 8.30am and last to about 5.30pm. >We will agree on a lunch break. >I hope I'll be in the conference room in time, as I arrive shortly before >8am at the airport following the schedule. > >The Boston conference (UPDF day around October 26) is considered a bigger >event for the UPDF group, as some things, which needed serious preparation, >grow together. >To aim at that major event we will have three sessions in Chicago: > >1. Constraints >The discussion was started some time ago, but not finished. >I will send some material later today or tomorrow morning to enable >everybody to study it ahead. >We will have DTD files as well as XML files. > >Statements to decide: >1.1. Conditions for constraints can be combined with AND and/or OR. >By nesting conditions recursively the number of levels and the complexity >possible is practically indefinite. >This allows a very flat architecture concerning the features of a printer >model, as all dependencies and interdependencies will be handled as >constraints. >1.2. Constraints will support the default action Filter. >Should it support messages? See proposals. >1.3. Constraints can also be used to handle conditional selections. >Select is considered an additional action. >1.4. Constraints are mainly known as an instrument to avoid conflicts in the >user interface of the driver's dialog. >The current proposal is supposed to be able to set conditions on almost any >combination of fields. Those constraints can also be used when composing >print files. > >We will take samples from paper handling, as that is known as an area full >of constraints. > >2. Overall architecture >The discussion about constraints will automatically lead to a more global >conversation about the overall architecture. >In case constraints work perfectly we may be able to flatten out the >architecture a bit. >2.1. Installable Options >We will see that constraints have serious impact on the handling of >installable options. >2.2. General extensibility >How easy should it be to add an installable option or new locale without >touching the original files? >This will be a discussion about a file structure. >2.3. Although a Universal Printer Data Description is considered platform >independent it should provide all information the operating system is >expecting. >What operating systems are exactly to be considered? >2.4. Linux >How much can the UPDF group help the Linux guys to implement an application >and a printing interface? Do we want to be involved? Do they want to be >involved? > >3. Font handling >3.1. Open questions about the font handling concept so far. >3.2. We want to prepare at least one sample implementation of a device >resident font. >This sample font(s) should be demonstrated in Boston. >We want to get information about how easy it will be to create the >information automatically, how big such a standard font may be in XML and >how this information can be used best during install and runtime. > >Regards >Norbert Schade > > From norbertschade at oaktech.com Tue Sep 5 18:59:19 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> constraints Message-ID: <003301c0178c$ed071ae0$510714ac@nschade-w2.xionics.com> Attached files show two approaches for constraints: The one with the suffix 'Small' is leaning towards today's well known constraint architecture with the exception of nested conditions. The implementations basically show the following constraint: if ( (MediaSize != Letter) && (MediaSize != A4) ) if ( (InputTray == Tray2) || (InputTray == Tray3) ) if (Duplex != Simplex) Filter(MediaSize); We will talk about some 'well-conformed constraints' and give recommendations on how to build proper constraints. Figure that the model supports Letter, A4, A5 and A6 as media sizes. The upper sample should not start with if ( (MediaSize == A5) || (MediaSize == A6) ) which is allowed by the syntax. You do not want to exclude the bad ones by listing them, but by listing the good ones and exclude ALL others. That will help in case an installable option input bin 'Optional Tray 8' has no chance to add media sizes to tray 2 or 3 when concentrating on creating constraints for the installable option only. I consider this a very important detail and we should spend some time on it to fully understand it. The differences in the XML files just show variaties of implementation. There is always a top condition! In the sample it is a set of conditions on MediaSize. This makes them kind of unidirectional. The same condition cannot be read for the case that duplex is not simplex and some constraints get active in that case. Nested conditions reflect AND combinations of conditions. Sets can be grouped on the same level and nested. On the same level they represent an OR. Only Sets can be ORed. In case somebody wants to OR conditions this requires separate constraints. This ensures some readability. Otherwise the temptation is too big to combine more or less everything into one tremendous constraint. I downloaded a Windows 9x printer driver for the HP LaserJet 8000 PCL 5e from HP's site. I'd like you to do the same. You may want to check some constraints on the paper tab starting with the default setting. 1. Select A5, select Tray 2. -> OK message with greying the paper source and selecting Tray 1. This involves messages and selections in the proposal. 2. Select Tray 2, select A5. -> OK/Cancel message. Cancel resets the media size, OK activates the new media size selection and changes everything else if necessary. Neither in sample 1 nor in 2 filtering is involved as an action. Minimum familiarity with XML Authority (or similar application) and XML Pro (or similar application) is assumed. All Full sample XML are based on the Constraints_FullFeatured.DTD. The Small sample XML is based on the Constraints_Small.DTD. The Full1 sample XML is exactly mirroring the Small sample, just based on the Full DTD. In this case I only had to add the Filter action, which is redundant in the Small DTD, as filtering is the only supported action. You see that any developer can concentrate on filtering only even with the Full DTD, as the message and select branches are optional. The samples are fully featured, although re-editing will be necessary once the concept is fully blown up. -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full1.xml Type: text/xml Size: 777 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full1.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full2.xml Type: text/xml Size: 945 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full2.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full3.xml Type: text/xml Size: 1125 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full3.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_FullFeatured.dtd Type: text/dtd Size: 4198 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_FullFeatured.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_FullFeatured.gif Type: image/gif Size: 3139 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_FullFeatured.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.dtd Type: text/dtd Size: 1346 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.gif Type: image/gif Size: 1831 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.xml Type: text/xml Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small.xml From norbertschade at oaktech.com Wed Sep 6 12:45:58 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> constraints spec Message-ID: <000901c01821$ef5227a0$510714ac@nschade-w2.xionics.com> Find attached the constraints specification document for developers. Please have it ready at the conference next Monday. We will talk about it. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000906/15054083/constraints.doc From lfarrell at cissc.canon.com Tue Sep 26 14:12:45 2000 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:04:49 2009 Subject: UPD> UPDF Meeting Minutes -- Sep '00 Message-ID: <6C940F5153E5D211937A0090274E8D8B11EAE5@cissc.cisoc.canon.com> Norbert Schade requested me to post his Minutes. They are now available at: ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.doc ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.pdf ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.txt lee ====================================== Lee Farrell Canon Information Systems 110 Innovation Drive Irvine, CA 92612 ph: (949) 856-7163 fax: (949) 856-7510 lfarrell@cis.canon.com ====================================== From norbertschade at oaktech.com Thu Sep 28 11:55:57 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> preliminary UPDF agenda for Boston Message-ID: <02b301c02964$974083f0$510714ac@nschade-w2.xionics.com> Preliminary agenda for the UPDF meeting in Boston on Friday, Sep 27th 2000. After having finished the printer resident fonts (mainly in San Fransciso) and even constraints (mainly in Chicago) it is time to come back to the bigger picture again with a hopefully larger group to discuss satisfaction with the current level of the spec, open requirements and scenarios of implementation. 1. So I will most likely start with a wrap-up of the current overall level of the spec. 2. The main item of the day will be paper handling with the current spec on constraints in mind. I will send this spec out within the next one or two days and I would very much appreciate that all attendees have a clear understanding of it at the meeting, as the constraints are one of the strong columns this concept is based on. It is only quite a small section. So the study will not be very time consuming. I will prepare more samples to easy understanding. I expect you to ask me questions concerning the constraints spec via email, if there are any. We will review the paper handling section the next weeks to prepare the meeting. I will share the status with the whole UPDF group. 3. Event handlers If there is time to prepare it more in detail and time in the meeting, Event handlers will be another item. Event handlers are considered another strong column of the concept. They are designed to describe the assembly of a print file. There will be a number of global events like JobStart, JobEnd, PageStart, PageEnd plus some specific events, where it might be important to define the exact order of commands to be sent (I could imagine that font download is a sample for such a section). The UPDF developer is supposed to be able to create something like an ordered list. Each element of the list can be selected out of all fields of any feature, which have to do with printer commands. Each Event handler will have a section for PreConditions, Actions and PostConditions. The idea is to be able to tell that certain settings are to be ensured before the event, then do the defined actions (work on the ordered list) and eventually knowing what settings have been changed by sending all these commands, if this is important. I would appreciate some feedback before the conference to get a feeling, how important you consider a flexible code-independent description of the print file structure. If this is considered a minor target, we can drop it. But expect me to fight for it. 4. Predefined variable names The Parameter Converter is already specified on the current level as the first of the three strong columns (a forth one may be added). To specify printer command sequences you need some predefined variable names, which you will use in your formulas. The driver will set them to certain values and it will basically be the input parameters of the function. Example: You need a parameter COPIES to specify any useful formula for copy handling. We have to define a list of those variable names, which any driver/client has to know about. 5. Overall architecture We have to make some decisions on file naming, file structure and other things. We also will review the overall UPDF structure in this session to check for consistency and wholes. Concerning the overall driver/client architecture I still see UPDF taking over where IPP stops. Although UPDF is not exclusively designed to work with IPP, it is leaning heavily towards it to ensure the best possible cooperation between these two concepts. So we like to get some more input from the IPP group, where they see requirements. We consider Boston a major event for the UPDF group and think the spec has grown to a certain level, which provides a much better base for a sophisticated validation than at the beginning of the year. This will and shall affect the way the spec will go heavily. It would be nice to get a head count, who from the group of UPDF attendees in Boston will be available on Thursday and/or Friday night AFTER work. Simple email will do. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000928/eb88f34c/NorbertSchade.vcf From norbertschade at oaktech.com Thu Sep 28 13:38:43 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> conference in Boston Message-ID: <001101c02972$f2b36eb0$510714ac@nschade-w2.xionics.com> Of course, the UPDF meeting is on Friday, Oct 27th 2000, not September. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000928/223e563c/NorbertSchade.vcf From norbertschade at oaktech.com Wed Oct 4 16:40:55 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> new version of constraints spec Message-ID: <000a01c02e43$65216db0$510714ac@nschade-w2.xionics.com> We have finished a new level of the constraints specification. All comments from Chicago are implemented. As paper handling is the area where constraints are mostly used, we are partly working on paper handling as well. Therefore the attached samples are taken from paper handling. I am updating the constraints specification documentation right now and will share it with you shortly. Please take a few minutes to study it. It is small enough. The samples hopefully fill it with life. One open question is how can we provide hooks for proprietary constraints. For now I leave that aside. I will watch how much this is a requirement. Perhaps the concept is flexible enough for all necessary implementations. I copy the IPP group, as constraints have been an issue there for quite a while. Please check whether this proposal can solve your problems. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: application/octet-stream Size: 1871 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/Constraints.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 5187 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/Constraints.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: application/octet-stream Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/constraints.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: application/octet-stream Size: 1404 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/constraints2.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/NorbertSchade.vcf From norbertschade at oaktech.com Wed Oct 4 17:47:45 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> UPDF architecture Message-ID: <00b801c02e52$de50b100$510714ac@nschade-w2.xionics.com> We have started a session in Chicago to specify more details for the final file architecture. We have to consider two areas: DTD files XML files based on those DTD files Concerning DTD files I fought a long time with myself. After having got some expertise in XML and when looking at the whole picture, I am convinced that forcing ourselves to one DTD file has too many disadvantages. I'd like to make two proposals: 1. Locales We will base locales on a separate DTD. Find the DTD, which is a very simple one, plus the specification documentation and two samples. You may look at the sample constraints files (especially constraints2.xml), which will make it more realistic. The documentation tells about the advantages such a solution has, expecially when we think about translating that stuff. There is one decision to make. Do we want the master XML file to know which locales are available? Shall it be possible to add another locale even after the driver is installed on a platform? If yes, the master XML file must be edited when a new locale is added to the system. If no, we need to specify a mechanism to detect locale XML files for a certain master XML file like adding some identification keys. 2. Installable options We have to face a similar question when it comes to installable options. We have dodged the issue long enough. I think that each physical unit (the master unit = the model, optional input units, optional output units, etc) should be represented by a separate XML file. As a unit may include very different features (input trays, duplex unit, RAM - who knows about the future). When trying to base the installable option XML files on the same DTD as the master, we have to make most if not all features optional. Do we want that? 3. Include files While we will have either one logical DTD file or (depending how we answer item 2) one master and one for installable options, we may want to work with different physical files including them to the master. I noticed that this method can save tons of time during development. It is quite simple to isolate an included DTD section and test it with a special XML file only based on that section without having to write or even to look at a complete XML file based on the whole picture. Sample: I sent the new version of the constraints section out today as a separate DTD. It can continue being a separate file when included by the master. Same with fonts, etc. Generally we have to develop a file naming system. I want to prepare this whole issue as much as possible before the Boston conference to just concentrate finding out the final weaknesses and then be able to make some decisions there. This proved to be a very good method the last conferences. We can make it an open discussion on the Internet or you can contact me directly. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: locale english.xml Type: application/octet-stream Size: 744 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/localeenglish.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: locale german.xml Type: application/octet-stream Size: 761 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/localegerman.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: locale.gif Type: image/gif Size: 1415 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/locale.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: locales.doc Type: application/msword Size: 27136 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/locales.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 474 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/UPDFLocale.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/NorbertSchade.vcf From norbertschade at oaktech.com Thu Oct 5 13:29:19 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:49 2009 Subject: UPD> constraints update Message-ID: <000901c02ef1$cd27af60$510714ac@nschade-w2.xionics.com> Please find attached the promised specification documentation. In the meantime I am getting really picky about names of variables, as I've learnt that it is very important to have clean and different names for every element in XML. I've added the previous files, too, as I have updated some variable names. No other changes. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/Constraints.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: text/xml Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: text/xml Size: 1410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints2.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 6967 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/Constraints.gif From hastings at cp10.es.xerox.com Mon Oct 9 03:21:25 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:04:49 2009 Subject: FW: UPD> constraints update Message-ID: <918C79AB552BD211A2BD00805F15CE8503FB68CA@x-crt-es-ms1.cp10.es.xerox.com> I'm forwarding this constraints spec to the IPP FAX DL, so that they can consider it at their Boston meeting, Thursday, 10/26 (the day before the UPDF meeting in Boston). The IPP FAX WG and the UPDF WG group should see if there is a way to converge the constraints specification to a common one. The IPP FAX primarily needs constraints for generating TIFF/FX and for interaction between IPP Job Template attributes. The UPDF group needs constraints for generating any PDL data. Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, October 05, 2000 10:29 To: UPD group Subject: UPD> constraints update Please find attached the promised specification documentation. In the meantime I am getting really picky about names of variables, as I've learnt that it is very important to have clean and different names for every element in XML. I've added the previous files, too, as I have updated some variable names. No other changes. Norbert Here is the previous message with more about the constraints proposal from the UPDF group. Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Wednesday, October 04, 2000 13:41 To: UPD group Cc: IPP Group Subject: IPP> new version of constraints spec We have finished a new level of the constraints specification. All comments from Chicago are implemented. As paper handling is the area where constraints are mostly used, we are partly working on paper handling as well. Therefore the attached samples are taken from paper handling. I am updating the constraints specification documentation right now and will share it with you shortly. Please take a few minutes to study it. It is small enough. The samples hopefully fill it with life. One open question is how can we provide hooks for proprietary constraints. For now I leave that aside. I will watch how much this is a requirement. Perhaps the concept is flexible enough for all necessary implementations. I copy the IPP group, as constraints have been an issue there for quite a while. Please check whether this proposal can solve your problems. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/Constraints.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: text/xml Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: text/xml Size: 1410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints2.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 6967 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/Constraints.gif From norbertschade at oaktech.com Mon Oct 9 15:31:51 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> the big picture Message-ID: <002201c03227$94f0db60$510714ac@nschade-w2.xionics.com> We want to save the current version of the UPDF DTD. So I copied it to updf1.dtd indicating that this was the first level of that UPDF DTD. We have to do that on the UPDF site, too. I am editing the updf.dtd to bring the new pieces together. The attached version is still unchanged just to get you familiar with it. We are going to work in section DeviceCap.Features, PrinterCap, Features. I am removing the layer "Global". All features will live on the same level directly assigned to Features. The features PaperMedia, PaperHandling, FINISHINGS will be handled in "UPDF PrintMediaHandling.DTD", which is the former "Paper Handling.DTD". This DTD will be included in the master DTD. Dimension for print media handling will be centimeter/10000 all over the place. This is definitely small enough to work for rounding. It is resolution independent. It is the unit used in NT systems (this reason has lowest priority). We are removing as much of the locale specific stuff out of the technical DTD as possible. That forces us to think about defaults in detail. I have moved it to the "UPDF Locale.DTD", where it belongs. See attached DTD. The question is the best implementation there. As before the main goal is to simplify creating or deleting locales as much as possible. With a defaults section in the locale DTD a file copy will provide all creation of new tags. The current updf.dtd still has locale settings all over the place, which needs editing at many different places when we want to add a new locale. If there are problems so far, speak now. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: updf.dtd Type: text/dtd Size: 31461 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/118168e0/updf.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: text/dtd Size: 864 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/118168e0/UPDFLocale.bin From norbertschade at oaktech.com Mon Oct 9 15:37:21 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> constraints review Message-ID: <000301c03228$59876520$510714ac@nschade-w2.xionics.com> The current version of constraints are out for some days now. I want to give everybody a chance to review it. As I want to decide on the current structure, I am setting ourselves a limit until Friday, Oct. 20th. We need a reliable constraints structure, when we want to be productive on paper handling. Please concentrate on the structure, not on variable names or parameter values. I'll be in the office the next three weeks continuously. So I am ready for questions and input. Regards Norbert From norbertschade at oaktech.com Tue Oct 10 16:42:59 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> preconfigured drivers Message-ID: <00e901c032fa$ad63b720$510714ac@nschade-w2.xionics.com> I know that many printer manufacturers are looking for a chance to help their customers with preconfigurations of drivers. That's mainly something requested by supervisors and network administrators. These people are typically driver and installation experts. So they would like to prepare a customer specific configuration, which all end-users in that company would use when installing that driver. It would not be too difficult adding an optional key like "Preconfiguration" to each feature (independent from any locale), which would fulfil exactly that request. Do you think these supervisors and administrators would feel comfortable adding an XML keyword for each setting, which they want to differ from the printer manufacturers default setting or does that sound unreasonable? They normally (if we do not prepare something extra for that or printer manufacturers provide that on their site) would not have the DTD file for validation. So there is some danger to mess it up. On the other hand a standard XML editor is quite simple to use. Tell me your opinion. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001010/29c5f889/NorbertSchade.vcf From norbertschade at oaktech.com Wed Oct 11 14:40:42 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> DTD structure Message-ID: <000901c033b2$c4a64480$510714ac@nschade-w2.xionics.com> We have to decide on the overall file and include philosophy of DTD files. As proposed some days ago, it has some advantages to split sections of the whole DTD into separate DTD file and include them in the technical master file. Please study attached files. The "UPDF Constraints.dtd" (previously named "constraints.dtd") is unchanged to the last version. Search for "Constraints" in the technical master "UPDF.dtd". See the call from PrinterCap somewhere in line 267 and the reference to the include file in lines 814, 815. Open XML Authority (or similar app) and click around watching the icons with the crosschecked red line. These descibe the modules of the include file and are not edited. Open XML Pro (or similar app) and see that I have added some simple constraint for demonstration purpose only below PrinterCap. It all works fine. This proves the functionality. Please ignore the problems with the validity. We still have to clean up some legacy problems from earlier work. I'll try to work on that before the conference as much as possible. If I do not hear any contradiction this week this philosophy will be decided and we will use it for other sections like fonts, too. Regards Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 18072 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/hplj8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/UPDFConstraints.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: updf.dtd Type: text/dtd Size: 30267 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/updf.bin From norbertschade at oaktech.com Wed Oct 11 14:57:55 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> UPDF status Message-ID: <000b01c033b5$2ce24f60$510714ac@nschade-w2.xionics.com> Ladies and Gentlemen, I think we get some stuff together these days. It is not so much inventing new functionality or write new XML. It is much more bringing the pieces together and lining it all up. I assume everybody recognizes that the big pictures is making progress, now that we have two more sections well prepared and are grinding through the remaining problems. And we get some good news from the industry proving that our activities are considered more seriously than half a year ago. I would like to get a preliminary count who is intending to attend the UPDF day in Boston to get a feeling for sample printouts, etc. BTW: Oak Technology may attend with a group of four people including me. The more you participate in the current email discussion, the better the conference will be prepared. Thanks so far Norbert Schade Principle Software Engineer Oak Technology Inc., Imaging Group From norbertschade at oaktech.com Thu Oct 12 17:19:15 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> corrected versions Message-ID: <001401c03492$1325fc60$510714ac@nschade-w2.xionics.com> I have worked hard to correct all the problems with the old XML file based on the old technical master UPDF.DTD. I tried to stay with the structure as much as possible by making some elements optional, adding some small pieces here and there. Now the DTD as well as the XML file should be error free. I got a successful validation in my XML editor. The warnings (no error!) I get in XML Authority 1.2 are a current limitation of the application. I am in contact with them. See note: """The yellow warnings Authority issues when loading the DTD are a current limitation of Authority's support for this type of structure. You are correct, this is valid. Authority supports this, but needs to fully expand the attribute type. The logical structure is not changed, Authority's yellow warnings are just telling you that the source will be saved as you see it in the source pane. The next release of Authority is targeting full support of these structures as you have written them. If you have any further questions, impressions, suggestions, etc. please don't hesitate to contact me again. """ (comment from extensibility) The "UPDF Constraints.DTD" has not changed. That is another step to come to the big picture. Now we can work with the master dtd, which already includes the dtd for constraints. While reviewing the sections and working on paper handling, we can clean up. I want to discuss one common feature out of paper handling publically in the Internet as a sample. I think print media size is the most important. So let's take that. The point is to get all necessary information together. I can wrap it into XML, as I have improved on the syntax. It's not mainly about XML, but I would like us to use standard applications to see the structure. That is possible without understanding one line of XML. I'd like to have a continuous contact in the IPP group for some time when working on paper handling. It's about implementing IPP keywords the best way. To make everybody understand the issue: This is affecting the way a driver is feeding and listening to a language monitor or similar functional unit in a client. We will make some basic decisions, what a driver can expect from a UPDF to assemble perfect IPP. If we can work the architecture out during the bake-off next week, that would be perfect. The real discussion should not be much more than an hour. The rest like assembling lists can be done by email. Regards Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 19815 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001012/be229343/hplj8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: text/dtd Size: 32633 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001012/be229343/UPDF.bin From norbertschade at oaktech.com Mon Oct 16 11:38:18 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> DTD architecture Message-ID: <000b01c03787$1bce6e40$510714ac@nschade-w2.xionics.com> There were no complaints about the new DTD architecture. The time limit ran out last Friday. So from now on we go with one technical master dtd (UPDF.DTD) and one locale dtd (UPDF Locale.DTD). The master dtd will refer to a number of modules, which are be included. For now we have identified three modules: 1. constraints (UPDF Constraints.DTD) This reference is already implemented. 2. print media handling (UPDF PrintMediaHandling.DTD) This reference will be implemented this week. 3. font handling This reference will be implemented later. There are some more details like attributes to be cleared by that is ready to be implemented. I think about one separate module for all entities. Others may follow. We want to accomplish a number of targets with that architecture. 1. It will be easier to develop single modules. 2. It will be easier to test single modules. This probably will save the most time. 3. Development can be shared by a number of people. 4. It is easier to get an overview about one section. Regards Norbert Schade From norbertschade at oaktech.com Tue Oct 17 09:30:44 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> Mike Yeung's email address Message-ID: <001701c0383e$74b7bc20$510714ac@nschade-w2.xionics.com> Mike, in case you still watch the UPDF emails, please answer. I have some questions about the meaning of certain fields, which I think only you can explain, as they may be from the original dtd. If somebody from Toshiba is listening and has his contact, please forward this to him. thanks Norbert Schade From norbertschade at oaktech.com Tue Oct 17 11:21:26 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> new architecture, next step Message-ID: <001c01c0384d$ebe710c0$510714ac@nschade-w2.xionics.com> We finished another step of the new architecture. Now all entity definitions are gathered in one external DTD. As an external DTD can only be connected to the calling one by the top element, we had to create an optional dummy element "OptionalDummyElementForExternalEntities". If anybody has a problem with that minor inconvience, please reply. This element does not need to be defined in any XML file. The main advantage of this structure now is that entities, which have to be defined for several dtds, are now central. One definition is enough. Whenever the structure of any dtd changes - even when elements will be moved from one dtd to another - we need not touch the entities. For my personal feeling this is the final design. From now on we will just talk about isolating some more sections into external dtds, which just means duplicating the process carefully at some other place. Just keep in mind that the "UPDF Locale.dtd" is not an external dtd, but a separate, independent one. BTW: Of course, dtds will not appear on the end-user's workstation. Only the XML files will show up there. Dtds are only necessary to validate the XML on the developer's workstation. So this whole discussion will not affect the end-user at all. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 11498 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/hplj8150.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: text/dtd Size: 20644 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDF.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: text/dtd Size: 5183 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFPrintMediaHandling.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: text/dtd Size: 5296 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFEntities.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: text/dtd Size: 2112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFConstraints.bin From norbertschade at oaktech.com Wed Oct 18 13:07:59 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> external entity for entities Message-ID: <000301c03925$f8a4d8a0$510714ac@nschade-w2.xionics.com> I learnt today that every external module accessing entities must as well include the entities entity. So I copied that over from the master dtd. Now I have access to the entities in print media handling. This needs further testing. Norbert Schade From norbertschade at oaktech.com Tue Nov 7 15:58:32 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> meeting minutes Boston UPDF conference Message-ID: <004901c048fd$7e0d4ae0$510714ac@nschade-w2.xionics.com> Please find attached the meeting minutes in three different formats. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: Meeting Minutes UPDF Group 1000.doc Type: application/msword Size: 24064 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001107/48813492/MeetingMinutesUPDFGroup1000.doc -------------- next part -------------- Minutes of the UPDF Working Group Meeting October 27, 2000 Meeting Attendees Mark VanderWiele IBM Shawn Flynn Bitstream Don Wright Lexmark Carl-Uno Manros Xerox Dave deBronkart PODi Jim Sommer Granite Systems Ron Bergman Hitachi Lee Farrell Canon Norbert Schade Oak Technology With the IPP bake-off in the Oak facilities just behind we met in Boston, which I consider my home conference. Therefore I put some extra effort into the preparation. I think it paid out. The general direction for the meeting was to provide the big picture and to move several components together to the big common structure. Major items discussed ? File structure of the UPDF DTD files Please recall some emails on the distributor from October 2000. We agreed that we split the big dtd into a technical dtd and a separate dtd for locales. The technical master is split into a master and a number of modules. These modules are realized as external dtd. We agreed on the following modules: Font handling, Print media handling, Constraints. Other modules will follow. It is not planned to define more than ten modules. Each module presents a large logical unit. It is easier to develop and test those smaller modules by temporarily converting it into a standalone dtd and build sample XML files on top of it. This is quite an easy process. We agreed on building one special external module for all entities. This file structure has to be checked with the intended XML file structure explained below. It may be necessary to separate the external modules into separate dtd. Consulting requested! ? File structure of the UPDF XML files Although XML seems to be weak in this area, the group is leaning towards modular units. It is my (Norbert Schade) understanding that each module is exactly based on one external dtd or the master dtd. There are no arbitrary compositions. E.g. it would not be allowed to build one XML file for print media sizes and another for finishing features. This has to be assembled into one XML file for print media handling based on the print media handling dtd module. This procedure creates reusable modules. We have to continue working on the proper references. Do we want to define certain file naming conventions and/or internal references. Something like a module script file would be another alternative. Consulting requested! There will certainly be one XML file per locale based on the locale dtd. References to be done. ? Installable options We were more or less agreeing to use the same technical dtd for installable options, too. As almost all features in the technical dtd are optional, any installable option description would have the same structure as a basic device description. It would just be much smaller typically. No installable option description would have a reference to any device. It's the other way around. A basic device description has references to installable options. That allows reusability of single installable options. An installable option would have its own locale descriptions. I am preparing a picture to demonstrate the different units. Although this is quite a complex and laborious discussion, I am glad we entered it eventually. That shows that developers have started thinking how to convert their current data into an UPDF format, how quickly a new device description could be created by assembling several pieces from previous descriptions. It also shows how much different people already think about how a driver would best use the information for a specific operating system. Two other areas drew our attention: ? Reference list for features, which have to be identified by at least one operating system, e.g. paper sizes. We certainly need a list for that. Basically we could take any list available in the market or create a new one (only recommended in emergency cases). Right now we are looking over our shoulders to the IPP group asking whether they do or are willing to provide these lists. Carl-Uno, this is something we should talk about. ? Event handlers We talked about the basic idea and it looks, as if it is accepted. It needs some detailed samples to examine the value of this conceptional feature. To be further investigated. I think the most important item on our to-do list is resolving all the issues with the file structures and the references between the files. Please think about it, wait for some simple pictures I am preparing right now and give me some feedback. prepared by: Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: updf-minutes-001027.pdf Type: application/pdf Size: 7818 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001107/48813492/updf-minutes-001027.pdf From norbertschade at oaktech.com Tue Nov 7 16:54:27 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> upcoming conferences Message-ID: <006401c04905$4e83d2a0$510714ac@nschade-w2.xionics.com> We will meet in San Diego on Monday, Dec 4th. I am happy that we have got a Monday and no parallel conference the first time. We got some positive input from some companies in California. I am looking forward to continuously get more people from real driver development involved. We need these people to get feedback, where problems with current driver concepts are, which we want to overcome. And I know there are a number of companies in driving distance. So I hope to see a number of programmers there. During the Christmas / New Year season I'll be in Europe for about three weeks (private). That keeps me away from preparations for Hawaii for some serious amount of time. We haven't created some sample font data in the new format developed in San Francisco so far, which is necessary before we can extend it and check for Asian fonts (vertical writing). Extensions for Asian fonts was one of the agenda items for Hawaii expecting some Asian developers show up in that case. Mark VanderWiele from IBM does not seem to be available for Hawaii. Taking all that together the UPDF group will not meet in Hawaii. We will meet again during the PWG conferences in March and April. That gives us enough time to the April conference another major event for UPDF. To confirm it: We will meet Monday, 4th, in San Diego (preliminary agenda coming soon). We will not meet in January in Hawaii. We will meet in March and April. Regards Norbert Schade From norbertschade at oaktech.com Wed Nov 8 13:41:37 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> file structure sample Message-ID: <001e01c049b3$8857c140$510714ac@nschade-w2.xionics.com> Find attached a sample for the file structure we talked about before and during the Boston conference. Please take a careful look and note: 1. The green elements are dtd files. "UPDF Entities" can be invoked by any other dtd as an external dtd and is intended to be so. "UPDF Locale" is a standalone dtd, separate from UPDF.dtd. You see that there are lines going from UPDF.dtd to the three light green dtd files. The lines shall indicate that the light green dtd files are external dtd files to the UPDF.dtd. In case we want to create physically separate XML files for sections like print media handling, I'm afraid we have to remove these lines and convert the light green external dtd files to standalone dtd files. Otherwise I'd expect problems with validation. By removing the lines we'd cut the connection to the master dtd. 2. The master XML file (I chose the extension upd for all XML files in my sample) without any background color has tags for internal modules, installable options and locales. These units themselves do not have any reference back to the master unit. In this sample we are not working with a script file, but the tags holding the references (in this case file names). That implicitely requires that the master unit knows about the additional modules. In case a module (like an installable option or a new language) will be added late after shipment of the original device the master unit has to be edited. I want us all to be aware of that. 3. XML files names are arbitrary in this sample, as long as they are referenced correctly in the master unit's tags. 4. Basically all yellow modules can be shared between master units like "80 PCL XL fonts.upd" is shared by Printer A and Printer B. A developer certainly had to draw his/her attention to the constraints to make sure the constraints are not model specific. 5. Installable options can be shared between devices like "Input Unit 1.upd" is shared by Printer A and Printer B. 6. Theoretically XML file for locales could be shared, too. In reality I think this will not happen, as something like the model name is always different. 7. The installable options are completely separate modules. They can be added and removed quite easily as a whole unit by editing the master XML of the printer (or a script file, if we decide so). A developer can decide not to support installable options for some time to get his project running and that would be perfectly fine. Just the UPDF architecture should be open to extend it. Basically he could even leave out the support of locales for some time and just use the name id reference instead, which may not be a nice UI string, but it could be used as a string, and use the first element as default simply. But I want us to set the directions for all those extensions, that as few code as possible has to be changed to extend the functionality. 8. I was thinking about a different file extension (uld = universal localization & defaults) for the locale files. For now I take that back. 9. Installable options may have different locales than the master unit. I recommend to make one locale mandatory (US English) and use a kind of fallback mechanism to select a proper substitution. The UPDF group could provide some fallback recommendations, if required. Please keep in mind: We are discussing the dtd and the XML file structure. That does not necessarily mean that the XML files are the files used by the driver. They could, but they need not. A driver (or a correspondent installer) could create some platform specific binary data out of it - for performance or other reasons. This is a separate issue and I want to leave that open to the driver developers. In case people request some conceptional ideas, the UPDF group may think about some recommendations. Ok, I would like us to finish this discussion in San Diego. So let us work it over in the upcoming weeks. Waiting for comments. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: File structure.ppt Type: application/vnd.ms-powerpoint Size: 50688 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001108/5196e325/Filestructure.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: file-structure.PDF Type: application/pdf Size: 11141 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001108/5196e325/file-structure.pdf From norbertschade at oaktech.com Wed Nov 8 13:55:31 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> preliminary agenda for San Diego Message-ID: <002401c049b5$7979af60$510714ac@nschade-w2.xionics.com> I would like to concentrate on the file structure the next four weeks and get that nailed down in San Diego. This has the top priority. It includes the clear definition how many internal modules we want to have (e.g. Font handling, Print media handling, constraints). I hope we'll make some progress with the print media handling dtd module, which then can be evaluated in detail in San Diego. If there is time before and during the conference - and that depends how many people will contribute - I'd like to prepare the building of a few sample device resident fonts. I'll wait whether some other issues will pop up in the distributor. The closer we come to a sort of full scaled format, the better we can cooperate with other standards like the PODi or some Linux activities. I want to show and prove our readiness and interest here. The closer we come to a sort of full scaled format, the better we can talk about details to developers for an optimal implementation. That is another area, where I start reserving some time in my mind. The UPDF group has pointed out several times that we want to provide active help during implementation of the format into drivers. Regards Norbert Schade From norbertschade at oaktech.com Fri Nov 10 10:22:52 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> registered parameters Message-ID: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Some operating systems insist to be informed about certain features. Print media sizes are a good sample. A universal client/driver has to know about all predefined parameters for all features any OS is interested in. There is no way around it! There are two ways to go: 1. A universal description like UPDF lists all keywords for all OS (the list is not too big) and offers the developer of the description a list of predefined parameters. For the sample print media size this could come out as a combo for registered MS Windows parameters. There could be another combo for McIntosh parameters and other combos, if Linux has new requirements. 2. We use a common reference and leave the conversion from the common reference to the OS specific one to the client/driver. In this case the list MUST be a superset of all registered parameters for all features in all OS. 2a. In the last UPDF conference we were talking about using registered IPP values as a common reference. The question is whether IPP wants to extend their lists to the required amount. For the sample print media sizes MS Windows is supporting about a good 100 predefined values, which of course then all must be supported. 2b. Theoretically there is the chance that the UPDF group makes up its own list. But we want to be very careful not to confuse developers with just another list of parameters. As far as I know the list includes the following features: Print media size Page orientation Print media source Duplex Print media type There some more when it comes to Print quality or Font handling like download formats. In Boston the UPDF group requested to find out how much IPP can and will provide the necessary list. That would require to extend some lists and maybe create new ones in IPP. It is to be discussed whether this would just be a merge of all known predefined parameters or IPP tries to sort out doubles and minimize the list as much as possible. This would leave some responsibility (and chances for error) to the driver developer. I need feedback on this during the upcoming week. Selection 1 would leave that responsibility to the developer of the UPDF. He'd have to do some more entries, but has more flexibility on the other hand to specify a certain feature exactly as he wants. It would be easier for driver developers. They'd just read the proper field for their announcements. We have to decide on this the next days. It is an important detail in the UPDF spec. So please provide your comments in the distributor. Regards Norbert Schade From markv at us.ibm.com Fri Nov 10 10:53:58 2000 From: markv at us.ibm.com (Mark VanderWiele/Austin/IBM) Date: Wed May 6 14:04:50 2009 Subject: UPD> registered parameters Message-ID: For me there is only one real option which is to keep the IPP and UPDF definitions in sync where they have common components and extend the IPP list where necessary. Note, IDs are good for fast matching, however we must supply enough information so that the system does not stop when it is presented with a new ID. For example I do not like systems which are completely reliant on predefined knowledge of form ID's and there sizes. When a new form or custom form comes along the system falls apart. More specifically, some word processors store the form ID returned from the driver in the document which may be a custom form and make no sense to another OS or across the network. Regards, Mark VanderWiele IBM 512-838-4779 email: markv@us.ibm.com From mike at easysw.com Fri Nov 10 12:13:35 2000 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:04:50 2009 Subject: UPD> Re: IPP> registered parameters References: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Message-ID: <3A0C2CBF.5F2CD5D@easysw.com> Norbert Schade wrote: > ... > 2a. In the last UPDF conference we were talking about using > registered IPP values as a common reference. > ... > As far as I know the list includes the following features: > Print media size > Page orientation > Print media source > Duplex > Print media type > > There some more when it comes to Print quality or Font handling like > download formats. > ... First, please *do not* rely solely on a keyword-based media size attribute. Such things are nice for the standard sizes but completely ignore variable sizes. You should allow keywords *and* measurements, which allows the driver/printing system to do any necessary mapping to the "native" value(s). Along with variable size support you'll need to communicate the minimum and maximum media sizes supported. FWIW, if you haven't done so already, please look at Adobe's PostScript Printer Description specification. It has its limitations (no "range of values" type of options, only supports PostScript directly, can only provide a single UI language in each file, etc.), but it *does* address most of the issues that you are looking at now for describing printer options. For example, PPD files provide named sizes plus the page dimensions and imageable area for the printer. Variable size support includes orientation, min/max width/height, etc. This all allows you to map Windows/MacOS/UNIX/IPP media sizes to PPD sizes and visa-versa, and to support variable sizes as needed. FWIW, CUPS (http://www.cups.org) uses PPD files and maps the IPP attributes to PPDs and visa-versa. We've added additional CUPS- specific attributes to PPDs for non-PS printers to support extra printer drivers, etc. It works quite well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Fri Nov 10 13:20:12 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> Fw: IPP> registered parameters Message-ID: <006801c04b42$def81960$510714ac@nschade-w2.xionics.com> Ok, Ok. Don't shoot me. I should have been more specific. I considered it common knowledge that a predefined parameter ID is only used additionally to numeric values for width, height and some other necessary parameters. I never questioned that and the current version of UPDF has that incorporated. I just want to set clear how far a UPDF format would take predefined parameters into consideration. Hoping to interpret Michael's and other comments right there is another option. 3. Do not specify any predefined parameter for any paper size. Leave that to the OS specific driver/client relying that it knows about width and height of predefined OS specific print media sizes (to stay with the sample) and assign them by interpreting the printer's values for width and height. So the driver would discover the proper predefined parameter for such an OS. It needs some rounding functionality. Probably this would be done once during installation or so. This puts some more burden to the driver developer of such an OS, but it is a clear statement. This could work well for this specific sample print media size. We'll have to see whether we'll find clear technical parameters for any feature. I put this option for vote. Regards Norbert Schade -----Original Message----- From: Michael Sweet To: Norbert Schade Cc: UPD group ; IPP Group Date: Friday, November 10, 2000 12:31 PM Subject: Re: IPP> registered parameters >Norbert Schade wrote: >> ... >> 2a. In the last UPDF conference we were talking about using >> registered IPP values as a common reference. >> ... >> As far as I know the list includes the following features: >> Print media size >> Page orientation >> Print media source >> Duplex >> Print media type >> >> There some more when it comes to Print quality or Font handling like >> download formats. >> ... > >First, please *do not* rely solely on a keyword-based media size >attribute. Such things are nice for the standard sizes but >completely ignore variable sizes. You should allow keywords *and* >measurements, which allows the driver/printing system to do any >necessary mapping to the "native" value(s). > >Along with variable size support you'll need to communicate the >minimum and maximum media sizes supported. > >FWIW, if you haven't done so already, please look at Adobe's >PostScript Printer Description specification. It has its >limitations (no "range of values" type of options, only supports >PostScript directly, can only provide a single UI language in each >file, etc.), but it *does* address most of the issues that you are >looking at now for describing printer options. > >For example, PPD files provide named sizes plus the page dimensions >and imageable area for the printer. Variable size support includes >orientation, min/max width/height, etc. This all allows you to map >Windows/MacOS/UNIX/IPP media sizes to PPD sizes and visa-versa, and >to support variable sizes as needed. > >FWIW, CUPS (http://www.cups.org) uses PPD files and maps the IPP >attributes to PPDs and visa-versa. We've added additional CUPS- >specific attributes to PPDs for non-PS printers to support extra >printer drivers, etc. It works quite well. > >-- >______________________________________________________________________ >Michael Sweet, Easy Software Products mike@easysw.com >Printing Software for UNIX http://www.easysw.com > From sommer at granitesystems.com Fri Nov 10 13:53:36 2000 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:04:50 2009 Subject: UPD> registered parameters In-Reply-To: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Message-ID: <4.2.0.58.20001110133011.0095ed20@mailbox.bellatlantic.net> Windows applications can ask for the following printer information: 1) Paper Name (user string) 2) Paper Number (Windows defined DMPAPER_* number or custom size using a value greater than DMPAPER_USER) 3) Paper Size 4) Paper Margins 5) Maximum Paper Size 6) Minimum Paper Size 7) Source Name (user string) 8) Source Number (Windows defined DMBIN_* number or custom source using a value greater than DMBIN_USER) For a truly independent universal description file the name and dimensions must be provided for all supported sizes. It's not a difficult job to match those sizes with the platform predefined sizes. There should also be a way to indicate if the user can define their own paper sizes in addition to the list of supported standard sizes. For constraints this means not only specifying the supported sizes but also specifying a range of user defined sizes that the constraint applies to. Jim From Jim.Lo at eng.sun.com Tue Nov 14 15:37:08 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:04:50 2009 Subject: UPD> registered parameters Message-ID: <200011142037.MAA22768@mpk07.Eng.Sun.COM> 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) // //The following substrings as qualifiers have special meaning ... // // ENV: Envelope papers. // // JENV: Japanese Envelope papers. // // PENV: Chinese (PROC) Envelope papers. // // EXECUTIVE: The paper size varies by as much as 0.5 inch across devices. // // EXTRA: To print crop marks and bleeds marks in the margins, an extra size designates // a page size slightly larger than its corresponding standard size. However, // the increase in size (typically 0.69 to 1 inch) varies from a device to another. // // ROTATED: The image is rotated relative to the corresponding standard size. This // would usually produce a landscape image on the paper (the x dimension is // longer than the y dimension) // // SMALL: A paper that is the same physical size as the regular standard paper except // its printable area is typically 10 to 20 points smaller. // // TRANSVERSE: The long edge of the physical paper is perpendicular to the feed direction. // It is opposed to the cases where most printers feed paper with the // short edge of the paper perpendicular to the feed direction. // //Notes: // // Dimension values enclosed in {} are specified in points (1 point = 1/72 inch; // 1 inch = 25.4 milimeter) // Dimension values enclosed in [] are specified in their original measurement unit B. Feature/Option Display Names For en-US Locale (PaperSize etc) //For en_US locale: // //The human-readable display strings are arranged in such a way that major keys come before minor keys. //Taking PaperSize as an example, a country or area name comes before anything else. //Then, a standard paper size name comes with zero or more variant qualifiers, such as Rotated and Transverse, //which are enclosed in parentheses. Finally, dimension field in original measurement units //is followed. Note that "North American" is implied if there is no country or area name //is explicitly specified for the sake of compactness in screen real estate. // //It is suggested that translation be performed on a word-by-word basis whenever possible so that //the display strings would be listed on screen more predictably when categorized as a result of //language-specific collation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001114/6057f32e/attachment.html From norbertschade at oaktech.com Wed Nov 15 15:46:02 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> UPDF web page Message-ID: <000301c04f45$12386f40$510714ac@nschade-w2.xionics.com> We have updated the UPDF web page and made a few changes to provide the current versions of dtd and XML files plus some documentation there. Please check it out and tell me, if you have any problems. Regards Norbert Schade From norbertschade at oaktech.com Thu Nov 16 13:33:54 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> UPD drivers Message-ID: <000f01c04ffb$c656b250$510714ac@nschade-w2.xionics.com> At the current state of discussion I'd like to add an item to the agenda for San Diego. We will have some Q&A session how drivers based on the new UPDF files should be built. This could well be a continuous item for the next conferences. I want to keep this short (not more than an hour), as it is not the fundamental work of the group by definition and charter. But I realize that some issues with the description can only be solved when thinking about a real implementation. With the progress we made we just have to take this more into consideration in future. I may outline a chance how a UPD driver under Windows could be designed. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001116/a20a98e6/NorbertSchade.vcf From norbertschade at oaktech.com Wed Nov 22 11:33:05 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:04:50 2009 Subject: UPD> registered parameters Message-ID: <004801c054a1$e40f7520$510714ac@nschade-w2.xionics.com> We have waited for comments on registered parameters until last Friday. The common tenor was to go with technical classifications based on numbers and attributes and not try map that to a global list. The decision is to go with that approach. I hope we'll be able to solve all problems coming up by that. I like to keep the format as clear as possible and not overloaded with nice, but redundant information. I want driver developers to expect a clear and transparent format to work with. So we will not save IPP or other keywords for paper sizes after this decision. We do not want to stop with the pure specification of the UPDF format. We already agreed that we will provide documentation on how to use the different fields and values best. Additionally the group is tending to give more help to driver developers. For now I do not promise sample source code. But things like Jim Lo's list of paper sizes is exactly what I mean by additional help. Putting together such overviews will be the exact help a driver developer is looking for. We may add this list to our documentation on our web site. Perhaps we'll create a special directory like "Driver developement recommendations". I will contact Jim today to find out, whether he is willing to accompany the format as a kind of print media expert. Maintaining that list would be one of the tasks. I'd like to see the list being unique. An Executive paper size should have exactly one value in our list. If a device has a different implementation with other values it will not be detected as the standard Executive paper size, although it could be considered a predefined custom paper size with the same name by drivers. If in doubt I like clear and unique information more than ambivalent documentation, which will not provide the quick orientation people are looking for. I do not like but I'm willing to buy some disadvantages for that. To stay with this sample we will reflect all necessary attributes in the UPDF format. I would like to add some recommendations how to round paper sizes to standard sizes in drivers (define an error range). BTW: This would be a nice area for some sample code, which likely exists already at a number of places. Just keep a number of #define outside the code like StandardSizeErrorRange and UnitRelatedErrorRange (perhaps even per typical unit like inch, mm, etc). Input parameters may be just a pointer to a value (relative to mm/1000, which will be the UPDF unit) and perhaps a unit const (relative to mm/1000; a sample value for mm would be 1000). The return value would be a driver and therefore OS specific standard size or NULL. A driver would refer to his list of standard sizes (structure with OS_ID, width and height in mm/1000). The value may be reset, if discovered as a standard size, as the OS standard size is assuming a slightly different value, or recalculated because of unit related rounding. If anybody will contribute such a small piece of code, we would add it to the recommendations. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001122/859a6e00/NorbertSchade.vcf From Jim.Lo at eng.sun.com Fri Dec 1 15:13:40 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:04:50 2009 Subject: UPD> completeness: commands generation (xpdo) Message-ID: <200012012013.MAA10134@mpk07.Eng.Sun.COM> Hi, Per Norbert Schade's request, I am trying to exchange what many of us working for Sun Microsystem think in many areas of printer description in terms of what may be a must and the possible solutions from the perspectives of looking for a "long term" solution for universal (raster-based) printing services (framework and drivers) under Unix and other platforms. As a new late comer, I am not sure it is a good way or a good timing now but I am doing it anyway ... The first thing I'd like to discuss is the requirement in printer description for run-time evaluation to generate raster data and printer setup commands. I have an impression that it had been brought up to UPDF's attention in the past (by Don Wright of Lexmark?) for the "completeness" of any page description file or otherwise those commands would need to be "hard-coded" somewhere else in C code for which the programming interface needs to be defined (and therefore must be covered as part of UPDF?). Attached (xpdo.nov01.html) for your reference please find the extensible printer description object model based on XML technologies. It is a very simple virtual machine for XML-based printer description language in an attempt to address those command generation issues in addition to custom declaration, modulization and binary encoding etc. My appology that GPD teminologies are used in the document for a demonstration because GPD is the only printer description format I know of that generates raster data for low-cost printers. Table of Content: ----------------- Introduction Data Types: string, name, int, float, boolean, array, dictionary File Modulization for Printer Model Family Hierarchies Executable Objects and Execution Context The load Executable Object and Paramter Dictionaries The switch Executable Object The Math Executable Objects: idiv, add, sub, expr The Formatter Executable Objects: tostring, numformat, maxrepeat Samples in the document: ------------------------ - for raster data commands generation: 5100 {1B}*{03} 12600 {1B}(*p- - for multiple-way runtime dependency (e.g., a printable area depends on the paper size and perhaps the orientation chosen at runtime): - for Custom feature/option (e.g. paper size): Best regards, Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Menlo Park, California From Jim.Lo at eng.sun.com Fri Dec 1 15:21:14 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:04:50 2009 Subject: UPD> completeness: commands generation (xpdo) Message-ID: <200012012021.MAA10336@mpk07.Eng.Sun.COM> <> Hi, Per Norbert Schade's request, I am trying to exchange what many of us working for Sun Microsystem think in many areas of printer description in terms of what may be a must and the possible solutions from the perspectives of looking for a "long term" solution for universal (raster-based) printing services (framework and drivers) under Unix and other platforms. As a new late comer, I am not sure it is a good way or a good timing now but I am doing it anyway ... The first thing I'd like to discuss is the requirement in printer description for run-time evaluation to generate raster data and printer setup commands. I have an impression that it had been brought up to UPDF's attention in the past (by Don Wright of Lexmark?) for the "completeness" of any page description file or otherwise those commands would need to be "hard-coded" somewhere else in C code for which the programming interface needs to be defined (and therefore must be covered as part of UPDF?). Attached (xpdo.nov01.html) for your reference please find the extensible printer description object model based on XML technologies. It is a very simple virtual machine for XML-based printer description language in an attempt to address those command generation issues in addition to custom declaration, modulization and binary encoding etc. My appology that GPD teminologies are used in the document for a demonstration because GPD is the only printer description format I know of that generates raster data for low-cost printers. Table of Content: ----------------- Introduction Data Types: string, name, int, float, boolean, array, dictionary File Modulization for Printer Model Family Hierarchies Executable Objects and Execution Context The load Executable Object and Paramter Dictionaries The switch Executable Object The Math Executable Objects: idiv, add, sub, expr The Formatter Executable Objects: tostring, numformat, maxrepeat Samples in the document: ------------------------ - for raster data commands generation: 5100 {1B}*{03} 12600 {1B}(*p- - for multiple-way runtime dependency (e.g., a printable area depends on the paper size and perhaps the orientation chosen at runtime): - for Custom feature/option (e.g. paper size): Best regards, Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Menlo Park, California -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001201/c73513c2/attachment.html From Jim.Lo at eng.sun.com Mon Dec 4 17:32:23 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:04:50 2009 Subject: UPD> completeness: Printer error/status monitoring (Responses framework) Message-ID: <200012042232.OAA07854@mpk07.Eng.Sun.COM> Hi, Another missing part in a printer description file format (including GPD) may be in the area of printer error/status messages monitoring. It is considered especially important for many new printers that support bi-directional USB (as opposed to traditional one-directional centronic parallel connection that depends on hardware signals for monitoring). For your reference, included is a document in an attempt to address this issue (its HTML version is also attached). I am not terribly familiar with this area which I consider tough because what we are trying to deal with is kind of drawing road maps (printer description files) by a simple tooling methord (the Responses framework) for many existing roads (printer languages) with not necessarily very regular shapes. The printer type that had been addressed in the document is PostScript. I also used a EPSON printer as my target try out in the document not only because I think it is rich and should be quite typical but also that there are simply no programming manuals available in public for many NEW printers. Anyone who like to give the framework a try with another printer or extend the framework if necessary would be helpful to move towards the design goal. Best regards Jim Lo Internet Appliance Group Sun Microsystems, Inc. PS. As you can see, the document is encoded for a demonstration purpose in terms of XPDO objects specified in my previous email. ..... It would be nice to have a GUI on a host machine to monitor a target printer for its possible error conditions and working status changes especially when there is no LCD panel on the printer. It is especially important for printers supporting bi-directional I/O connectivity such as USB (Universal Serial Bus). Those printers usually provide a much richer set of device-dependent proprietary notification and enquiry messages compared to a hardware based interface for the traditional one-directional centronics parallel connection which provides a much limited set of less clearer error/status messages. This document provides a device independent way to describe device-dependent message formats so that most printer vendors can benefit from a common printer-decription-file-driven GUI services in a consistent way without having to write any line of C code for their device dependent messages. The Responses tag and all its predefined nested element tags are introduced to enable dynamic configuration, error, warning and progress enquiry and responses. They are all described in a unified format which is demonstrated by the following two examples for PostScript printers and EPSON inkjet printers respectively: /Code <11> Note that the Responses entry is optional and is not used for a driver operating on a target printer locally connected with a non-bidirectional transport type (e.g., traditional one-directional parallel port). In case of operating in a non-bidirectional mode, commands that require responses from the printer will not be sent down. Instead, predefined hardware signals from a parallel port can be used but with much less comprehensive error/status messages to a human user as demonstrated below in terms of a Unix parallel port I/O interface whose function names should describe themselves: isPrinterTimedOut() => "Not Responding" isPaperOut() => "Out of Paper" isPrinterSelected() => "Off Line" isPrinterError() => "Error" Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Last modified: Mon. Dec 04 2000 13:25:23 PDT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001204/67541bac/attachment.html From sandram at boi.hp.com Mon Jan 31 17:31:39 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:05 2009 Subject: UPD> New Orleans meeting Message-ID: I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From charles.a.adams at opbu.xerox.com Mon Jan 31 17:56:03 2000 From: charles.a.adams at opbu.xerox.com (charles.a.adams@opbu.xerox.com) Date: Wed May 6 14:05:05 2009 Subject: UPD> New Orleans meeting Message-ID: <2B6C906F79BCD2119D1D00805F19A10DE57385@us-wv-m13.wv.tek.com> I also have been sucked into the depths of product development/management. But as I come back up for air I would like us to talk about constraints a bit. Nothing formal just want to hear more about Norbert's work. Chuck Adams Office Printing Business ... Xerox -----Original Message----- From: Sandra Matts [mailto:sandram@boi.hp.COM] Sent: Monday, January 31, 2000 2:32 PM To: Universal Printer Driver Subject: UPD> New Orleans meeting I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From don at lexmark.com Tue Feb 1 10:17:10 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:05 2009 Subject: UPD> New Orleans meeting Message-ID: <200002011558.KAA20628@interlock2.lexmark.com> Any font experts willing to present to the group some background material to get this kicked off? ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** sandram%boi.hp.com@interlock.lexmark.com on 01/31/2000 05:31:39 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> New Orleans meeting I am currently putting the minutes from the last meeting on the web page. At the last meeting, we had discussed spending some time on fonts and other parts of the UPDF that is more related to paper handling and printer features. Due to matters outside my control - I have had no time to spend on UPDF. Therefore, I am soliciting agenda items to discuss on Friday. If anyone has any items to contribute, please reply to this email and let me know. At the last meeting we spoke about constraints. We may be able to spend some time on that. Sandra Matts From nschade at xionics.com Tue Feb 1 13:48:21 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:05 2009 Subject: UPD> fonts Message-ID: <000201bf6ce4$fd691990$c31343ce@gca-2.xionics.com> I would not call myself the absolute font expert, but I know this and that. I invited Bitstream on January, 13th, to Oak (formerly Xionics, most of you may have heard that the merge now is public and legal) to talk about the subject. They were interested in visiting the group. I told them about the next meetings of our group especially mentioning New York. Don and Sandra, I hope that's in your sense. They may take the chance to represent themselves. With Bob Thomas, Director of Product Management, and Rob Solomon, Director of Type Engineering, and Shawn Flynn, Senior Software Engineer, on Bitstream's side and a colleague of mine as a font expert from the embedded side plus myself we had a nice group together and could cover a lot of items in little more than an hour on the management level as well as on the technical level. I introduced PWG and especially UPDF to them and told them my ideas about a font approach (we must start somewhere). 1.) I think we should take the IFIMETRICS structure from NT and check, whether this is the right superset for general font information. This includes Panose info. 2.) We have to add character set handling and 3.) character width information. I propose we will not tell about the scaling formula for calculating single char width explicitely in our XML file. I rather would expect that we assume the driver knows about certain font formats including their scaling formulas and we just reference that in a list. 4.) The relationship of system fonts to printer resident fonts with the complexity of font substitution unfortunately is another item in this area. I explained that I want us to investigate SVG and their font description more before we decide on a spec. Bitsteam generally agreed on all of that. They may even be interested to think about a tool to provide a XML file per font (only newer ones) shipped by Bitstream to be included easily into a complete UPDF. But that depends on how sophisticated and convincing our concept will be. That's probably something more for Sandra or Don. So I gave it a kick-off. The question for me now is: After coming back from other development today, will I spend the remaining days on constraints or prepare fonts further more. I am open to proposals. Norbert From sandra_matts at hp.com Tue Feb 1 15:19:04 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:05 2009 Subject: UPD> fonts Message-ID: That's a great start Norbert. Will these people be able to attend the New Orleans meeting or the next meeting in New York? Sandra -----Original Message----- From: Norbert Schade [mailto:nschade@xionics.com] Sent: Tuesday, February 01, 2000 11:48 AM To: UPD group Subject: UPD> fonts I would not call myself the absolute font expert, but I know this and that. I invited Bitstream on January, 13th, to Oak (formerly Xionics, most of you may have heard that the merge now is public and legal) to talk about the subject. They were interested in visiting the group. I told them about the next meetings of our group especially mentioning New York. Don and Sandra, I hope that's in your sense. They may take the chance to represent themselves. With Bob Thomas, Director of Product Management, and Rob Solomon, Director of Type Engineering, and Shawn Flynn, Senior Software Engineer, on Bitstream's side and a colleague of mine as a font expert from the embedded side plus myself we had a nice group together and could cover a lot of items in little more than an hour on the management level as well as on the technical level. I introduced PWG and especially UPDF to them and told them my ideas about a font approach (we must start somewhere). 1.) I think we should take the IFIMETRICS structure from NT and check, whether this is the right superset for general font information. This includes Panose info. 2.) We have to add character set handling and 3.) character width information. I propose we will not tell about the scaling formula for calculating single char width explicitely in our XML file. I rather would expect that we assume the driver knows about certain font formats including their scaling formulas and we just reference that in a list. 4.) The relationship of system fonts to printer resident fonts with the complexity of font substitution unfortunately is another item in this area. I explained that I want us to investigate SVG and their font description more before we decide on a spec. Bitsteam generally agreed on all of that. They may even be interested to think about a tool to provide a XML file per font (only newer ones) shipped by Bitstream to be included easily into a complete UPDF. But that depends on how sophisticated and convincing our concept will be. That's probably something more for Sandra or Don. So I gave it a kick-off. The question for me now is: After coming back from other development today, will I spend the remaining days on constraints or prepare fonts further more. I am open to proposals. Norbert From sandram at boi.hp.com Thu Feb 3 15:51:48 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:05 2009 Subject: UPD> Request for Constraint paper In-Reply-To: <000201bf6ce4$fd691990$c31343ce@gca-2.xionics.com> Message-ID: Norbert and others: I did not get the constraint paper that Norbert wrote up for the last meeting. Can someone please email it to me in an attachment. I want to copy it to the ftp site. thanks, Sandra Matts From nschade at xionics.com Fri Feb 4 12:04:48 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:05 2009 Subject: UPD> fonts Message-ID: <000801bf6f31$f21b0180$c31343ce@gca-2.xionics.com> We may reserve about two hours for some talk about fonts and I can accompany it with some notes. My problem is I don't know how much is common knowledge. We are all assumed to be printer experts somehow. So maybe everyone knows as much or even more than I do. But nonetheless I will be prepared for some items. So we can use this as a kind of an agenda to follow on. At the beginning of our font discussion I'd like a public and binding decision that every glyph will always and everywhere be identified as a Unicode in our spec. After that we may talk about resident fonts: 1. Common font description files for the host PFM, AFM, TFM 2. General font attributes I hope others will jump in here. We will talk about font description structures for drivers in different operating systems. I propose a description close to the IFIMETRICS we know from NT. Please send me and bring with you appropriate stuff for the Mac and Unix/Linux. 3. Character width tables One long list of pairs of Unicode and width values. I'd like to see values for bitmap fonts rather based on virtual units (7200 will work in many cases, but this could be set somewhere more in a global section of our spec) than on real resolution. I do not want to have two lists for one font in 300 and 600 dpi, not to talk about 1200. This will make the font description a bit more model independent and reusable. I hope to encourage font vendors by that to develop a tool for automatic creation of UPDF font description files for easy implementation into a UPDF file. That is exactly the kind of arguments companies like Bitstream are looking for. An interesting item may be to describe the width of some fonts used in Japan, which are mainly fixed pitch. Few glyphs are half width and few others, mainly the Latin section, are proportional. The danger is to create huge data files without really providing much information. Do we want it simple and large or small and effective, but with more work on the driver side? 4. Dynamic character selection Similar problem as above. Do we want fonts to be determined to one special character set used in the operating system? This may result in quite a large number of font descriptions just to support a typeface like Arial under different operating systems and different language versions (International, East European, Cyrillic, Japanese, etc.). We have to think about character set definitions and their effective use. And I want us to specify some common character sets in the DTD. Who can we use as a reference? The Unicode consortium? IEEE? A subitem here is when the font should be announced at all. Assuming a font description including Western and Eastern European characters would we expect to see the font showing up as Western AND Eastern, when the Eastern European option is not installed? That might be a nice battle. I have fought a lot already to make fonts 'dynamic'. 5. Font rotation Sometimes only some characters can be rotated. See Japanese market. Sometimes fonts can only rotated in 90 degree steps. The unit to describe angles in could be 3600. 6. Character composition table Maybe there is better name for it. But you want to be able to substitute some characters with accents by combining the basic character and the accent as another char. I want us to specify a common composition table in the DTD, which can be used as a base. 7. Kerning 8. Scaling formulas I do not want to translate C code into XML to specify the way the width of characters in a scalable Intellifont or other font format is done. So we need to decide which font formats and therefore scaling formulas we support. This can include an anticipation of how the driver is expected to calculate. I would not mind to show five lines of C code per scaling formula in the general explanation of the spec. 9. System fonts used to screen resident fonts To be honest: This is an area, where I get angry quickly. So keep me calm. Typical questions: How should the font be named? If there are four styles of a typeface will the font name of these four fonts have a suffix like 'Bold', 'Italic', 'BoldItalic' or so? We don't need to decide that and can leave it open. But I like to have a policy in cases like this, which then can build up some culture to avoid problems early. Do we say anything how characters should be handled, which may not be supported by standard system fonts? When system fonts will be shipped with the device can we assume they are installed? 10. Command sequences Generally I propose to select fonts by attribute and not by location. To describe the download of system fonts not represented by resident fonts is somehow different, but we could reuse some sections. Character sets and rotation are an issue here, too. Proposal: We concentrate on temporary download, not permanent. Otherwise we have to handle hard disk, Flash ROM and so on. I do not think we are on level to handle that already. Temporary will make it difficult enough. I do not want to describe each download method in detail, but create a reference list with exact target models, e.g. 'PCL 5 bitmap' references the PCL bitmap download understood by a HP LaserJet III. We may need to specify some values like 'maximum number of download fonts', 'download per page / per document', etc. Even with constraints (you remember I suggested not to use constraints for UI only) it might be impossible to describe something like 'do not use more than 30% of RAM for download, if less than 2MB are available'. So memory handling might be up to the driver. So the download section might be quite short. As I said I know this and that. This overview may give you enough reason to throw tomatoes and eggs. I know I left font substitution out. I think we will face huge data accumulation and compression automatically. Anything else I forgot? Norbert From sandram at boi.hp.com Fri Feb 4 16:11:19 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:05 2009 Subject: UPD> minutes Message-ID: Hi All, I've copied minutes and the latest DTD and companion files to www.pwg.org. I'm in the process of copying the constraint doc from Norbert and the Visio file that shows the current hierarchical layout of the DTD file. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com 208-396-4755 phone -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1580 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000204/28c62578/winmail-0001.bin From sandram at boi.hp.com Fri Feb 4 16:21:21 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:05 2009 Subject: UPD> Tokyo meeting Message-ID: Hi All, I recently found out that I will not be able to attend the Tokyo meeting. The location is not the problem but the actual date of the meeting. Unfortunately, I cannot leave Boise during March and April. I am looking for someone to voluteer to chair the meeting on Thursday in Tokyo. Please respond if you would be willing to lead the meeting for that one day. If no one can lead the meeting, I will have to cancel the UPDF meeting on Thursday. thank-you, Sandra Matts -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1668 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000204/599659ba/winmail-0001.bin From nschade at xionics.com Mon Feb 7 10:01:56 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: Fw: UPD> Tokyo meeting Message-ID: <001e01bf717c$47443900$c31343ce@gca-2.xionics.com> -----Original Message----- From: Norbert Schade To: Sandra Matts Date: Monday, February 07, 2000 10:01 AM Subject: Re: UPD> Tokyo meeting >Sandra, >my company is still thinking about the UPDF Tokoy meeting. >In case it will be cancelled at all, I strongly vote for two teleconferences >in April. >Additionally I'd like to select from one of two options in New York: >A. We will not stop our UPDF meeting right after lunch, but extend it to at >least 5pm. >B. We add a font day on Thursday, 2pm to 6pm, which would leave enough time >for travel in the morning for most of us. >By the way, I would accept both options the same time. Target of the New >York meeting then could be to finish discussions about fonts and >concentrating on writing it down in XML the weeks before San Francisco. >To accomplish that it would be necessary that several people take over some >tasks for fonts, especially in the OS specific area, contacting the Unicode >consortium or getting various one-byte character sets filled with Unicode in >their own company and other tasks, which will come up during our discussion >this Friday. If some people commit to that, I am ready to lead the font >section of the spec. >Norbert >-----Original Message----- >From: Sandra Matts >To: Universal Printer Driver >Date: Friday, February 04, 2000 5:13 PM >Subject: UPD> Tokyo meeting > > >>Hi All, >> I recently found out that I will not be able to attend >>the Tokyo meeting. The location is not the problem but >>the actual date of the meeting. Unfortunately, I cannot >>leave Boise during March and April. >> >> I am looking for someone to voluteer to chair >>the meeting on Thursday in Tokyo. Please respond >>if you would be willing to lead the meeting for that >>one day. >> >> If no one can lead the meeting, I will have >>to cancel the UPDF meeting on Thursday. >> >> >>thank-you, >>Sandra Matts >> > From don at lexmark.com Mon Feb 7 11:43:28 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> Tokyo UPDF Meeting Message-ID: <200002071827.NAA25594@interlock2.lexmark.com> I would be willing to lead the UPDF meeting in Tokyo _IF_ the agenda is done in advance. I can moderate and direct the discussion as necessary but others should be on the hook for the presentations and other material. ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From egglestn at lexmark.com Mon Feb 14 12:09:14 2000 From: egglestn at lexmark.com (egglestn@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> Testing.... Message-ID: <200002141710.MAA07264@interlock2.lexmark.com> Testing upgrades to pwg.org. Please do not respond. Roger From nschade at xionics.com Tue Feb 15 16:23:42 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> command sequences Message-ID: <000401bf77fa$ef8d2fc0$c31343ce@gca-2.xionics.com> The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert From nschade at xionics.com Mon Feb 14 15:32:57 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Unicode support Message-ID: <000701bf772a$ae135ea0$c31343ce@gca-2.xionics.com> It became apparent that we need a unique way of identifying characters when dealing with them in different operating systems with different configurations. The only option coming up was Unicode. It would be used in two areas: 1. Technical spec of fonts Especially the handling of character sets requires a neutral and consistent way to identify characters. 2. Dialogs Any Universal Printer Driver will have a dialog. Some other strings like font names will even be passed through to applications. It would be a huge problem to have different conditions for storing these strings based on different operating system character sets. While there seemed to be a wide consensus about the use of Unicode to accomplish that every company shall have the chance to discuss this internally and check current policies. It needs a little more investigation to find out about the appropriate encoding form. It will most probably be either UTF-8 or UTF-16. When searching in the Internet it looks as if UTF-8 is the current leader in industry standards. Saving the Unicode in the theoretic default value of four bytes is not an option. We'll wait til end of March 2000 for statements. After that there will be a time to vote on that. While chatting around I found a number of XML editors either available or under development, which support at least UTF-8. So this should not be a problem at all. Norbert From nschade at xionics.com Mon Feb 14 16:03:57 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> further input to font handling Message-ID: <000901bf772f$02afb0e0$c31343ce@gca-2.xionics.com> Having checked user defined character sets in PCL over the week-end I think this is a good direction to go. I explained why a UPD has to have the ability to define and download user defined character sets in PostScript (only one character set per font, only few predefined char sets). So we would add few sections to the driver development to extend this functionality to PCL. We can use Unicode in PCL character set definitions. This would make UPDF practically independent from character sets for device fonts. It saves time when creating the UPDF font section. It makes the font description significantly shorter. It may even be more efficient in performance. I realize that it can happen that we redefine a character set, which was already a perfect match as a predefined, in certain cases. The only challenge would be to add the necessary functionality for PCL. A future switch to direct Unicode support in the PDL would then be little more than a finger snip. I still believe that we need the character set functionality described last Friday for dynamic character selection additionally, as some fonts may come with only "almost" perfect match from the font vendor, as some PDL may not offer a dynamic user defined character set. But for PCL 5, PCL 6 and PostScript this will make our life easier - and of those, who will write the UPDF. Norbert From don at lexmark.com Thu Feb 17 10:20:49 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> command sequences Message-ID: <200002171521.KAA25429@interlock2.lexmark.com> It has been my assumption all along that we would have to include these command sequences. There's simply no way around it. Is it time to bite the bullet and start this process? ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/15/2000 04:23:42 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> command sequences The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert From don at lexmark.com Thu Feb 17 10:22:46 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> Unicode support Message-ID: <200002171545.KAA03138@interlock2.lexmark.com> I too believe UTF-8 is the way to go. ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/14/2000 03:32:57 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> Unicode support It became apparent that we need a unique way of identifying characters when dealing with them in different operating systems with different configurations. The only option coming up was Unicode. It would be used in two areas: 1. Technical spec of fonts Especially the handling of character sets requires a neutral and consistent way to identify characters. 2. Dialogs Any Universal Printer Driver will have a dialog. Some other strings like font names will even be passed through to applications. It would be a huge problem to have different conditions for storing these strings based on different operating system character sets. While there seemed to be a wide consensus about the use of Unicode to accomplish that every company shall have the chance to discuss this internally and check current policies. It needs a little more investigation to find out about the appropriate encoding form. It will most probably be either UTF-8 or UTF-16. When searching in the Internet it looks as if UTF-8 is the current leader in industry standards. Saving the Unicode in the theoretic default value of four bytes is not an option. We'll wait til end of March 2000 for statements. After that there will be a time to vote on that. While chatting around I found a number of XML editors either available or under development, which support at least UTF-8. So this should not be a problem at all. Norbert From cmanros at cp10.es.xerox.com Thu Feb 17 11:09:51 2000 From: cmanros at cp10.es.xerox.com (Manros, Carl-Uno B) Date: Wed May 6 14:05:06 2009 Subject: UPD> Unicode support Message-ID: <918C79AB552BD211A2BD00805F15CE8502A6043D@x-crt-es-ms1.cp10.es.xerox.com> All, I agree with Don, considering that UTF-8 is now mandated for all IETF standards that contain text, and hence has to supported in things like IPP. Carl-Uno > -----Original Message----- > From: don@lexmark.com [mailto:don@lexmark.com] > Sent: Thursday, February 17, 2000 7:23 AM > To: nschade@xionics.com > Cc: upd@pwg.org > Subject: Re: UPD> Unicode support > > > I too believe UTF-8 is the way to go. > > ********************************************** > * Don Wright don@lexmark.com * > * Director, Strategic & Technical Alliances * > * Lexmark International * > * 740 New Circle Rd * > * Lexington, Ky 40550 * > * 606-232-4808 (phone) 606-232-6740 (fax) * > ********************************************** > > > > nschade%xionics.com@interlock.lexmark.com on 02/14/2000 03:32:57 PM > > To: upd%pwg.org@interlock.lexmark.com > cc: (bcc: Don Wright/Lex/Lexmark) > Subject: UPD> Unicode support > > > > It became apparent that we need a unique way of identifying > characters when > dealing with them in different operating systems with different > configurations. > The only option coming up was Unicode. It would be used in two areas: > 1. Technical spec of fonts > Especially the handling of character sets requires a neutral > and consistent > way to identify characters. > 2. Dialogs > Any Universal Printer Driver will have a dialog. Some other > strings like > font names will even be passed through to applications. > It would be a huge problem to have different conditions for > storing these > strings based on different operating system character sets. > > While there seemed to be a wide consensus about the use of Unicode to > accomplish that every company shall have the chance to discuss this > internally and check current policies. > It needs a little more investigation to find out about the appropriate > encoding form. It will most probably be either UTF-8 or UTF-16. When > searching in the Internet it looks as if UTF-8 is the current > leader in > industry standards. Saving the Unicode in the theoretic > default value of > four bytes is not an option. > We'll wait til end of March 2000 for statements. After that > there will be a > time to vote on that. > > While chatting around I found a number of XML editors either > available or > under development, which support at least UTF-8. So this > should not be a > problem at all. > Norbert > > > > > From sandram at boi.hp.com Wed Feb 16 14:50:02 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:06 2009 Subject: UPD> command sequences In-Reply-To: <000401bf77fa$ef8d2fc0$c31343ce@gca-2.xionics.com> Message-ID: For fonts I believe we can specify font sequences for PCL 5 and PCL 6 and it will work. However, for graphics commands using Raster and HP-GL/2, I think it will be a bit hard. I will have to do some prototyping (later) to see if it will work. For Fonts I think it is probably our only choice because of our tendencies to add proprietary escapes. Encoding escape sequences in XML may be hard. We can reference a binary file of escape sequences (Binary ENTITY) or we can use the pre-defined ISO-Latin-1 Character set. Using the latter would mean a driver has to decode Esc* (1B2Ah) to the binary equivalent 1B2A in hex and send that to the printer. Using a binary entity the driver would pull the entry from the file and send it to the printer with no decoding. I would lean towards the former so that the driver would not have to have as much intelligence. Also it may be difficult to enhance binary definitions if we require the driver to know their meaning. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com 208-396-4755 phone Boise, ID 83714 -----Original Message----- From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert Schade Sent: Tuesday, February 15, 2000 2:24 PM To: UPD group Subject: UPD> command sequences The more I think about it, the more I am convinced that we need command sequences in the UPDF file. It is simply an illusion that a driver uses a certain HP model as a reference. I really think every clone and every port of a PDL to a specific model has its proprietary conditions and even improvements, which are not 100% compatible with the target HP model. >From my time in Germany, where we developed drivers for many different companies, I know that a lot of proprietary command sequences have been invented in the past and that there are tons of proprietary paper source, paper size, print media, typeface, symbol set and other parameters. Only very few models would work with a UPD, that anticipates the correctness of a print file. Beside the difficulties to describe binary print files - are there other reasons to not specify command sequences in a UPDF? Like marketing or policy reasons? In case we solve the problems to describe that technically, has any company any other problem? Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2920 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000216/a50de91d/winmail-0001.bin From sandra_matts at hp.com Thu Feb 17 15:29:33 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: FW: UPD> command sequences Message-ID: I sent this yesterday and it didn't make it. > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 12:50 PM > To: Universal Printer Driver > Subject: RE: UPD> command sequences > > For fonts I believe we can specify font sequences > for PCL 5 and PCL 6 and it will work. However, > for graphics commands using Raster and HP-GL/2, > I think it will be a bit hard. I will > have to do some prototyping (later) to see if it will > work. > > For Fonts I think it is probably our only choice > because of our tendencies to add proprietary > escapes. > > Encoding escape sequences in XML may be hard. We can > reference a binary file of escape sequences (Binary > ENTITY) or we can use the pre-defined ISO-Latin-1 > Character set. Using the latter would mean a driver > has to decode Esc* (1B2Ah) to the binary equivalent > 1B2A in hex and send that to the printer. Using > a binary entity the driver would pull the entry > from the file and send it to the printer with > no decoding. > > I would lean towards the former so that > the driver would not have to have as much intelligence. > Also it may be difficult to enhance binary definitions > if we require the driver to know their meaning. > > Sandra Matts > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Tuesday, February 15, 2000 2:24 PM > To: UPD group > Subject: UPD> command sequences > > > The more I think about it, the more I am convinced that we need command > sequences in the UPDF file. > It is simply an illusion that a driver uses a certain HP model as a > reference. I really think every clone and every port of a PDL to a > specific > model has its proprietary conditions and even improvements, which are not > 100% compatible with the target HP model. > >From my time in Germany, where we developed drivers for many different > companies, I know that a lot of proprietary command sequences have been > invented in the past and that there are tons of proprietary paper source, > paper size, print media, typeface, symbol set and other parameters. > Only very few models would work with a UPD, that anticipates the > correctness > of a print file. > > Beside the difficulties to describe binary print files - are there other > reasons to not specify command sequences in a UPDF? > Like marketing or policy reasons? > In case we solve the problems to describe that technically, has any > company > any other problem? > Norbert From sandra_matts at hp.com Thu Feb 17 15:32:24 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: FW: UPD> command sequences Message-ID: > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Thursday, February 17, 2000 1:19 PM > To: sandra_matts@am.exch.hp.com > Subject: FW: UPD> command sequences > > > > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 12:50 PM > To: Universal Printer Driver > Subject: RE: UPD> command sequences > > For fonts I believe we can specify font sequences > for PCL 5 and PCL 6 and it will work. However, > for graphics commands using Raster and HP-GL/2, > I think it will be a bit hard. I will > have to do some prototyping (later) to see if it will > work. > > For Fonts I think it is probably our only choice > because of our tendencies to add proprietary > escapes. > > Encoding escape sequences in XML may be hard. We can > reference a binary file of escape sequences (Binary > ENTITY) or we can use the pre-defined ISO-Latin-1 > Character set. Using the latter would mean a driver > has to decode Esc* (1B2Ah) to the binary equivalent > 1B2A in hex and send that to the printer. Using > a binary entity the driver would pull the entry > from the file and send it to the printer with > no decoding. > > I would lean towards the former so that > the driver would not have to have as much intelligence. > Also it may be difficult to enhance binary definitions > if we require the driver to know their meaning. > > Sandra Matts > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Tuesday, February 15, 2000 2:24 PM > To: UPD group > Subject: UPD> command sequences > > > The more I think about it, the more I am convinced that we need command > sequences in the UPDF file. > It is simply an illusion that a driver uses a certain HP model as a > reference. I really think every clone and every port of a PDL to a > specific > model has its proprietary conditions and even improvements, which are not > 100% compatible with the target HP model. > >From my time in Germany, where we developed drivers for many different > companies, I know that a lot of proprietary command sequences have been > invented in the past and that there are tons of proprietary paper source, > paper size, print media, typeface, symbol set and other parameters. > Only very few models would work with a UPD, that anticipates the > correctness > of a print file. > > Beside the difficulties to describe binary print files - are there other > reasons to not specify command sequences in a UPDF? > Like marketing or policy reasons? > In case we solve the problems to describe that technically, has any > company > any other problem? > Norbert From sandram at boi.hp.com Wed Feb 16 16:01:46 2000 From: sandram at boi.hp.com (Sandra Matts) Date: Wed May 6 14:05:06 2009 Subject: UPD> further input to font handling In-Reply-To: <000901bf772f$02afb0e0$c31343ce@gca-2.xionics.com> Message-ID: user defined character sets are limited to 256 characters. It can be typical for Asian docs to contain 1000-2000 unique characters. Therefore the driver has to maintain a list of font descriptor numbers and when it downloads a character, it has to search for it in the list of font descriptors. It is not a major problem. There are drivers today that manage this. I just want to make sure that people realize there some work involved in the driver to make it work. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com 208-396-4755 phone Boise, ID 83714 -----Original Message----- From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert Schade Sent: Monday, February 14, 2000 2:04 PM To: UPD group Subject: UPD> further input to font handling Having checked user defined character sets in PCL over the week-end I think this is a good direction to go. I explained why a UPD has to have the ability to define and download user defined character sets in PostScript (only one character set per font, only few predefined char sets). So we would add few sections to the driver development to extend this functionality to PCL. We can use Unicode in PCL character set definitions. This would make UPDF practically independent from character sets for device fonts. It saves time when creating the UPDF font section. It makes the font description significantly shorter. It may even be more efficient in performance. I realize that it can happen that we redefine a character set, which was already a perfect match as a predefined, in certain cases. The only challenge would be to add the necessary functionality for PCL. A future switch to direct Unicode support in the PDL would then be little more than a finger snip. I still believe that we need the character set functionality described last Friday for dynamic character selection additionally, as some fonts may come with only "almost" perfect match from the font vendor, as some PDL may not offer a dynamic user defined character set. But for PCL 5, PCL 6 and PostScript this will make our life easier - and of those, who will write the UPDF. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2824 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000216/8d7c96c2/winmail-0001.bin From sandra_matts at hp.com Thu Feb 17 15:33:06 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: FW: UPD> further input to font handling Message-ID: > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Thursday, February 17, 2000 1:19 PM > To: sandra_matts@am.exch.hp.com > Subject: FW: UPD> further input to font handling > > > > -----Original Message----- > From: Sandra Matts [mailto:sandram@boi.hp.com] > Sent: Wednesday, February 16, 2000 2:02 PM > To: UPD group > Subject: RE: UPD> further input to font handling > > user defined character sets are limited to 256 characters. It can > be typical for Asian docs to contain 1000-2000 unique > characters. Therefore the driver has to maintain a list of font > descriptor numbers and when it downloads a character, it has > to search for it in the list of font descriptors. It is not a major > problem. There are drivers today that manage this. I just > want to make sure that people realize there some work > involved in the driver to make it work. > > Sandra Matts > > > Sandra Matts > Engineer Scientist > Hewlett-Packard > sandram@boi.hp.com > 208-396-4755 phone > Boise, ID 83714 > > > -----Original Message----- > From: owner-upd@pwg.org [mailto:owner-upd@pwg.org]On Behalf Of Norbert > Schade > Sent: Monday, February 14, 2000 2:04 PM > To: UPD group > Subject: UPD> further input to font handling > > > Having checked user defined character sets in PCL over the week-end I > think > this is a good direction to go. > I explained why a UPD has to have the ability to define and download user > defined character sets in PostScript (only one character set per font, > only > few predefined char sets). So we would add few sections to the driver > development to extend this functionality to PCL. We can use Unicode in PCL > character set definitions. > This would make UPDF practically independent from character sets for > device > fonts. It saves time when creating the UPDF font section. It makes the > font > description significantly shorter. It may even be more efficient in > performance. > I realize that it can happen that we redefine a character set, which was > already a perfect match as a predefined, in certain cases. > The only challenge would be to add the necessary functionality for PCL. > A future switch to direct Unicode support in the PDL would then be little > more than a finger snip. > > I still believe that we need the character set functionality described > last > Friday for dynamic character selection additionally, as some fonts may > come > with only "almost" perfect match from the font vendor, as some PDL may not > offer a dynamic user defined character set. > > But for PCL 5, PCL 6 and PostScript this will make our life easier - and > of > those, who will write the UPDF. > > Norbert From nschade at xionics.com Fri Feb 18 10:03:20 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> command sequences Message-ID: <002b01bf7a21$4bbab560$c31343ce@gca-2.xionics.com> I think we are on a good way here. I second the idea not to specify vector language. This is typically identical in all PDL implementations. We may come up with a list of functionality and command sequences, which we expect the driver to know and activate depending on a certain target model. I need a little bit more time to start that. Items in the list can be: Vector language, bitmap download, outline download, etc. Raster graphic to be checked. The list of command sequences to be supported in UPDF includes: job language (to be checked with IPP), session and page settings (paper handling, etc.), font selection and others. This list should be specified in our spec. That is exactly the kind of policy I talk about from time to time to provide some orientation for driver developers. I see problems in reading fixed binary commands from a binary file. I'd like us to provide more flexibility here. We have a good chance to step ahead GPD here. We need to support formulas. The simpliest example is a command sequence for the height of scalable fonts. You will not list every point size. So you want to specify the height as a flexible parameter. I could imagine we can make it better than something like '%D', where the driver has to know that 'D' in the height command is the height. There are more complex sequences with several parameters and working with methods like '%D' would be kind of restrictive by only being able to work with the predefined values. To give an odd example: If a special printer model would expect the width instead of the height as the parameter in our above sample, you would not have any chance to specify it, as the driver is assuming without any doubt that '%D' is the height in the print file. That's why I call a method like '%D' working with predefined parameters, while something like '%Height' (or similar syntax, to be discussed) would provide what I call speaking variables / meaningful variable names (help me with my bad English). It is very useful to even be able to do some simple calculations. Let's say it would be necessary to do something in 1200dpi (current device resolution), although the application is sending in a value in 600dpi (current graphic resolution). To stay with '%Height' sample this could then be '%Height*2'. The main issue to care for is the variable length of the name/formula. But then you can feed the driver with nearly any kind of command sequence description. I'd like that to be on the agenda for the next conference I'll be joining (Tokyo or New York). The item should be called 'parameter converter'. Generally I think very much that we are heading the right direction with command sequences in the meantime. Norbert From don at lexmark.com Fri Feb 18 13:07:31 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> command sequences Message-ID: <200002181808.NAA17860@interlock2.lexmark.com> On the subject of Vector Language.... I don't think we should assume that every printer uses the same language or that all printers use a language from some predefined set. We must consider the case where a printer has a unique and proprietary language. How would the UPD know about it? How should the UPDF tell the driver about it? Is this a separate XML file or one that is included by the UPDF? ********************************************** * Don Wright don@lexmark.com * * Director, Strategic & Technical Alliances * * Lexmark International * * 740 New Circle Rd * * Lexington, Ky 40550 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** nschade%xionics.com@interlock.lexmark.com on 02/18/2000 10:03:20 AM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> command sequences I think we are on a good way here. I second the idea not to specify vector language. This is typically identical in all PDL implementations. We may come up with a list of functionality and command sequences, which we expect the driver to know and activate depending on a certain target model. I need a little bit more time to start that. Items in the list can be: Vector language, bitmap download, outline download, etc. Raster graphic to be checked. The list of command sequences to be supported in UPDF includes: job language (to be checked with IPP), session and page settings (paper handling, etc.), font selection and others. This list should be specified in our spec. That is exactly the kind of policy I talk about from time to time to provide some orientation for driver developers. I see problems in reading fixed binary commands from a binary file. I'd like us to provide more flexibility here. We have a good chance to step ahead GPD here. We need to support formulas. The simpliest example is a command sequence for the height of scalable fonts. You will not list every point size. So you want to specify the height as a flexible parameter. I could imagine we can make it better than something like '%D', where the driver has to know that 'D' in the height command is the height. There are more complex sequences with several parameters and working with methods like '%D' would be kind of restrictive by only being able to work with the predefined values. To give an odd example: If a special printer model would expect the width instead of the height as the parameter in our above sample, you would not have any chance to specify it, as the driver is assuming without any doubt that '%D' is the height in the print file. That's why I call a method like '%D' working with predefined parameters, while something like '%Height' (or similar syntax, to be discussed) would provide what I call speaking variables / meaningful variable names (help me with my bad English). It is very useful to even be able to do some simple calculations. Let's say it would be necessary to do something in 1200dpi (current device resolution), although the application is sending in a value in 600dpi (current graphic resolution). To stay with '%Height' sample this could then be '%Height*2'. The main issue to care for is the variable length of the name/formula. But then you can feed the driver with nearly any kind of command sequence description. I'd like that to be on the agenda for the next conference I'll be joining (Tokyo or New York). The item should be called 'parameter converter'. Generally I think very much that we are heading the right direction with command sequences in the meantime. Norbert From nschade at xionics.com Thu Mar 9 15:32:55 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> How many UPD? Message-ID: <000901bf8a06$a6b54e40$c31343ce@gca-2.xionics.com> I do expect the number of drivers per operating system to fall significantly. But I do not expect that there will be one master driver per operating system, which will be able to read and use all UPDF in the world. So the question I'd like to raise is: Do we expect any UPD to understand any UPDF? Can a UPD reject certain UPDF's though the syntax is correct? The background of the question is deeper than it looks like the first second. Do we want the world to use the UPDF format to describe printers, while accepting that different companies may write different UPD's for that purpose? I consider it as a good direction to push the format first. I know a number of PDL's outside PostScript and PCL, which possibly can be described by a well architectured UPDF. But I would not expect that companies, who push these PDL's, will write a driver with a big PostScript and PCL section additionally. On the other side I do not expect that the first UPD's, e.g. if one would be written by HP, will be able to support every variant in the POS (point on sale) or other special markets. So I suggest that there will be fields in the UPDF, which allows a driver to check, whether it is really able to work with a certain UPDF (some info about the PDL to decide the UPD can support the appropriate vector language etc.). These fields must be supervised to avoid nonsense. I do not think that Oak would need these fields in the near future, but I feel it's somehow following an open concept and can help the format in its worldwide acceptance. I would like to see this item discussed in Tokyo and New York. Even if we disagree, it will be better to talk about it. Norbert From nschade at xionics.com Fri Mar 10 16:05:21 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Font handling DTD Message-ID: <000901bf8ad4$82adeec0$c31343ce@gca-2.xionics.com> All, in New Orleans I said I will continue working on fonts. This is the result so far. The structure of element types is pretty much complete except FontDownload. I do not expect to change the DeviceFonts section by myself a lot. So I'll see what feedback will come in. The next step will be to define the attributes. As you can see they are all empty yet. Further steps will be some documentation to show that IFIMETRICS structures can be created by this structure. I really would like to hear from the Apple guy I met several times at the meetings, if this is providing all info he needs. We will have some discussion whether it is possible or useful to support device fonts on a Unix machine at all. I am tending not to announce them at all there, as I do not yet see how the system will screen them without installing the corresponding screen fonts together with the driver. For those of you, who do not have a DTD editor like XML authority I added a GIF file, which you could insert into a WinWord document that you can watch the overview instead of single lines in a simple text editor. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling.dtd Type: text/dtd Size: 4621 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000310/523a3bd9/fonthandling-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: diagram.gif Type: image/gif Size: 48090 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000310/523a3bd9/diagram-0001.gif From nschade at xionics.com Mon Mar 13 14:23:32 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> resident fonts in UPDF Message-ID: <000301bf8d21$9efa3c60$c31343ce@gca-2.xionics.com> After further investigation of different concepts I think that UnitsPerEm and DesignUnits are identical. I will remove DesignUnits in the next version. From motoyama at blackhole.str.ricoh.com Wed Mar 15 10:42:13 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:05:06 2009 Subject: UPD> Font Message-ID: <200003151542.HAA23238@blackhole.str.ricoh.com> I am new to this list. However, I noticed that Font is discussed and encoded into SGML (XML). ISO 9541 is a font standard in which SGML encoding is given. Will this standard help? T. Motoyama From motoyama at blackhole.str.ricoh.com Wed Mar 15 10:43:40 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:05:06 2009 Subject: UPD> Font Message-ID: <200003151543.HAA23244@blackhole.str.ricoh.com> I am new to this list. However, I noticed that Font is discussed and encoded into SGML (XML). ISO 9541 is a font standard in which SGML encoding is given. Will this standard help? T. Motoyama From nschade at xionics.com Wed Mar 15 11:01:10 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Font Message-ID: <001201bf8e97$aec64ae0$c31343ce@gca-2.xionics.com> I busy today, but I definitely will have a look tomorrow. Motoyama-san, you have an Internet site? Norbert -----Original Message----- From: T. Motoyama +1-408-954-5445 To: upd@pwg.org Date: Wednesday, March 15, 2000 10:46 AM Subject: UPD> Font > >I am new to this list. However, I noticed that Font is discussed and >encoded into SGML (XML). ISO 9541 is a font standard in which SGML >encoding is given. Will this standard help? > >T. Motoyama > From motoyama at blackhole.str.ricoh.com Wed Mar 15 11:12:37 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:05:06 2009 Subject: UPD> ISO 9541 Message-ID: <200003151612.IAA23330@blackhole.str.ricoh.com> Norbert: Anything to do with ISO is hard. I think you have to get the standard from ANSI (www.ansi.org). It is three volumes standard and will cost you good $$$. However, they contains detailed attributes for multi-national fonts. This standard will save a lot of time to handle the international characters. T. Motoyama From sandra_matts at hp.com Wed Mar 15 16:02:05 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> New York mtg Message-ID: Don has asked me to send out a notice concerning the UPDF meeting in New York. Due to scheduling conflicts he wants the meeting to take place on Friday - our usual day. We had discussed having it on Tuesday of that week. Hopefully people have not made travel plans yet since it is a couple of months yet. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandram@boi.hp.com (208) 396-4755 phone From sandra_matts at hp.com Thu Mar 16 10:49:04 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> Tokyo meeting Message-ID: If anyone is planning on attending the Tokyo for the UPDF meeting and has agenda items, please send them to Don Wright. Currently we are still working on the Font encoding in XML and that will be the main agenda item in New York in May. thank-you, Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From nschade at xionics.com Mon Mar 27 11:24:54 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> ISO 9541 Message-ID: <001301bf9808$fbd9d2a0$c31343ce@gca-2.xionics.com> I had a chance to have a short look at it. This spec consists of three parts: general architecture, ways to code it (Interchange format) and Glyph shape representation. I don't think we care about part 3 too much. Part 2 tells about ASN and SGML coding and minimum font resources and should be easy to understand. Part 1 is the main description of the architecture and the structures and parameters. This would be the main reference. I have some comments and questions: 1. I want to find out how much this spec is a living spec. Where is it used? I would not called it exactly Windows conform, although that shouldn't be our only view. Perhaps some people from operating systems and/or font development have some more info. Motoyama-san, what do you know about that? Are you working with it regularly? Can somebody provide a DTD and an XML file based on that DTD? 2. the spec is from the early nineties. A bigger part of the architecture is handling font classification, which nowadays is realized by Panose in many environments. I favor Panose. 3. Unicode is not mentioned in the sections I have seen. 4. I do not find anything about character sets in the spec, neither of operating systems nor of devices. 5. The spec seems to be stronger concerning alignments of international characters. 6. Parameters looks somehow familiar, although I haven't studied in detail yet. I have to study more, but my conclusion up to now is: We will not fulfill the spec 100%, as today's requirements are not all covered. So we will not be compatible. The question is whether we want to lean towards it. What advantages would that have? What extra effort (at least reading and thinking about it and then comparing in detail, what we can take over)? We may want to decide that in the very near future. But we need more info and a broader base for the decision. Norbert From motoyama at blackhole.str.ricoh.com Mon Mar 27 11:57:22 2000 From: motoyama at blackhole.str.ricoh.com (T. Motoyama +1-408-954-5445) Date: Wed May 6 14:05:06 2009 Subject: UPD> ISO 9541 Message-ID: <200003271657.IAA00627@blackhole.str.ricoh.com> The specification is published and under 5 year review cycle. However, the glyph registration may be handled by Unicode group. I am not sure the status of glyph registration. Mike Ksar of HP was involved to use the font registration to publish 10646. I just suggested to take a look at the specification and to use the usable part. If you think ISO 9541 is too old or not practical, I suggest not to use it. The character sets were different issues. The specification only handled glyphs and how to may them to code was never addressed. The collection of glyphs was internation including oriental launguages such as Chinese and Korean. I think Alabic was included too. Tetsuro From nschade at xionics.com Mon Mar 27 16:30:31 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> True Type fonts Message-ID: <000301bf9833$ae085940$c31343ce@gca-2.xionics.com> As it came up today: 1. Shall we just use the True Type format to describe the device fonts by eliminating the glyph descriptions and everything else we don't need? I think the answer in this case is no, as it is a binary format. 2. Shall we convert the remainder of the True Type format to XML? would we have all the info we are looking for? How much data would that be per font? I do not know. I'm not an expert in writing TT fonts. Perhaps someone else can provide more feedback. Norbert From nschade at xionics.com Tue Mar 28 16:55:19 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> character sets in device fonts Message-ID: <000d01bf9900$4f30a120$c31343ce@gca-2.xionics.com> You may want to find out about the reasons why I designed the character set handling the way I introduced it almost three weeks ago. See some explanations in the following section. Character selection in device fonts The target format of this spec concerning device fonts ? in case they survive in the longterm run ? is based on Unicode handling. That means a character would be identified by its Unicode. Character sets would become redundant. As long as this is not reality, we need character sets. I keeping away more and more from thinking in terms of 1-byte and 2-byte character sets. I?ve learnt that a set is a more or less arbitrary collection of characters. But the fact is that character sets are needed to identify characters in a font. DeviceCharacterSets I want to realize some rules when defining ways to identify characters in the device: 1. I do not see any reason to specify all predefined character sets of a PDL with all characters. The ideal solution would be to specify each character exactly once, whatever the used character set for that character is. 2. As the ideal solution could have a serious impact on the print file size and especially on the performance and as PDL?s nowadays have a number of character sets, which are at least close to operating system character sets, I consider it useful to specify some character sets used in the PDL with all characters. Those character sets will be the ones used as primary and secondary sets in the CharacterSetIdentification. This avoids unnecessary switching and the next character will most likely be found more quickly. This could result in a device font with several Windows character sets plus some sets with only few characters, which are really new ones compared to the primary/secondary sets. This would allow to list all characters without an overwhelming amount of data. Targets of this priority is to list all characters while allowing some redundancy for performance advantages. 3. If operating system character sets are not available in the numbers needed and if user defined character sets are supported that could be the alternative. We can discuss whether this should be the top priority. This approach offers the easiest switch from character sets to real Unicode handling in the device. Then there would not be any DeviceCharacterSets section. It is to be investigated, whether these DeviceCharacterSets should be specified outside the individual font specification, as many if not most of them will appear in many fonts. The font specific section would then only list, which character sets are available, not the ranges. It should be a target to avoid redundancy where possible. But in this case we would loose the independency of each font specification. Ranges I think ranges are at least an alternative to matrix definitions. The problem with matrix definitions always is to handle 1-byte (16x16 matrix) and multibyte character sets. To list each character with its Unicode and the corresponding binary output would create long lists in many cases, while not each pair of data is not really providing new information. A range from U+0020 to U+007E for example could just show the binary output for the first Unicode. The binary values for all following characters in that range can easily be calculated. This is a kind of compression therefore. CharacterSetIdentification After having defined all necessary DeviceCharacterSets we can think about how to tell, which operating system character sets the font can fulfill. So for any OS char set there might be a device char set with the perfect match. This one would be listed as primary and that?s it. In case it?s just the best one available and very good, but not perfect, it would still be listed as primary, but one or more other could be added as secondary sets. I assume that the search for a character would always start in the character where the driver found the last character, then in the primary and then in the secondary sets. This should provide a good performance with a maximum of flexibility. CharacterSubstitutionTables can provide further help in the search process. To be investigated, whether characters, which are not listed in either the primary or the secondary sets, can be used for that OS char set at all. I hope I made it clear enough that this structure would support one Arial font for all OS char sets and not one per OS char set like realized in most of today's drivers. Norbert From don at lexmark.com Wed Mar 29 23:31:40 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> Tokyo meeting Message-ID: <200003300434.XAA17628@interlock2.lexmark.com> I've seen nor heard any interest from the US side in participating in a conference call during the UPDF meeting in Tokyo. That meeting will start on Thursday at 9AM Tokyo time or Wednesday evening at 8PM eastern time (I believe). Unless I hear from some people very very very soon (today 3/30), there will be no conference call. If there are more than 1 that respond, I need someone on the US side to set up a dial in number. ********************************************** * 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 * * 606-232-4808 (phone) 606-232-6740 (fax) * ********************************************** From sandra_matts at hp.com Mon Apr 17 11:28:43 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> UPDF Chair Message-ID: Hi All, This May will be the two year mark of my job chairing the UPDF portion of the PWG. There have been alot of changes during the two years at HP and I am now part of a different organization. My new management has decided that I must give up the chairperson. It takes up quite a bit of my time just to prepare for the meetings. Also travel to the meetings and then attending the meetings takes up almost a full week. New York will be my last meeting as chair. I will still be able to participate but only as a regular member. I put it out to the group to see if another person wants to take over the chair. Please resond with thoughts, ideas. Sandra Matts Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From sandra_matts at hp.com Mon May 8 16:38:47 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> agenda for UPDF meeting Message-ID: Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From sandra_matts at hp.com Mon May 8 16:56:10 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> Font Message-ID: Sorry this is so late. I'm catching up on old email. I looked at ISO 9541 and it appears to be a Type 1 PostScript font format. I want to look at it for ideas but I want to make sure that our font.dtd is PDL independent. Sandra -----Original Message----- From: Norbert Schade [mailto:nschade@xionics.com] Sent: Wednesday, March 15, 2000 9:01 AM To: T. Motoyama +1-408-954-5445 Cc: UPD group Subject: Re: UPD> Font I busy today, but I definitely will have a look tomorrow. Motoyama-san, you have an Internet site? Norbert -----Original Message----- From: T. Motoyama +1-408-954-5445 To: upd@pwg.org Date: Wednesday, March 15, 2000 10:46 AM Subject: UPD> Font > >I am new to this list. However, I noticed that Font is discussed and >encoded into SGML (XML). ISO 9541 is a font standard in which SGML >encoding is given. Will this standard help? > >T. Motoyama > From lfarrell at cissc.canon.com Mon May 8 17:14:53 2000 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:05:06 2009 Subject: UPD> agenda for UPDF meeting Message-ID: <6C940F5153E5D211937A0090274E8D8B11E8A9@cissc002.cisoc.canon.com> Sandra, Since you have announced that this will be your last meeting as Chair, we should probably include an agenda item to address the future of the group [leadership]. lee ====================================== Lee Farrell Canon Information Systems 110 Innovation Drive Irvine, CA 92612 ph: (949) 856-7163 fax: (949) 856-7510 lfarrell@cis.canon.com ====================================== -----Original Message----- From: MATTS,SANDRA (HP-Boise,ex1) [mailto:sandra_matts@hp.com] Sent: Monday, May 08, 2000 1:39 PM To: Universal Printer Driver (E-mail) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From nschade at xionics.com Tue May 9 15:12:22 2000 From: nschade at xionics.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> UPDF future Message-ID: <006001bfb9ea$85b85840$c31343ce@gca-2.xionics.com> I thought about it a while after HP's statement to step back from the chair. For better readability I add the original WinWord file, which is the same text. UPDF marketing and development directions as considered by Norbert Schade, Oak Imaging Group How much do companies want to be involved? ? Actions ? Always be on top of the information level ? New development ? Competion ? Provide Christmas wish list ? Provide problem list ? Become an expert for discussions ? PDLs ? Operating systems ? Driver delevopment concepts (PPD, GPD, etc.) ? Specification issues (XML, stylesheets, etc.) ? Contribute to specification ? Provide feedback ? Companies ? Hewlett-Packard ? Canon ? Oak Technologies ? others Development of a Universal Printer Data Format ? Develop sections of the spec ? Commit to it in a list attached with a schedule ? Provide section-wise explanations in the spec about the way a driver is supposed to use the data. ? Provide section-wise explanations in the spec why the data is specified as it is. ? Feedback ? Regular representatives of meetings ? Experts at home ? Subscribers (publish and set schedules) ? Other companies contacted by the group (like font companies some months ago) ? Compare with existing standards regularly Results of a UPDF development other than the format itself ? Develop a Universal Font Description Format as a 100 percent subsection of UPDF ? Prove problem awareness ? Prove solution expertise ? Isolate and discuss common driver development problem areas ? Be a contact to operating system developers ? Provide a list of useful and required extensions to existing develoment systems (e.g. spooler requirements like job respool or page order). ? Recommend certain driver conceptional approaches ? Be a contact to application developers ? Recommend certain handling of driver features (e.g. duplex) A UPDF spec will be written at least three times ? As a draft ? After the expert check ? During driver development Conclusion: The UPDF group has to decide about its future. If Hewlett-Packard is no more interested in playing a major role (completely independent from the person Sandra Matts) concerning the spec and a driver, this would be a serious political indication. If not more people become active developers of the spec and generally support the group, we have to ask ourselves about productivity and determination. This includes the establishment of experts in the group and in the background of the group. We need at least a full day (eight hours) meeting time. A smaller requirement is that we need a XML consultant. Finally I think the chair is a more personal decision. First we have to care for some productive conditions of the group. I hope we can see some more signs of devotion to the job by more people. Otherwise credibility will become a problem. Sincerely Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF marketing and development directions.doc Type: application/msword Size: 22528 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000509/d5e5d7f7/UPDFmarketinganddevelopmentdirections-0001.doc From don at lexmark.com Wed May 10 15:17:13 2000 From: don at lexmark.com (don@lexmark.com) Date: Wed May 6 14:05:06 2009 Subject: UPD> agenda for UPDF meeting Message-ID: <200005101924.PAA09739@interlock2.lexmark.com> While I don't have XML for it, I think adding the PDL strings should be a high priority item on the list. This is core to the concept of a UPD... it has to be able to know how to do all the basic things for text, images, positioning, etc. ********************************************** * 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) * * (Former area code until 10/1 was 606) * ********************************************** sandra_matts%hp.com@interlock.lexmark.com on 05/08/2000 04:38:47 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From hastings at cp10.es.xerox.com Wed May 10 19:58:45 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:06 2009 Subject: UPD> agenda for UPDF meeting [PDL strings] Message-ID: <918C79AB552BD211A2BD00805F15CE85031F4A40@x-crt-es-ms1.cp10.es.xerox.com> I agree with Don about adding the PDL strings to the UPDF agenda. I'd also like to make sure that there is sufficient distinctions in the UPDF specification for specifying where the PDL strings go in the payload, so that the UPDF can indicate the placement of the PDL data as being up front or as it occurs on the page, etc. We have looked at the similar PPD mechanism for positioning IPP Job Template attributes, like "media", "copies", and "finishings" in the payload up front and it is almost, but not quite, sufficient for generating conforming 'application/ipp' MIME Media type data. It would be good if a UPDF file could have sufficient flexibility to be able to produce an application/ipp payload for a Print-Job request including the IPP operation attributes and the IPP Job Template attributes in front of the PDL data in the payload. Thanks, Tom -----Original Message----- From: don@lexmark.com [mailto:don@lexmark.com] Sent: Wednesday, May 10, 2000 12:17 To: sandra_matts@hp.com Cc: upd@pwg.org Subject: Re: UPD> agenda for UPDF meeting While I don't have XML for it, I think adding the PDL strings should be a high priority item on the list. This is core to the concept of a UPD... it has to be able to know how to do all the basic things for text, images, positioning, etc. ********************************************** * 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) * * (Former area code until 10/1 was 606) * ********************************************** sandra_matts%hp.com@interlock.lexmark.com on 05/08/2000 04:38:47 PM To: upd%pwg.org@interlock.lexmark.com cc: (bcc: Don Wright/Lex/Lexmark) Subject: UPD> agenda for UPDF meeting Hi, I am soliciting agenda items for the New York meeting. I know at the last meeting we wanted to continue discussing fonts. Are there any specific font items? Is there anything else that people want to talk about. There were a few threads about adding the PDL strings to the UPDF file. If someone has some XML for that - let me know. Sandra Sandra Matts Engineer Scientist Hewlett-Packard sandra_matts@hp.com (208) 396-4755 phone From norbertschade at oaktech.com Mon May 22 11:53:26 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> documents from NY meeting Message-ID: <000d01bfc405$de47ef00$c31343ce@gca-2.xionics.com> Hi, find the documents I brought as printed versions attached. The DTD files are available as GIF, too, to make it easier to import them into WinWord for printing. I'm going to work on the font handling DTD the next days, including a draft spec for it. I will establish a small font expert group. Up to now major members will be in alphabetical order AGFA (Dale Hubbard), Bitstream (Shawn Flynn), IBM (Mark VanderWiele) and Oak (Norbert Schade). The people mentioned in brackets may be the developers or can also work as coordinators to other more technical experts. This will result in an e-mail group and probably some teleconferences over the next months. If anyone wants to be added to that list, please tell me. I require feedback from other PWG companies from time to time. The first soliciting may be around June, 12. Please be prepared that your font experts can spend some time investigating, whether the current spec will hold all info needed for any kind of driver development. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling 1.dtd Type: text/dtd Size: 5621 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/fonthandling1-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Font handling.gif Type: image/gif Size: 26856 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/Fonthandling-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: paper handling.dtd Type: text/dtd Size: 3994 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/paperhandling-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Paper handling.gif Type: image/gif Size: 16337 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/Paperhandling-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: task schedule 2000.xls Type: application/vnd.ms-excel Size: 14336 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/taskschedule2000-0001.xls -------------- next part -------------- A non-text attachment was scrubbed... Name: TT IFI Comparison.doc Type: application/msword Size: 29184 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/TTIFIComparison-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF marketing and development directions.doc Type: application/msword Size: 23040 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/UPDFmarketinganddevelopmentdirections-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF meeting New York.doc Type: application/msword Size: 24576 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000522/b4ab986e/UPDFmeetingNewYork-0001.doc From norbertschade at oaktech.com Fri May 26 12:39:20 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> new e-mail address Message-ID: <000501bfc730$f14a4fc0$c31343ce@gca-2.xionics.com> my new e-mail address is norbertschade@oaktech.com. please make necessary adjustments. the old address will work a while. Norbert From sandra_matts at hp.com Fri May 26 13:39:23 2000 From: sandra_matts at hp.com (MATTS,SANDRA (HP-Boise,ex1)) Date: Wed May 6 14:05:06 2009 Subject: UPD> new e-mail address Message-ID: I also have a new email. Please send email to sandra_matts@hp.com thanks, Sandra Matts -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Friday, May 26, 2000 10:39 AM To: UPD group Subject: UPD> new e-mail address my new e-mail address is norbertschade@oaktech.com. please make necessary adjustments. the old address will work a while. Norbert From hastings at cp10.es.xerox.com Mon Jun 19 21:05:29 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:06 2009 Subject: UPD> Jim Flowers' email address (editor of ISO 9541 font standard) Message-ID: <918C79AB552BD211A2BD00805F15CE8503496A1C@x-crt-es-ms1.cp10.es.xerox.com> Jim Flowers offered to answer questions about the ISO 9541 font standard of which he was once the editor. His email address is: flowers@aligninc.com Tom -----Original Message----- From: Jim Flowers [mailto:flowers@aligninc.com] Sent: Thursday, June 01, 2000 07:26 To: Rick Landau; Hastings, Tom N Cc: Jim Flowers Subject: Re: Do you know Jim Flowers email address? Yes this email address still works. How are you guys doing? I'm still consulting through my company Align, about to hire on some people to more effectively work on large B2B web sites. I focus on server-side Java these days, although I just finished up a font server-related project for Sun's SunPCi product. Tom, I haven't done anything remotely *font* in many years, particularly related to the ISO font standard. Part 3 (I think) of the standard when shapes are defined IS Type 1 specific, although it probably allows other formats--this part happened after I was booted by the working group chair. I'd be happy to answer any direct questions that you have, but I'm not in a position to work on standardization any more. -Jim > ----- Original Message ----- > From: Hastings, Tom N > To: Rick Landau > Cc: Hastings, Tom > Sent: Tuesday, 2000/05/30 14:16 > Subject: Do you know Jim Flowers email address? > > > > Rick, > > > > > > > > The Printer Working Group (PWG) has a Universal Printer Driver Format > (UPDF) > > project which has just started to consider an XML encoded font metrics > > module. I got them to look at ISO 9541 that Jim authored. But the > chairman > > (from HP) thinks that it is Type 1 PostScript format. Probably because it > > doesn't have all of the wierdness of HP fonts. I would be extremely > > surprised if the ISO standard was for Postscript type1 fonts. > > > > > > > > I wanted to see if Jim was interested in helping the group. There are a > > number of font venders from the Boston area (Bit Stream and Agfa) that are > > joining in. > > > > > > > > Thanks, > > > > Tom > > > > -----Original Message----- > > > > From: MATTS,SANDRA (HP-Boise,ex1) [mailto:sandra_matts@hp.com] > > > > Sent: Monday, May 08, 2000 13:56 > > > > To: Universal Printer Driver (E-mail) > > > > Subject: RE: UPD> Font > > > > > > > > Sorry this is so late. I'm catching up on old email. > > > > I looked at ISO 9541 and it appears to be a Type 1 PostScript > > > > font format. I want to look at it for ideas but I want > > > > to make sure that our font.dtd is PDL independent. > > > > Sandra > > > > -----Original Message----- > > > > From: Norbert Schade [mailto:nschade@xionics.com] > > > > Sent: Wednesday, March 15, 2000 9:01 AM > > > > To: T. Motoyama +1-408-954-5445 > > > > Cc: UPD group > > > > Subject: Re: UPD> Font > > > > > > > > I busy today, but I definitely will have a look tomorrow. > > > > Motoyama-san, you have an Internet site? > > > > Norbert > > > > -----Original Message----- > > > > From: T. Motoyama +1-408-954-5445 > > > > To: upd@pwg.org > > > > Date: Wednesday, March 15, 2000 10:46 AM > > > > Subject: UPD> Font > > > > > > > > > > > > > >I am new to this list. However, I noticed that Font is discussed and > > > > >encoded into SGML (XML). ISO 9541 is a font standard in which SGML > > > > >encoding is given. Will this standard help? > > > > > > > > > >T. Motoyama > > > > > > > > From norbertschade at oaktech.com Fri Jul 7 16:57:11 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Universal Device Font Description Message-ID: <000901bfe855$ec6269c0$510714ac@nschade-w2.xionics.com> All, find attached some files. This is the output of the small group working on a Universal Device Font Description Format. It is pretty complete already except for the download. This will be the base for Monday's UPDF meeting. I will have some printed versions with me. See you there. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: Font handling.gif Type: image/gif Size: 32268 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/Fonthandling-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: font handling.dtd Type: text/dtd Size: 7765 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/fonthandling-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Universal Device Font Description Format.doc Type: application/msword Size: 99840 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/UniversalDeviceFontDescriptionFormat-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Parameter Converter.doc Type: application/msword Size: 26112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000707/282f35c5/ParameterConverter-0001.doc From hastings at cp10.es.xerox.com Sat Jul 8 15:39:28 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:06 2009 Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts Message-ID: <918C79AB552BD211A2BD00805F15CE8503753B75@x-crt-es-ms1.cp10.es.xerox.com> This note is an idea for possible collaboration of the UPDF and IPP work. Attached is the first draft of an IPP extension for a Resource object and operations to get the attributes and/or opaque data. The Get-Resources operation includes a filter mechanism that uses the attributes defined for the Resource. Here is the Abstract: This IPP Get Resource document specifies an extension to IPP/1.0 [RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document extends the current closed IPP object model with a passive polymorphic object that is intended to satisfy most needs for new object types in the long-term evolution of IPP via an extensible object framework. This document defines: Resource object (passive polymorphic object); Resource get operations (e.g., Get-Resource-Attributes); Resource attributes (e.g., "resource-name"); new Printer attributes (e.g., "resource-type-supported"); Resource type of Driver (a morph of the Resource object); methods for supporting 'driver download' to IPP Client systems. The Resource object has a number of REQUIRED and OPTIONAL attributes that are independent of the resource type. We envision that one such resource type would be 'font'. Each resource type would also define additional attributes that are specific to that resource type. One of the Resource attributes is resource-document-formats (1setOf mimeMediaType) which indicates which document-formats each Resource instance is defined for, e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client could filter on the "resource-document-format" attribute to list, say, only the PostScript fonts. The resource data for a Resource object instance is envisioned being a collection of files, packaged as a single file, using, say, zip. Thus font metrics and font data could be separately represented. The IPP WG needs review by the UPDF WG to see if the basic mechanism is a good foundation for fonts and would meet your requirements for defining the 'font' resource type. For example, the attributes for different types of fonts needs to be different (we understand that the attributes for PostScript fonts and PCL fonts have something in common, but a lot that is different). Questions for the UPDF WG: 1. Is the basic framework sufficient for fonts? 2. Would you like to define the attributes for a 'font' resource-type? 3. For which document-formats? 4. What about other resources, such as device constraints? <> -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF and IPP - resource object.doc Type: application/msword Size: 105984 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000708/de527498/UPDFandIPP-resourceobject-0001.doc From hastings at cp10.es.xerox.com Sun Jul 9 13:31:58 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:06 2009 Subject: UPD> More on UPDF and IPP Collaboration Message-ID: <918C79AB552BD211A2BD00805F15CE8503753B79@x-crt-es-ms1.cp10.es.xerox.com> I wasn't very clear in my previous note about UPDF and IPP Collaboration. 1. Firstly, there are lots more areas for collaboration that just fonts. It should be possible for a driver that interprets a UPDF file to generate an 'application/ipp' MIME type payload for a Print-Job request that conforms to IPP/1.1. Also a UPDF file for IPP/1.0. See (1) and and (2) RFCs 2566 and 2565, respectively. 2. For fonts, the area of collaboration is to have a semantic description of the font attributes, such as the ones that describe the font and the ones that describe the font metrics. This semantic description would have several parts: a. Attributes that are common to all fonts b. Attributes that apply to a particular document format, such as Postscript or PCL 3. Then these semantic description documents would have separate encoding documents: a. IPP encoding for use in the Get-Resource-Attributes, Get-Resource-Data, and Get-Resources operation requests and responses. b. XML encoding for use by font vendors when publishing their fonts and for use in a UPDF file for use by Printer vendors when publish their UPDF Printer Description files. Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Saturday, July 08, 2000 12:39 To: upd Subject: UPD> UPDF and IPP Collaboration - Resource object for fonts This note is an idea for possible collaboration of the UPDF and IPP work. Attached is the first draft of an IPP extension for a Resource object and operations to get the attributes and/or opaque data. The Get-Resources operation includes a filter mechanism that uses the attributes defined for the Resource. Here is the Abstract: This IPP Get Resource document specifies an extension to IPP/1.0 [RFC-2565] [RFC-2566] and IPP/1.1 [IPP-MOD] [IPP-PRO]. This document extends the current closed IPP object model with a passive polymorphic object that is intended to satisfy most needs for new object types in the long-term evolution of IPP via an extensible object framework. This document defines: Resource object (passive polymorphic object); Resource get operations (e.g., Get-Resource-Attributes); Resource attributes (e.g., "resource-name"); new Printer attributes (e.g., "resource-type-supported"); Resource type of Driver (a morph of the Resource object); methods for supporting 'driver download' to IPP Client systems. The Resource object has a number of REQUIRED and OPTIONAL attributes that are independent of the resource type. We envision that one such resource type would be 'font'. Each resource type would also define additional attributes that are specific to that resource type. One of the Resource attributes is resource-document-formats (1setOf mimeMediaType) which indicates which document-formats each Resource instance is defined for, e.g., 'application/postscript', 'application/vnd.hp-PCL', etc. So a client could filter on the "resource-document-format" attribute to list, say, only the PostScript fonts. The resource data for a Resource object instance is envisioned being a collection of files, packaged as a single file, using, say, zip. Thus font metrics and font data could be separately represented. The IPP WG needs review by the UPDF WG to see if the basic mechanism is a good foundation for fonts and would meet your requirements for defining the 'font' resource type. For example, the attributes for different types of fonts needs to be different (we understand that the attributes for PostScript fonts and PCL fonts have something in common, but a lot that is different). Questions for the UPDF WG: 1. Is the basic framework sufficient for fonts? 2. Would you like to define the attributes for a 'font' resource-type? 3. For which document-formats? 4. What about other resources, such as device constraints? <> From norbertschade at oaktech.com Thu Jul 27 11:26:37 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Unicode tables Message-ID: <002401bff7df$0e4abd10$510714ac@nschade-w2.xionics.com> who can provide reliable Unicode based character set tables for the OSCharacterSets section of the Universal Device Font Description Format? I'm in direct contact with Apple. I may get something directly from them. I'm looking for MS Windows and Unix/Linux based tables. Although our format will only refer to these tables with the CharacterSetID field, we need a clear reference that there is no doubt about the character identifiers. I think about either listing them in the specification document, which will make it huge, or refer to that info somewhere. Feedback appreciated. I'm trying to contact the Unicode Consortium. This is a path I'm running parallel. But I made bad experience with them in the past. Norbert From david.roach at unisys.com Thu Jul 27 11:50:40 2000 From: david.roach at unisys.com (Roach, David L.) Date: Wed May 6 14:05:06 2009 Subject: UPD> Unicode tables (Resend) Message-ID: <31DAD5F069E5D31189A20060973CE25504EB82@US-PL-EXCH-2> See the official Unicode Online Data site, at "http://www.unicode.org/unicode/onlinedat/online.html". This page includes links to various cross-mapping table, including most (if not all) the MS Windows character sets. Dave Roach > -----Original Message----- > From: "Norbert Schade" @UNISYS > Sent: Thursday, July 27, 2000 11:27 AM > To: "UPD group" ; "Dale Hubbard" > ; "Shawn M. Flynn" ; > "Norbert Schade" ; "Mark VanderWiele" > > Subject: UPD> Unicode tables > > <<...>> > who can provide reliable Unicode based character set tables for the > OSCharacterSets section of the Universal Device Font Description Format? > I'm in direct contact with Apple. I may get something directly from them. > I'm looking for MS Windows and Unix/Linux based tables. > Although our format will only refer to these tables with the > CharacterSetID > field, we need a clear reference that there is no doubt about the > character > identifiers. > I think about either listing them in the specification document, which > will > make it huge, or refer to that info somewhere. Feedback appreciated. > I'm trying to contact the Unicode Consortium. This is a path I'm running > parallel. But I made bad experience with them in the past. > Norbert > From norbertschade at oaktech.com Tue Aug 22 10:48:46 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> company move Message-ID: <003101c00c48$12f923b0$510714ac@nschade-w2.xionics.com> Oak Technology, Imaging Group, has moved from Burlington to Woburn. Although the old and the new building are only in a distance of about 10 miles, some things have changed: Oak Technology, Inc. Imaging Group Attn.: Norbert Schade 10 Presidential Way Woburn, MA 01801-1041 Phones Reception: 781-638-7500 Direct: 781-638-7614 Fax: 781-638-7555 email: norbertschade@oaktech.com Oak web site: www.oaktech.com Attention!!! Due to the strike of the telephone company Verizon (previously Bell Atlantic) there are serious delays in the installations of the new phone system. We only provide an emergency system these days. It will be very tough to reach me on the phone and the direct call is not yet working at all. We expect improvements the next days and hope to break water end of next week. In case you want to talk to me, please use email. Regards Norbert Schade From norbertschade at oaktech.com Tue Sep 5 17:29:35 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> Chicago agenda Message-ID: <001601c01780$63a53cc0$510714ac@nschade-w2.xionics.com> The UPDF day is Monday, Sept 11. The conference will start at 8.30am and last to about 5.30pm. We will agree on a lunch break. I hope I'll be in the conference room in time, as I arrive shortly before 8am at the airport following the schedule. The Boston conference (UPDF day around October 26) is considered a bigger event for the UPDF group, as some things, which needed serious preparation, grow together. To aim at that major event we will have three sessions in Chicago: 1. Constraints The discussion was started some time ago, but not finished. I will send some material later today or tomorrow morning to enable everybody to study it ahead. We will have DTD files as well as XML files. Statements to decide: 1.1. Conditions for constraints can be combined with AND and/or OR. By nesting conditions recursively the number of levels and the complexity possible is practically indefinite. This allows a very flat architecture concerning the features of a printer model, as all dependencies and interdependencies will be handled as constraints. 1.2. Constraints will support the default action Filter. Should it support messages? See proposals. 1.3. Constraints can also be used to handle conditional selections. Select is considered an additional action. 1.4. Constraints are mainly known as an instrument to avoid conflicts in the user interface of the driver's dialog. The current proposal is supposed to be able to set conditions on almost any combination of fields. Those constraints can also be used when composing print files. We will take samples from paper handling, as that is known as an area full of constraints. 2. Overall architecture The discussion about constraints will automatically lead to a more global conversation about the overall architecture. In case constraints work perfectly we may be able to flatten out the architecture a bit. 2.1. Installable Options We will see that constraints have serious impact on the handling of installable options. 2.2. General extensibility How easy should it be to add an installable option or new locale without touching the original files? This will be a discussion about a file structure. 2.3. Although a Universal Printer Data Description is considered platform independent it should provide all information the operating system is expecting. What operating systems are exactly to be considered? 2.4. Linux How much can the UPDF group help the Linux guys to implement an application and a printing interface? Do we want to be involved? Do they want to be involved? 3. Font handling 3.1. Open questions about the font handling concept so far. 3.2. We want to prepare at least one sample implementation of a device resident font. This sample font(s) should be demonstrated in Boston. We want to get information about how easy it will be to create the information automatically, how big such a standard font may be in XML and how this information can be used best during install and runtime. Regards Norbert Schade From norbertschade at oaktech.com Tue Sep 5 18:09:23 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: Fw: UPD> Chicago agenda Message-ID: <001b01c01785$f2cd3d80$510714ac@nschade-w2.xionics.com> Please add mapping lists to item 2.3. to be able to convert the incoming values of communication protocols like IPP to operating system specific flags. -----Original Message----- From: Norbert Schade To: UPD group Date: Tuesday, September 05, 2000 5:32 PM Subject: UPD> Chicago agenda >The UPDF day is Monday, Sept 11. >The conference will start at 8.30am and last to about 5.30pm. >We will agree on a lunch break. >I hope I'll be in the conference room in time, as I arrive shortly before >8am at the airport following the schedule. > >The Boston conference (UPDF day around October 26) is considered a bigger >event for the UPDF group, as some things, which needed serious preparation, >grow together. >To aim at that major event we will have three sessions in Chicago: > >1. Constraints >The discussion was started some time ago, but not finished. >I will send some material later today or tomorrow morning to enable >everybody to study it ahead. >We will have DTD files as well as XML files. > >Statements to decide: >1.1. Conditions for constraints can be combined with AND and/or OR. >By nesting conditions recursively the number of levels and the complexity >possible is practically indefinite. >This allows a very flat architecture concerning the features of a printer >model, as all dependencies and interdependencies will be handled as >constraints. >1.2. Constraints will support the default action Filter. >Should it support messages? See proposals. >1.3. Constraints can also be used to handle conditional selections. >Select is considered an additional action. >1.4. Constraints are mainly known as an instrument to avoid conflicts in the >user interface of the driver's dialog. >The current proposal is supposed to be able to set conditions on almost any >combination of fields. Those constraints can also be used when composing >print files. > >We will take samples from paper handling, as that is known as an area full >of constraints. > >2. Overall architecture >The discussion about constraints will automatically lead to a more global >conversation about the overall architecture. >In case constraints work perfectly we may be able to flatten out the >architecture a bit. >2.1. Installable Options >We will see that constraints have serious impact on the handling of >installable options. >2.2. General extensibility >How easy should it be to add an installable option or new locale without >touching the original files? >This will be a discussion about a file structure. >2.3. Although a Universal Printer Data Description is considered platform >independent it should provide all information the operating system is >expecting. >What operating systems are exactly to be considered? >2.4. Linux >How much can the UPDF group help the Linux guys to implement an application >and a printing interface? Do we want to be involved? Do they want to be >involved? > >3. Font handling >3.1. Open questions about the font handling concept so far. >3.2. We want to prepare at least one sample implementation of a device >resident font. >This sample font(s) should be demonstrated in Boston. >We want to get information about how easy it will be to create the >information automatically, how big such a standard font may be in XML and >how this information can be used best during install and runtime. > >Regards >Norbert Schade > > From norbertschade at oaktech.com Tue Sep 5 18:59:19 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> constraints Message-ID: <003301c0178c$ed071ae0$510714ac@nschade-w2.xionics.com> Attached files show two approaches for constraints: The one with the suffix 'Small' is leaning towards today's well known constraint architecture with the exception of nested conditions. The implementations basically show the following constraint: if ( (MediaSize != Letter) && (MediaSize != A4) ) if ( (InputTray == Tray2) || (InputTray == Tray3) ) if (Duplex != Simplex) Filter(MediaSize); We will talk about some 'well-conformed constraints' and give recommendations on how to build proper constraints. Figure that the model supports Letter, A4, A5 and A6 as media sizes. The upper sample should not start with if ( (MediaSize == A5) || (MediaSize == A6) ) which is allowed by the syntax. You do not want to exclude the bad ones by listing them, but by listing the good ones and exclude ALL others. That will help in case an installable option input bin 'Optional Tray 8' has no chance to add media sizes to tray 2 or 3 when concentrating on creating constraints for the installable option only. I consider this a very important detail and we should spend some time on it to fully understand it. The differences in the XML files just show variaties of implementation. There is always a top condition! In the sample it is a set of conditions on MediaSize. This makes them kind of unidirectional. The same condition cannot be read for the case that duplex is not simplex and some constraints get active in that case. Nested conditions reflect AND combinations of conditions. Sets can be grouped on the same level and nested. On the same level they represent an OR. Only Sets can be ORed. In case somebody wants to OR conditions this requires separate constraints. This ensures some readability. Otherwise the temptation is too big to combine more or less everything into one tremendous constraint. I downloaded a Windows 9x printer driver for the HP LaserJet 8000 PCL 5e from HP's site. I'd like you to do the same. You may want to check some constraints on the paper tab starting with the default setting. 1. Select A5, select Tray 2. -> OK message with greying the paper source and selecting Tray 1. This involves messages and selections in the proposal. 2. Select Tray 2, select A5. -> OK/Cancel message. Cancel resets the media size, OK activates the new media size selection and changes everything else if necessary. Neither in sample 1 nor in 2 filtering is involved as an action. Minimum familiarity with XML Authority (or similar application) and XML Pro (or similar application) is assumed. All Full sample XML are based on the Constraints_FullFeatured.DTD. The Small sample XML is based on the Constraints_Small.DTD. The Full1 sample XML is exactly mirroring the Small sample, just based on the Full DTD. In this case I only had to add the Filter action, which is redundant in the Small DTD, as filtering is the only supported action. You see that any developer can concentrate on filtering only even with the Full DTD, as the message and select branches are optional. The samples are fully featured, although re-editing will be necessary once the concept is fully blown up. -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full1.xml Type: text/xml Size: 777 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full1-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full2.xml Type: text/xml Size: 945 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full2-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Full3.xml Type: text/xml Size: 1125 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Full3-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_FullFeatured.dtd Type: text/dtd Size: 4198 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_FullFeatured-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_FullFeatured.gif Type: image/gif Size: 3139 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_FullFeatured-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.dtd Type: text/dtd Size: 1346 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.gif Type: image/gif Size: 1831 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints_Small.xml Type: text/xml Size: 739 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000905/6df430ba/Constraints_Small-0001.xml From norbertschade at oaktech.com Wed Sep 6 12:45:58 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> constraints spec Message-ID: <000901c01821$ef5227a0$510714ac@nschade-w2.xionics.com> Find attached the constraints specification document for developers. Please have it ready at the conference next Monday. We will talk about it. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000906/15054083/constraints-0001.doc From lfarrell at cissc.canon.com Tue Sep 26 14:12:45 2000 From: lfarrell at cissc.canon.com (Farrell, Lee) Date: Wed May 6 14:05:06 2009 Subject: UPD> UPDF Meeting Minutes -- Sep '00 Message-ID: <6C940F5153E5D211937A0090274E8D8B11EAE5@cissc.cisoc.canon.com> Norbert Schade requested me to post his Minutes. They are now available at: ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.doc ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.pdf ftp://ftp.pwg.org/pub/pwg/upd/minutes/2000/updf-000911.txt lee ====================================== Lee Farrell Canon Information Systems 110 Innovation Drive Irvine, CA 92612 ph: (949) 856-7163 fax: (949) 856-7510 lfarrell@cis.canon.com ====================================== From norbertschade at oaktech.com Thu Sep 28 11:55:57 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> preliminary UPDF agenda for Boston Message-ID: <02b301c02964$974083f0$510714ac@nschade-w2.xionics.com> Preliminary agenda for the UPDF meeting in Boston on Friday, Sep 27th 2000. After having finished the printer resident fonts (mainly in San Fransciso) and even constraints (mainly in Chicago) it is time to come back to the bigger picture again with a hopefully larger group to discuss satisfaction with the current level of the spec, open requirements and scenarios of implementation. 1. So I will most likely start with a wrap-up of the current overall level of the spec. 2. The main item of the day will be paper handling with the current spec on constraints in mind. I will send this spec out within the next one or two days and I would very much appreciate that all attendees have a clear understanding of it at the meeting, as the constraints are one of the strong columns this concept is based on. It is only quite a small section. So the study will not be very time consuming. I will prepare more samples to easy understanding. I expect you to ask me questions concerning the constraints spec via email, if there are any. We will review the paper handling section the next weeks to prepare the meeting. I will share the status with the whole UPDF group. 3. Event handlers If there is time to prepare it more in detail and time in the meeting, Event handlers will be another item. Event handlers are considered another strong column of the concept. They are designed to describe the assembly of a print file. There will be a number of global events like JobStart, JobEnd, PageStart, PageEnd plus some specific events, where it might be important to define the exact order of commands to be sent (I could imagine that font download is a sample for such a section). The UPDF developer is supposed to be able to create something like an ordered list. Each element of the list can be selected out of all fields of any feature, which have to do with printer commands. Each Event handler will have a section for PreConditions, Actions and PostConditions. The idea is to be able to tell that certain settings are to be ensured before the event, then do the defined actions (work on the ordered list) and eventually knowing what settings have been changed by sending all these commands, if this is important. I would appreciate some feedback before the conference to get a feeling, how important you consider a flexible code-independent description of the print file structure. If this is considered a minor target, we can drop it. But expect me to fight for it. 4. Predefined variable names The Parameter Converter is already specified on the current level as the first of the three strong columns (a forth one may be added). To specify printer command sequences you need some predefined variable names, which you will use in your formulas. The driver will set them to certain values and it will basically be the input parameters of the function. Example: You need a parameter COPIES to specify any useful formula for copy handling. We have to define a list of those variable names, which any driver/client has to know about. 5. Overall architecture We have to make some decisions on file naming, file structure and other things. We also will review the overall UPDF structure in this session to check for consistency and wholes. Concerning the overall driver/client architecture I still see UPDF taking over where IPP stops. Although UPDF is not exclusively designed to work with IPP, it is leaning heavily towards it to ensure the best possible cooperation between these two concepts. So we like to get some more input from the IPP group, where they see requirements. We consider Boston a major event for the UPDF group and think the spec has grown to a certain level, which provides a much better base for a sophisticated validation than at the beginning of the year. This will and shall affect the way the spec will go heavily. It would be nice to get a head count, who from the group of UPDF attendees in Boston will be available on Thursday and/or Friday night AFTER work. Simple email will do. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000928/eb88f34c/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Sep 28 13:38:43 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:06 2009 Subject: UPD> conference in Boston Message-ID: <001101c02972$f2b36eb0$510714ac@nschade-w2.xionics.com> Of course, the UPDF meeting is on Friday, Oct 27th 2000, not September. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20000928/223e563c/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Oct 4 16:40:55 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> new version of constraints spec Message-ID: <000a01c02e43$65216db0$510714ac@nschade-w2.xionics.com> We have finished a new level of the constraints specification. All comments from Chicago are implemented. As paper handling is the area where constraints are mostly used, we are partly working on paper handling as well. Therefore the attached samples are taken from paper handling. I am updating the constraints specification documentation right now and will share it with you shortly. Please take a few minutes to study it. It is small enough. The samples hopefully fill it with life. One open question is how can we provide hooks for proprietary constraints. For now I leave that aside. I will watch how much this is a requirement. Perhaps the concept is flexible enough for all necessary implementations. I copy the IPP group, as constraints have been an issue there for quite a while. Please check whether this proposal can solve your problems. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: application/octet-stream Size: 1871 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/Constraints-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 5187 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/Constraints-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: application/octet-stream Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/constraints-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: application/octet-stream Size: 1404 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/constraints2-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/6920c647/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Oct 4 17:47:45 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> UPDF architecture Message-ID: <00b801c02e52$de50b100$510714ac@nschade-w2.xionics.com> We have started a session in Chicago to specify more details for the final file architecture. We have to consider two areas: DTD files XML files based on those DTD files Concerning DTD files I fought a long time with myself. After having got some expertise in XML and when looking at the whole picture, I am convinced that forcing ourselves to one DTD file has too many disadvantages. I'd like to make two proposals: 1. Locales We will base locales on a separate DTD. Find the DTD, which is a very simple one, plus the specification documentation and two samples. You may look at the sample constraints files (especially constraints2.xml), which will make it more realistic. The documentation tells about the advantages such a solution has, expecially when we think about translating that stuff. There is one decision to make. Do we want the master XML file to know which locales are available? Shall it be possible to add another locale even after the driver is installed on a platform? If yes, the master XML file must be edited when a new locale is added to the system. If no, we need to specify a mechanism to detect locale XML files for a certain master XML file like adding some identification keys. 2. Installable options We have to face a similar question when it comes to installable options. We have dodged the issue long enough. I think that each physical unit (the master unit = the model, optional input units, optional output units, etc) should be represented by a separate XML file. As a unit may include very different features (input trays, duplex unit, RAM - who knows about the future). When trying to base the installable option XML files on the same DTD as the master, we have to make most if not all features optional. Do we want that? 3. Include files While we will have either one logical DTD file or (depending how we answer item 2) one master and one for installable options, we may want to work with different physical files including them to the master. I noticed that this method can save tons of time during development. It is quite simple to isolate an included DTD section and test it with a special XML file only based on that section without having to write or even to look at a complete XML file based on the whole picture. Sample: I sent the new version of the constraints section out today as a separate DTD. It can continue being a separate file when included by the master. Same with fonts, etc. Generally we have to develop a file naming system. I want to prepare this whole issue as much as possible before the Boston conference to just concentrate finding out the final weaknesses and then be able to make some decisions there. This proved to be a very good method the last conferences. We can make it an open discussion on the Internet or you can contact me directly. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: locale english.xml Type: application/octet-stream Size: 744 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/localeenglish-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: locale german.xml Type: application/octet-stream Size: 761 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/localegerman-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: locale.gif Type: image/gif Size: 1415 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/locale-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: locales.doc Type: application/msword Size: 27136 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/locales-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: application/octet-stream Size: 474 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/UPDFLocale-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001004/a0bb3a51/NorbertSchade-0001.vcf From norbertschade at oaktech.com Thu Oct 5 13:29:19 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> constraints update Message-ID: <000901c02ef1$cd27af60$510714ac@nschade-w2.xionics.com> Please find attached the promised specification documentation. In the meantime I am getting really picky about names of variables, as I've learnt that it is very important to have clean and different names for every element in XML. I've added the previous files, too, as I have updated some variable names. No other changes. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/Constraints-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: text/xml Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: text/xml Size: 1410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/constraints2-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 6967 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001005/08b2a9f8/Constraints-0001.gif From hastings at cp10.es.xerox.com Mon Oct 9 03:21:25 2000 From: hastings at cp10.es.xerox.com (Hastings, Tom N) Date: Wed May 6 14:05:07 2009 Subject: FW: UPD> constraints update Message-ID: <918C79AB552BD211A2BD00805F15CE8503FB68CA@x-crt-es-ms1.cp10.es.xerox.com> I'm forwarding this constraints spec to the IPP FAX DL, so that they can consider it at their Boston meeting, Thursday, 10/26 (the day before the UPDF meeting in Boston). The IPP FAX WG and the UPDF WG group should see if there is a way to converge the constraints specification to a common one. The IPP FAX primarily needs constraints for generating TIFF/FX and for interaction between IPP Job Template attributes. The UPDF group needs constraints for generating any PDL data. Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Thursday, October 05, 2000 10:29 To: UPD group Subject: UPD> constraints update Please find attached the promised specification documentation. In the meantime I am getting really picky about names of variables, as I've learnt that it is very important to have clean and different names for every element in XML. I've added the previous files, too, as I have updated some variable names. No other changes. Norbert Here is the previous message with more about the constraints proposal from the UPDF group. Tom -----Original Message----- From: Norbert Schade [mailto:norbertschade@oaktech.com] Sent: Wednesday, October 04, 2000 13:41 To: UPD group Cc: IPP Group Subject: IPP> new version of constraints spec We have finished a new level of the constraints specification. All comments from Chicago are implemented. As paper handling is the area where constraints are mostly used, we are partly working on paper handling as well. Therefore the attached samples are taken from paper handling. I am updating the constraints specification documentation right now and will share it with you shortly. Please take a few minutes to study it. It is small enough. The samples hopefully fill it with life. One open question is how can we provide hooks for proprietary constraints. For now I leave that aside. I will watch how much this is a requirement. Perhaps the concept is flexible enough for all necessary implementations. I copy the IPP group, as constraints have been an issue there for quite a while. Please check whether this proposal can solve your problems. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.doc Type: application/msword Size: 28672 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints-0001.doc -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/Constraints-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints.xml Type: text/xml Size: 444 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: constraints2.xml Type: text/xml Size: 1410 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/constraints2-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: Constraints.gif Type: image/gif Size: 6967 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/c33221b0/Constraints-0001.gif From norbertschade at oaktech.com Mon Oct 9 15:31:51 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> the big picture Message-ID: <002201c03227$94f0db60$510714ac@nschade-w2.xionics.com> We want to save the current version of the UPDF DTD. So I copied it to updf1.dtd indicating that this was the first level of that UPDF DTD. We have to do that on the UPDF site, too. I am editing the updf.dtd to bring the new pieces together. The attached version is still unchanged just to get you familiar with it. We are going to work in section DeviceCap.Features, PrinterCap, Features. I am removing the layer "Global". All features will live on the same level directly assigned to Features. The features PaperMedia, PaperHandling, FINISHINGS will be handled in "UPDF PrintMediaHandling.DTD", which is the former "Paper Handling.DTD". This DTD will be included in the master DTD. Dimension for print media handling will be centimeter/10000 all over the place. This is definitely small enough to work for rounding. It is resolution independent. It is the unit used in NT systems (this reason has lowest priority). We are removing as much of the locale specific stuff out of the technical DTD as possible. That forces us to think about defaults in detail. I have moved it to the "UPDF Locale.DTD", where it belongs. See attached DTD. The question is the best implementation there. As before the main goal is to simplify creating or deleting locales as much as possible. With a defaults section in the locale DTD a file copy will provide all creation of new tags. The current updf.dtd still has locale settings all over the place, which needs editing at many different places when we want to add a new locale. If there are problems so far, speak now. Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: updf.dtd Type: text/dtd Size: 31461 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/118168e0/updf-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Locale.dtd Type: text/dtd Size: 864 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001009/118168e0/UPDFLocale-0001.bin From norbertschade at oaktech.com Mon Oct 9 15:37:21 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> constraints review Message-ID: <000301c03228$59876520$510714ac@nschade-w2.xionics.com> The current version of constraints are out for some days now. I want to give everybody a chance to review it. As I want to decide on the current structure, I am setting ourselves a limit until Friday, Oct. 20th. We need a reliable constraints structure, when we want to be productive on paper handling. Please concentrate on the structure, not on variable names or parameter values. I'll be in the office the next three weeks continuously. So I am ready for questions and input. Regards Norbert From norbertschade at oaktech.com Tue Oct 10 16:42:59 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> preconfigured drivers Message-ID: <00e901c032fa$ad63b720$510714ac@nschade-w2.xionics.com> I know that many printer manufacturers are looking for a chance to help their customers with preconfigurations of drivers. That's mainly something requested by supervisors and network administrators. These people are typically driver and installation experts. So they would like to prepare a customer specific configuration, which all end-users in that company would use when installing that driver. It would not be too difficult adding an optional key like "Preconfiguration" to each feature (independent from any locale), which would fulfil exactly that request. Do you think these supervisors and administrators would feel comfortable adding an XML keyword for each setting, which they want to differ from the printer manufacturers default setting or does that sound unreasonable? They normally (if we do not prepare something extra for that or printer manufacturers provide that on their site) would not have the DTD file for validation. So there is some danger to mess it up. On the other hand a standard XML editor is quite simple to use. Tell me your opinion. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001010/29c5f889/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Oct 11 14:40:42 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> DTD structure Message-ID: <000901c033b2$c4a64480$510714ac@nschade-w2.xionics.com> We have to decide on the overall file and include philosophy of DTD files. As proposed some days ago, it has some advantages to split sections of the whole DTD into separate DTD file and include them in the technical master file. Please study attached files. The "UPDF Constraints.dtd" (previously named "constraints.dtd") is unchanged to the last version. Search for "Constraints" in the technical master "UPDF.dtd". See the call from PrinterCap somewhere in line 267 and the reference to the include file in lines 814, 815. Open XML Authority (or similar app) and click around watching the icons with the crosschecked red line. These descibe the modules of the include file and are not edited. Open XML Pro (or similar app) and see that I have added some simple constraint for demonstration purpose only below PrinterCap. It all works fine. This proves the functionality. Please ignore the problems with the validity. We still have to clean up some legacy problems from earlier work. I'll try to work on that before the conference as much as possible. If I do not hear any contradiction this week this philosophy will be decided and we will use it for other sections like fonts, too. Regards Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 18072 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/hplj8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: text/dtd Size: 1867 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/UPDFConstraints-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: updf.dtd Type: text/dtd Size: 30267 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001011/a1dd0e8c/updf-0001.bin From norbertschade at oaktech.com Wed Oct 11 14:57:55 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> UPDF status Message-ID: <000b01c033b5$2ce24f60$510714ac@nschade-w2.xionics.com> Ladies and Gentlemen, I think we get some stuff together these days. It is not so much inventing new functionality or write new XML. It is much more bringing the pieces together and lining it all up. I assume everybody recognizes that the big pictures is making progress, now that we have two more sections well prepared and are grinding through the remaining problems. And we get some good news from the industry proving that our activities are considered more seriously than half a year ago. I would like to get a preliminary count who is intending to attend the UPDF day in Boston to get a feeling for sample printouts, etc. BTW: Oak Technology may attend with a group of four people including me. The more you participate in the current email discussion, the better the conference will be prepared. Thanks so far Norbert Schade Principle Software Engineer Oak Technology Inc., Imaging Group From norbertschade at oaktech.com Thu Oct 12 17:19:15 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> corrected versions Message-ID: <001401c03492$1325fc60$510714ac@nschade-w2.xionics.com> I have worked hard to correct all the problems with the old XML file based on the old technical master UPDF.DTD. I tried to stay with the structure as much as possible by making some elements optional, adding some small pieces here and there. Now the DTD as well as the XML file should be error free. I got a successful validation in my XML editor. The warnings (no error!) I get in XML Authority 1.2 are a current limitation of the application. I am in contact with them. See note: """The yellow warnings Authority issues when loading the DTD are a current limitation of Authority's support for this type of structure. You are correct, this is valid. Authority supports this, but needs to fully expand the attribute type. The logical structure is not changed, Authority's yellow warnings are just telling you that the source will be saved as you see it in the source pane. The next release of Authority is targeting full support of these structures as you have written them. If you have any further questions, impressions, suggestions, etc. please don't hesitate to contact me again. """ (comment from extensibility) The "UPDF Constraints.DTD" has not changed. That is another step to come to the big picture. Now we can work with the master dtd, which already includes the dtd for constraints. While reviewing the sections and working on paper handling, we can clean up. I want to discuss one common feature out of paper handling publically in the Internet as a sample. I think print media size is the most important. So let's take that. The point is to get all necessary information together. I can wrap it into XML, as I have improved on the syntax. It's not mainly about XML, but I would like us to use standard applications to see the structure. That is possible without understanding one line of XML. I'd like to have a continuous contact in the IPP group for some time when working on paper handling. It's about implementing IPP keywords the best way. To make everybody understand the issue: This is affecting the way a driver is feeding and listening to a language monitor or similar functional unit in a client. We will make some basic decisions, what a driver can expect from a UPDF to assemble perfect IPP. If we can work the architecture out during the bake-off next week, that would be perfect. The real discussion should not be much more than an hour. The rest like assembling lists can be done by email. Regards Norbert -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 19815 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001012/be229343/hplj8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: text/dtd Size: 32633 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001012/be229343/UPDF-0001.bin From norbertschade at oaktech.com Mon Oct 16 11:38:18 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> DTD architecture Message-ID: <000b01c03787$1bce6e40$510714ac@nschade-w2.xionics.com> There were no complaints about the new DTD architecture. The time limit ran out last Friday. So from now on we go with one technical master dtd (UPDF.DTD) and one locale dtd (UPDF Locale.DTD). The master dtd will refer to a number of modules, which are be included. For now we have identified three modules: 1. constraints (UPDF Constraints.DTD) This reference is already implemented. 2. print media handling (UPDF PrintMediaHandling.DTD) This reference will be implemented this week. 3. font handling This reference will be implemented later. There are some more details like attributes to be cleared by that is ready to be implemented. I think about one separate module for all entities. Others may follow. We want to accomplish a number of targets with that architecture. 1. It will be easier to develop single modules. 2. It will be easier to test single modules. This probably will save the most time. 3. Development can be shared by a number of people. 4. It is easier to get an overview about one section. Regards Norbert Schade From norbertschade at oaktech.com Tue Oct 17 09:30:44 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> Mike Yeung's email address Message-ID: <001701c0383e$74b7bc20$510714ac@nschade-w2.xionics.com> Mike, in case you still watch the UPDF emails, please answer. I have some questions about the meaning of certain fields, which I think only you can explain, as they may be from the original dtd. If somebody from Toshiba is listening and has his contact, please forward this to him. thanks Norbert Schade From norbertschade at oaktech.com Tue Oct 17 11:21:26 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> new architecture, next step Message-ID: <001c01c0384d$ebe710c0$510714ac@nschade-w2.xionics.com> We finished another step of the new architecture. Now all entity definitions are gathered in one external DTD. As an external DTD can only be connected to the calling one by the top element, we had to create an optional dummy element "OptionalDummyElementForExternalEntities". If anybody has a problem with that minor inconvience, please reply. This element does not need to be defined in any XML file. The main advantage of this structure now is that entities, which have to be defined for several dtds, are now central. One definition is enough. Whenever the structure of any dtd changes - even when elements will be moved from one dtd to another - we need not touch the entities. For my personal feeling this is the final design. From now on we will just talk about isolating some more sections into external dtds, which just means duplicating the process carefully at some other place. Just keep in mind that the "UPDF Locale.dtd" is not an external dtd, but a separate, independent one. BTW: Of course, dtds will not appear on the end-user's workstation. Only the XML files will show up there. Dtds are only necessary to validate the XML on the developer's workstation. So this whole discussion will not affect the end-user at all. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: hplj8150.xml Type: text/xml Size: 11498 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/hplj8150-0001.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF.dtd Type: text/dtd Size: 20644 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDF-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF PrintMediaHandling.dtd Type: text/dtd Size: 5183 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFPrintMediaHandling-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Entities.dtd Type: text/dtd Size: 5296 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFEntities-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UPDF Constraints.dtd Type: text/dtd Size: 2112 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001017/0084da74/UPDFConstraints-0001.bin From norbertschade at oaktech.com Wed Oct 18 13:07:59 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> external entity for entities Message-ID: <000301c03925$f8a4d8a0$510714ac@nschade-w2.xionics.com> I learnt today that every external module accessing entities must as well include the entities entity. So I copied that over from the master dtd. Now I have access to the entities in print media handling. This needs further testing. Norbert Schade From norbertschade at oaktech.com Tue Nov 7 15:58:32 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> meeting minutes Boston UPDF conference Message-ID: <004901c048fd$7e0d4ae0$510714ac@nschade-w2.xionics.com> Please find attached the meeting minutes in three different formats. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: Meeting Minutes UPDF Group 1000.doc Type: application/msword Size: 24064 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001107/48813492/MeetingMinutesUPDFGroup1000-0001.doc -------------- next part -------------- Minutes of the UPDF Working Group Meeting October 27, 2000 Meeting Attendees Mark VanderWiele IBM Shawn Flynn Bitstream Don Wright Lexmark Carl-Uno Manros Xerox Dave deBronkart PODi Jim Sommer Granite Systems Ron Bergman Hitachi Lee Farrell Canon Norbert Schade Oak Technology With the IPP bake-off in the Oak facilities just behind we met in Boston, which I consider my home conference. Therefore I put some extra effort into the preparation. I think it paid out. The general direction for the meeting was to provide the big picture and to move several components together to the big common structure. Major items discussed ? File structure of the UPDF DTD files Please recall some emails on the distributor from October 2000. We agreed that we split the big dtd into a technical dtd and a separate dtd for locales. The technical master is split into a master and a number of modules. These modules are realized as external dtd. We agreed on the following modules: Font handling, Print media handling, Constraints. Other modules will follow. It is not planned to define more than ten modules. Each module presents a large logical unit. It is easier to develop and test those smaller modules by temporarily converting it into a standalone dtd and build sample XML files on top of it. This is quite an easy process. We agreed on building one special external module for all entities. This file structure has to be checked with the intended XML file structure explained below. It may be necessary to separate the external modules into separate dtd. Consulting requested! ? File structure of the UPDF XML files Although XML seems to be weak in this area, the group is leaning towards modular units. It is my (Norbert Schade) understanding that each module is exactly based on one external dtd or the master dtd. There are no arbitrary compositions. E.g. it would not be allowed to build one XML file for print media sizes and another for finishing features. This has to be assembled into one XML file for print media handling based on the print media handling dtd module. This procedure creates reusable modules. We have to continue working on the proper references. Do we want to define certain file naming conventions and/or internal references. Something like a module script file would be another alternative. Consulting requested! There will certainly be one XML file per locale based on the locale dtd. References to be done. ? Installable options We were more or less agreeing to use the same technical dtd for installable options, too. As almost all features in the technical dtd are optional, any installable option description would have the same structure as a basic device description. It would just be much smaller typically. No installable option description would have a reference to any device. It's the other way around. A basic device description has references to installable options. That allows reusability of single installable options. An installable option would have its own locale descriptions. I am preparing a picture to demonstrate the different units. Although this is quite a complex and laborious discussion, I am glad we entered it eventually. That shows that developers have started thinking how to convert their current data into an UPDF format, how quickly a new device description could be created by assembling several pieces from previous descriptions. It also shows how much different people already think about how a driver would best use the information for a specific operating system. Two other areas drew our attention: ? Reference list for features, which have to be identified by at least one operating system, e.g. paper sizes. We certainly need a list for that. Basically we could take any list available in the market or create a new one (only recommended in emergency cases). Right now we are looking over our shoulders to the IPP group asking whether they do or are willing to provide these lists. Carl-Uno, this is something we should talk about. ? Event handlers We talked about the basic idea and it looks, as if it is accepted. It needs some detailed samples to examine the value of this conceptional feature. To be further investigated. I think the most important item on our to-do list is resolving all the issues with the file structures and the references between the files. Please think about it, wait for some simple pictures I am preparing right now and give me some feedback. prepared by: Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: updf-minutes-001027.pdf Type: application/pdf Size: 7818 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001107/48813492/updf-minutes-001027-0001.pdf From norbertschade at oaktech.com Tue Nov 7 16:54:27 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> upcoming conferences Message-ID: <006401c04905$4e83d2a0$510714ac@nschade-w2.xionics.com> We will meet in San Diego on Monday, Dec 4th. I am happy that we have got a Monday and no parallel conference the first time. We got some positive input from some companies in California. I am looking forward to continuously get more people from real driver development involved. We need these people to get feedback, where problems with current driver concepts are, which we want to overcome. And I know there are a number of companies in driving distance. So I hope to see a number of programmers there. During the Christmas / New Year season I'll be in Europe for about three weeks (private). That keeps me away from preparations for Hawaii for some serious amount of time. We haven't created some sample font data in the new format developed in San Francisco so far, which is necessary before we can extend it and check for Asian fonts (vertical writing). Extensions for Asian fonts was one of the agenda items for Hawaii expecting some Asian developers show up in that case. Mark VanderWiele from IBM does not seem to be available for Hawaii. Taking all that together the UPDF group will not meet in Hawaii. We will meet again during the PWG conferences in March and April. That gives us enough time to the April conference another major event for UPDF. To confirm it: We will meet Monday, 4th, in San Diego (preliminary agenda coming soon). We will not meet in January in Hawaii. We will meet in March and April. Regards Norbert Schade From norbertschade at oaktech.com Wed Nov 8 13:41:37 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> file structure sample Message-ID: <001e01c049b3$8857c140$510714ac@nschade-w2.xionics.com> Find attached a sample for the file structure we talked about before and during the Boston conference. Please take a careful look and note: 1. The green elements are dtd files. "UPDF Entities" can be invoked by any other dtd as an external dtd and is intended to be so. "UPDF Locale" is a standalone dtd, separate from UPDF.dtd. You see that there are lines going from UPDF.dtd to the three light green dtd files. The lines shall indicate that the light green dtd files are external dtd files to the UPDF.dtd. In case we want to create physically separate XML files for sections like print media handling, I'm afraid we have to remove these lines and convert the light green external dtd files to standalone dtd files. Otherwise I'd expect problems with validation. By removing the lines we'd cut the connection to the master dtd. 2. The master XML file (I chose the extension upd for all XML files in my sample) without any background color has tags for internal modules, installable options and locales. These units themselves do not have any reference back to the master unit. In this sample we are not working with a script file, but the tags holding the references (in this case file names). That implicitely requires that the master unit knows about the additional modules. In case a module (like an installable option or a new language) will be added late after shipment of the original device the master unit has to be edited. I want us all to be aware of that. 3. XML files names are arbitrary in this sample, as long as they are referenced correctly in the master unit's tags. 4. Basically all yellow modules can be shared between master units like "80 PCL XL fonts.upd" is shared by Printer A and Printer B. A developer certainly had to draw his/her attention to the constraints to make sure the constraints are not model specific. 5. Installable options can be shared between devices like "Input Unit 1.upd" is shared by Printer A and Printer B. 6. Theoretically XML file for locales could be shared, too. In reality I think this will not happen, as something like the model name is always different. 7. The installable options are completely separate modules. They can be added and removed quite easily as a whole unit by editing the master XML of the printer (or a script file, if we decide so). A developer can decide not to support installable options for some time to get his project running and that would be perfectly fine. Just the UPDF architecture should be open to extend it. Basically he could even leave out the support of locales for some time and just use the name id reference instead, which may not be a nice UI string, but it could be used as a string, and use the first element as default simply. But I want us to set the directions for all those extensions, that as few code as possible has to be changed to extend the functionality. 8. I was thinking about a different file extension (uld = universal localization & defaults) for the locale files. For now I take that back. 9. Installable options may have different locales than the master unit. I recommend to make one locale mandatory (US English) and use a kind of fallback mechanism to select a proper substitution. The UPDF group could provide some fallback recommendations, if required. Please keep in mind: We are discussing the dtd and the XML file structure. That does not necessarily mean that the XML files are the files used by the driver. They could, but they need not. A driver (or a correspondent installer) could create some platform specific binary data out of it - for performance or other reasons. This is a separate issue and I want to leave that open to the driver developers. In case people request some conceptional ideas, the UPDF group may think about some recommendations. Ok, I would like us to finish this discussion in San Diego. So let us work it over in the upcoming weeks. Waiting for comments. Regards Norbert Schade -------------- next part -------------- A non-text attachment was scrubbed... Name: File structure.ppt Type: application/vnd.ms-powerpoint Size: 50688 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001108/5196e325/Filestructure-0001.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: file-structure.PDF Type: application/pdf Size: 11141 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001108/5196e325/file-structure-0001.pdf From norbertschade at oaktech.com Wed Nov 8 13:55:31 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> preliminary agenda for San Diego Message-ID: <002401c049b5$7979af60$510714ac@nschade-w2.xionics.com> I would like to concentrate on the file structure the next four weeks and get that nailed down in San Diego. This has the top priority. It includes the clear definition how many internal modules we want to have (e.g. Font handling, Print media handling, constraints). I hope we'll make some progress with the print media handling dtd module, which then can be evaluated in detail in San Diego. If there is time before and during the conference - and that depends how many people will contribute - I'd like to prepare the building of a few sample device resident fonts. I'll wait whether some other issues will pop up in the distributor. The closer we come to a sort of full scaled format, the better we can cooperate with other standards like the PODi or some Linux activities. I want to show and prove our readiness and interest here. The closer we come to a sort of full scaled format, the better we can talk about details to developers for an optimal implementation. That is another area, where I start reserving some time in my mind. The UPDF group has pointed out several times that we want to provide active help during implementation of the format into drivers. Regards Norbert Schade From norbertschade at oaktech.com Fri Nov 10 10:22:52 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> registered parameters Message-ID: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Some operating systems insist to be informed about certain features. Print media sizes are a good sample. A universal client/driver has to know about all predefined parameters for all features any OS is interested in. There is no way around it! There are two ways to go: 1. A universal description like UPDF lists all keywords for all OS (the list is not too big) and offers the developer of the description a list of predefined parameters. For the sample print media size this could come out as a combo for registered MS Windows parameters. There could be another combo for McIntosh parameters and other combos, if Linux has new requirements. 2. We use a common reference and leave the conversion from the common reference to the OS specific one to the client/driver. In this case the list MUST be a superset of all registered parameters for all features in all OS. 2a. In the last UPDF conference we were talking about using registered IPP values as a common reference. The question is whether IPP wants to extend their lists to the required amount. For the sample print media sizes MS Windows is supporting about a good 100 predefined values, which of course then all must be supported. 2b. Theoretically there is the chance that the UPDF group makes up its own list. But we want to be very careful not to confuse developers with just another list of parameters. As far as I know the list includes the following features: Print media size Page orientation Print media source Duplex Print media type There some more when it comes to Print quality or Font handling like download formats. In Boston the UPDF group requested to find out how much IPP can and will provide the necessary list. That would require to extend some lists and maybe create new ones in IPP. It is to be discussed whether this would just be a merge of all known predefined parameters or IPP tries to sort out doubles and minimize the list as much as possible. This would leave some responsibility (and chances for error) to the driver developer. I need feedback on this during the upcoming week. Selection 1 would leave that responsibility to the developer of the UPDF. He'd have to do some more entries, but has more flexibility on the other hand to specify a certain feature exactly as he wants. It would be easier for driver developers. They'd just read the proper field for their announcements. We have to decide on this the next days. It is an important detail in the UPDF spec. So please provide your comments in the distributor. Regards Norbert Schade From markv at us.ibm.com Fri Nov 10 10:53:58 2000 From: markv at us.ibm.com (Mark VanderWiele/Austin/IBM) Date: Wed May 6 14:05:07 2009 Subject: UPD> registered parameters Message-ID: For me there is only one real option which is to keep the IPP and UPDF definitions in sync where they have common components and extend the IPP list where necessary. Note, IDs are good for fast matching, however we must supply enough information so that the system does not stop when it is presented with a new ID. For example I do not like systems which are completely reliant on predefined knowledge of form ID's and there sizes. When a new form or custom form comes along the system falls apart. More specifically, some word processors store the form ID returned from the driver in the document which may be a custom form and make no sense to another OS or across the network. Regards, Mark VanderWiele IBM 512-838-4779 email: markv@us.ibm.com From mike at easysw.com Fri Nov 10 12:13:35 2000 From: mike at easysw.com (Michael Sweet) Date: Wed May 6 14:05:07 2009 Subject: UPD> Re: IPP> registered parameters References: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Message-ID: <3A0C2CBF.5F2CD5D@easysw.com> Norbert Schade wrote: > ... > 2a. In the last UPDF conference we were talking about using > registered IPP values as a common reference. > ... > As far as I know the list includes the following features: > Print media size > Page orientation > Print media source > Duplex > Print media type > > There some more when it comes to Print quality or Font handling like > download formats. > ... First, please *do not* rely solely on a keyword-based media size attribute. Such things are nice for the standard sizes but completely ignore variable sizes. You should allow keywords *and* measurements, which allows the driver/printing system to do any necessary mapping to the "native" value(s). Along with variable size support you'll need to communicate the minimum and maximum media sizes supported. FWIW, if you haven't done so already, please look at Adobe's PostScript Printer Description specification. It has its limitations (no "range of values" type of options, only supports PostScript directly, can only provide a single UI language in each file, etc.), but it *does* address most of the issues that you are looking at now for describing printer options. For example, PPD files provide named sizes plus the page dimensions and imageable area for the printer. Variable size support includes orientation, min/max width/height, etc. This all allows you to map Windows/MacOS/UNIX/IPP media sizes to PPD sizes and visa-versa, and to support variable sizes as needed. FWIW, CUPS (http://www.cups.org) uses PPD files and maps the IPP attributes to PPDs and visa-versa. We've added additional CUPS- specific attributes to PPDs for non-PS printers to support extra printer drivers, etc. It works quite well. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com From norbertschade at oaktech.com Fri Nov 10 13:20:12 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> Fw: IPP> registered parameters Message-ID: <006801c04b42$def81960$510714ac@nschade-w2.xionics.com> Ok, Ok. Don't shoot me. I should have been more specific. I considered it common knowledge that a predefined parameter ID is only used additionally to numeric values for width, height and some other necessary parameters. I never questioned that and the current version of UPDF has that incorporated. I just want to set clear how far a UPDF format would take predefined parameters into consideration. Hoping to interpret Michael's and other comments right there is another option. 3. Do not specify any predefined parameter for any paper size. Leave that to the OS specific driver/client relying that it knows about width and height of predefined OS specific print media sizes (to stay with the sample) and assign them by interpreting the printer's values for width and height. So the driver would discover the proper predefined parameter for such an OS. It needs some rounding functionality. Probably this would be done once during installation or so. This puts some more burden to the driver developer of such an OS, but it is a clear statement. This could work well for this specific sample print media size. We'll have to see whether we'll find clear technical parameters for any feature. I put this option for vote. Regards Norbert Schade -----Original Message----- From: Michael Sweet To: Norbert Schade Cc: UPD group ; IPP Group Date: Friday, November 10, 2000 12:31 PM Subject: Re: IPP> registered parameters >Norbert Schade wrote: >> ... >> 2a. In the last UPDF conference we were talking about using >> registered IPP values as a common reference. >> ... >> As far as I know the list includes the following features: >> Print media size >> Page orientation >> Print media source >> Duplex >> Print media type >> >> There some more when it comes to Print quality or Font handling like >> download formats. >> ... > >First, please *do not* rely solely on a keyword-based media size >attribute. Such things are nice for the standard sizes but >completely ignore variable sizes. You should allow keywords *and* >measurements, which allows the driver/printing system to do any >necessary mapping to the "native" value(s). > >Along with variable size support you'll need to communicate the >minimum and maximum media sizes supported. > >FWIW, if you haven't done so already, please look at Adobe's >PostScript Printer Description specification. It has its >limitations (no "range of values" type of options, only supports >PostScript directly, can only provide a single UI language in each >file, etc.), but it *does* address most of the issues that you are >looking at now for describing printer options. > >For example, PPD files provide named sizes plus the page dimensions >and imageable area for the printer. Variable size support includes >orientation, min/max width/height, etc. This all allows you to map >Windows/MacOS/UNIX/IPP media sizes to PPD sizes and visa-versa, and >to support variable sizes as needed. > >FWIW, CUPS (http://www.cups.org) uses PPD files and maps the IPP >attributes to PPDs and visa-versa. We've added additional CUPS- >specific attributes to PPDs for non-PS printers to support extra >printer drivers, etc. It works quite well. > >-- >______________________________________________________________________ >Michael Sweet, Easy Software Products mike@easysw.com >Printing Software for UNIX http://www.easysw.com > From sommer at granitesystems.com Fri Nov 10 13:53:36 2000 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:07 2009 Subject: UPD> registered parameters In-Reply-To: <001701c04b2a$193b4c00$510714ac@nschade-w2.xionics.com> Message-ID: <4.2.0.58.20001110133011.0095ed20@mailbox.bellatlantic.net> Windows applications can ask for the following printer information: 1) Paper Name (user string) 2) Paper Number (Windows defined DMPAPER_* number or custom size using a value greater than DMPAPER_USER) 3) Paper Size 4) Paper Margins 5) Maximum Paper Size 6) Minimum Paper Size 7) Source Name (user string) 8) Source Number (Windows defined DMBIN_* number or custom source using a value greater than DMBIN_USER) For a truly independent universal description file the name and dimensions must be provided for all supported sizes. It's not a difficult job to match those sizes with the platform predefined sizes. There should also be a way to indicate if the user can define their own paper sizes in addition to the list of supported standard sizes. For constraints this means not only specifying the supported sizes but also specifying a range of user defined sizes that the constraint applies to. Jim From Jim.Lo at eng.sun.com Tue Nov 14 15:37:08 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:05:07 2009 Subject: UPD> registered parameters Message-ID: <200011142037.MAA22768@mpk07.Eng.Sun.COM> 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) // //The following substrings as qualifiers have special meaning ... // // ENV: Envelope papers. // // JENV: Japanese Envelope papers. // // PENV: Chinese (PROC) Envelope papers. // // EXECUTIVE: The paper size varies by as much as 0.5 inch across devices. // // EXTRA: To print crop marks and bleeds marks in the margins, an extra size designates // a page size slightly larger than its corresponding standard size. However, // the increase in size (typically 0.69 to 1 inch) varies from a device to another. // // ROTATED: The image is rotated relative to the corresponding standard size. This // would usually produce a landscape image on the paper (the x dimension is // longer than the y dimension) // // SMALL: A paper that is the same physical size as the regular standard paper except // its printable area is typically 10 to 20 points smaller. // // TRANSVERSE: The long edge of the physical paper is perpendicular to the feed direction. // It is opposed to the cases where most printers feed paper with the // short edge of the paper perpendicular to the feed direction. // //Notes: // // Dimension values enclosed in {} are specified in points (1 point = 1/72 inch; // 1 inch = 25.4 milimeter) // Dimension values enclosed in [] are specified in their original measurement unit B. Feature/Option Display Names For en-US Locale (PaperSize etc) //For en_US locale: // //The human-readable display strings are arranged in such a way that major keys come before minor keys. //Taking PaperSize as an example, a country or area name comes before anything else. //Then, a standard paper size name comes with zero or more variant qualifiers, such as Rotated and Transverse, //which are enclosed in parentheses. Finally, dimension field in original measurement units //is followed. Note that "North American" is implied if there is no country or area name //is explicitly specified for the sake of compactness in screen real estate. // //It is suggested that translation be performed on a word-by-word basis whenever possible so that //the display strings would be listed on screen more predictably when categorized as a result of //language-specific collation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001114/6057f32e/attachment-0001.html From norbertschade at oaktech.com Wed Nov 15 15:46:02 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> UPDF web page Message-ID: <000301c04f45$12386f40$510714ac@nschade-w2.xionics.com> We have updated the UPDF web page and made a few changes to provide the current versions of dtd and XML files plus some documentation there. Please check it out and tell me, if you have any problems. Regards Norbert Schade From norbertschade at oaktech.com Thu Nov 16 13:33:54 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> UPD drivers Message-ID: <000f01c04ffb$c656b250$510714ac@nschade-w2.xionics.com> At the current state of discussion I'd like to add an item to the agenda for San Diego. We will have some Q&A session how drivers based on the new UPDF files should be built. This could well be a continuous item for the next conferences. I want to keep this short (not more than an hour), as it is not the fundamental work of the group by definition and charter. But I realize that some issues with the description can only be solved when thinking about a real implementation. With the progress we made we just have to take this more into consideration in future. I may outline a chance how a UPD driver under Windows could be designed. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001116/a20a98e6/NorbertSchade-0001.vcf From norbertschade at oaktech.com Wed Nov 22 11:33:05 2000 From: norbertschade at oaktech.com (Norbert Schade) Date: Wed May 6 14:05:07 2009 Subject: UPD> registered parameters Message-ID: <004801c054a1$e40f7520$510714ac@nschade-w2.xionics.com> We have waited for comments on registered parameters until last Friday. The common tenor was to go with technical classifications based on numbers and attributes and not try map that to a global list. The decision is to go with that approach. I hope we'll be able to solve all problems coming up by that. I like to keep the format as clear as possible and not overloaded with nice, but redundant information. I want driver developers to expect a clear and transparent format to work with. So we will not save IPP or other keywords for paper sizes after this decision. We do not want to stop with the pure specification of the UPDF format. We already agreed that we will provide documentation on how to use the different fields and values best. Additionally the group is tending to give more help to driver developers. For now I do not promise sample source code. But things like Jim Lo's list of paper sizes is exactly what I mean by additional help. Putting together such overviews will be the exact help a driver developer is looking for. We may add this list to our documentation on our web site. Perhaps we'll create a special directory like "Driver developement recommendations". I will contact Jim today to find out, whether he is willing to accompany the format as a kind of print media expert. Maintaining that list would be one of the tasks. I'd like to see the list being unique. An Executive paper size should have exactly one value in our list. If a device has a different implementation with other values it will not be detected as the standard Executive paper size, although it could be considered a predefined custom paper size with the same name by drivers. If in doubt I like clear and unique information more than ambivalent documentation, which will not provide the quick orientation people are looking for. I do not like but I'm willing to buy some disadvantages for that. To stay with this sample we will reflect all necessary attributes in the UPDF format. I would like to add some recommendations how to round paper sizes to standard sizes in drivers (define an error range). BTW: This would be a nice area for some sample code, which likely exists already at a number of places. Just keep a number of #define outside the code like StandardSizeErrorRange and UnitRelatedErrorRange (perhaps even per typical unit like inch, mm, etc). Input parameters may be just a pointer to a value (relative to mm/1000, which will be the UPDF unit) and perhaps a unit const (relative to mm/1000; a sample value for mm would be 1000). The return value would be a driver and therefore OS specific standard size or NULL. A driver would refer to his list of standard sizes (structure with OS_ID, width and height in mm/1000). The value may be reset, if discovered as a standard size, as the OS standard size is assuming a slightly different value, or recalculated because of unit related rounding. If anybody will contribute such a small piece of code, we would add it to the recommendations. Regards Norbert Schade Oak Technology, Inc. Imaging Group 10 Presidential Way Woburn, MA 01801-1041 USA phone: 1-781-638-7614 fax: 1-781-638-7555 email: norbertschade@oaktech.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Norbert Schade.vcf Type: text/x-vcard Size: 447 bytes Desc: not available Url : http://www.pwg.org/archives/upd/attachments/20001122/859a6e00/NorbertSchade-0001.vcf From Jim.Lo at eng.sun.com Fri Dec 1 15:13:40 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:05:07 2009 Subject: UPD> completeness: commands generation (xpdo) Message-ID: <200012012013.MAA10134@mpk07.Eng.Sun.COM> Hi, Per Norbert Schade's request, I am trying to exchange what many of us working for Sun Microsystem think in many areas of printer description in terms of what may be a must and the possible solutions from the perspectives of looking for a "long term" solution for universal (raster-based) printing services (framework and drivers) under Unix and other platforms. As a new late comer, I am not sure it is a good way or a good timing now but I am doing it anyway ... The first thing I'd like to discuss is the requirement in printer description for run-time evaluation to generate raster data and printer setup commands. I have an impression that it had been brought up to UPDF's attention in the past (by Don Wright of Lexmark?) for the "completeness" of any page description file or otherwise those commands would need to be "hard-coded" somewhere else in C code for which the programming interface needs to be defined (and therefore must be covered as part of UPDF?). Attached (xpdo.nov01.html) for your reference please find the extensible printer description object model based on XML technologies. It is a very simple virtual machine for XML-based printer description language in an attempt to address those command generation issues in addition to custom declaration, modulization and binary encoding etc. My appology that GPD teminologies are used in the document for a demonstration because GPD is the only printer description format I know of that generates raster data for low-cost printers. Table of Content: ----------------- Introduction Data Types: string, name, int, float, boolean, array, dictionary File Modulization for Printer Model Family Hierarchies Executable Objects and Execution Context The load Executable Object and Paramter Dictionaries The switch Executable Object The Math Executable Objects: idiv, add, sub, expr The Formatter Executable Objects: tostring, numformat, maxrepeat Samples in the document: ------------------------ - for raster data commands generation: 5100 {1B}*{03} 12600 {1B}(*p- - for multiple-way runtime dependency (e.g., a printable area depends on the paper size and perhaps the orientation chosen at runtime): - for Custom feature/option (e.g. paper size): Best regards, Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Menlo Park, California From Jim.Lo at eng.sun.com Fri Dec 1 15:21:14 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:05:07 2009 Subject: UPD> completeness: commands generation (xpdo) Message-ID: <200012012021.MAA10336@mpk07.Eng.Sun.COM> <> Hi, Per Norbert Schade's request, I am trying to exchange what many of us working for Sun Microsystem think in many areas of printer description in terms of what may be a must and the possible solutions from the perspectives of looking for a "long term" solution for universal (raster-based) printing services (framework and drivers) under Unix and other platforms. As a new late comer, I am not sure it is a good way or a good timing now but I am doing it anyway ... The first thing I'd like to discuss is the requirement in printer description for run-time evaluation to generate raster data and printer setup commands. I have an impression that it had been brought up to UPDF's attention in the past (by Don Wright of Lexmark?) for the "completeness" of any page description file or otherwise those commands would need to be "hard-coded" somewhere else in C code for which the programming interface needs to be defined (and therefore must be covered as part of UPDF?). Attached (xpdo.nov01.html) for your reference please find the extensible printer description object model based on XML technologies. It is a very simple virtual machine for XML-based printer description language in an attempt to address those command generation issues in addition to custom declaration, modulization and binary encoding etc. My appology that GPD teminologies are used in the document for a demonstration because GPD is the only printer description format I know of that generates raster data for low-cost printers. Table of Content: ----------------- Introduction Data Types: string, name, int, float, boolean, array, dictionary File Modulization for Printer Model Family Hierarchies Executable Objects and Execution Context The load Executable Object and Paramter Dictionaries The switch Executable Object The Math Executable Objects: idiv, add, sub, expr The Formatter Executable Objects: tostring, numformat, maxrepeat Samples in the document: ------------------------ - for raster data commands generation: 5100 {1B}*{03} 12600 {1B}(*p- - for multiple-way runtime dependency (e.g., a printable area depends on the paper size and perhaps the orientation chosen at runtime): - for Custom feature/option (e.g. paper size): Best regards, Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Menlo Park, California -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001201/c73513c2/attachment-0001.html From Jim.Lo at eng.sun.com Mon Dec 4 17:32:23 2000 From: Jim.Lo at eng.sun.com (Jim Lo) Date: Wed May 6 14:05:07 2009 Subject: UPD> completeness: Printer error/status monitoring (Responses framework) Message-ID: <200012042232.OAA07854@mpk07.Eng.Sun.COM> Hi, Another missing part in a printer description file format (including GPD) may be in the area of printer error/status messages monitoring. It is considered especially important for many new printers that support bi-directional USB (as opposed to traditional one-directional centronic parallel connection that depends on hardware signals for monitoring). For your reference, included is a document in an attempt to address this issue (its HTML version is also attached). I am not terribly familiar with this area which I consider tough because what we are trying to deal with is kind of drawing road maps (printer description files) by a simple tooling methord (the Responses framework) for many existing roads (printer languages) with not necessarily very regular shapes. The printer type that had been addressed in the document is PostScript. I also used a EPSON printer as my target try out in the document not only because I think it is rich and should be quite typical but also that there are simply no programming manuals available in public for many NEW printers. Anyone who like to give the framework a try with another printer or extend the framework if necessary would be helpful to move towards the design goal. Best regards Jim Lo Internet Appliance Group Sun Microsystems, Inc. PS. As you can see, the document is encoded for a demonstration purpose in terms of XPDO objects specified in my previous email. ..... It would be nice to have a GUI on a host machine to monitor a target printer for its possible error conditions and working status changes especially when there is no LCD panel on the printer. It is especially important for printers supporting bi-directional I/O connectivity such as USB (Universal Serial Bus). Those printers usually provide a much richer set of device-dependent proprietary notification and enquiry messages compared to a hardware based interface for the traditional one-directional centronics parallel connection which provides a much limited set of less clearer error/status messages. This document provides a device independent way to describe device-dependent message formats so that most printer vendors can benefit from a common printer-decription-file-driven GUI services in a consistent way without having to write any line of C code for their device dependent messages. The Responses tag and all its predefined nested element tags are introduced to enable dynamic configuration, error, warning and progress enquiry and responses. They are all described in a unified format which is demonstrated by the following two examples for PostScript printers and EPSON inkjet printers respectively: /Code <11> Note that the Responses entry is optional and is not used for a driver operating on a target printer locally connected with a non-bidirectional transport type (e.g., traditional one-directional parallel port). In case of operating in a non-bidirectional mode, commands that require responses from the printer will not be sent down. Instead, predefined hardware signals from a parallel port can be used but with much less comprehensive error/status messages to a human user as demonstrated below in terms of a Unix parallel port I/O interface whose function names should describe themselves: isPrinterTimedOut() => "Not Responding" isPaperOut() => "Out of Paper" isPrinterSelected() => "Off Line" isPrinterError() => "Error" Jim Lo (jim.lo@eng.sun.com) Internet Appliance Group Sun Microsystems, Inc. Last modified: Mon. Dec 04 2000 13:25:23 PDT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20001204/67541bac/attachment-0001.html