From harryl at us.ibm.com Tue Jan 21 18:49:58 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:00 2009 Subject: UPD> D.C. meeting Message-ID: Need to decide if UPDF will meet in D.C. Mar 31 week. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030121/a8d03f02/attachment.html From NorbertSchade at oaktech.com Tue Feb 11 18:38:03 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> work for version 0.85 Message-ID: This lays out the work for the next weeks: 1. Further changes related to the use of namespaces. This is more work than we originally thought. I have created a 0.85 directory out on the ftp site (ftp.pwg.org/pub/pwg/upd/0.85), which will hold the current version of this work. We don't want to confuse the 'official' version out on the ftp site so that people can continue to use it. I'll let you know about the progress. 2. Incorporation of the semantic model schemas. We have started that already and will increase that effort. This includes the proper use of patterns. 3. Incorporation of the PSI capabilities schemas. We have started that already and will increase that effort. 4. Detailed attributes for font handling. So far many constrainsts don't exist. One can simply enter any string for many font attributes. We want to provide a bit more guidance. That will keep us busy before D.C. Regards Norbert Schade From norbertschade at attbi.com Thu Feb 13 08:35:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> 0.85, namespaces: Locale schema Message-ID: <002701c2d364$cdb3d3e0$a8948018@ne1.client2.attbi.com> I updated the locale schema on the ftp site. Details: - removed the user interface section. - changed all elements to complex types. - to do: we are still working with Predefined_ID, Proprietary_ID instead of a union. this is the next step. I assume some people would like a pattern for free entries (previously Proprietary_ID). If somebody is fast with those declarations, please jump in. - to discuss: watching other schemas in PWG I see that attribute and element declarations seem to be located in different schemas. We have the attributes in "UPDF Data Types.xsd" so far and I left the element declarations (the complex types) in the locale schema. questionable, if we want to source these out. Wouldn't be a big job. And wouldn't change anything for the developer creating the device descriptions (s/he wouldn't even notice). Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030213/33c97e21/attachment.html From NorbertSchade at oaktech.com Wed Feb 19 18:16:59 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> 0.85, UPDF main schema Message-ID: I copied the master schema UPDF.xsd together with the updated 'UPDF Data Types.xsd' schema to the ftp site, subdir 0.85. The complete schema has been changed so that it follows the complextype declarations like the locale schema, which I changed previously. All required namespaces are imported/included including the PWG schemas and the capability schemas except the font handling schema, which I had to take out temporarily. That leaves the font handling schema for the namespace task and we are done with those changes. Then I'll add it back as an include in the UPDF schema. Feel free to check it out. I'll let you know. Norbert Schade From NorbertSchade at oaktech.com Wed Feb 26 10:04:57 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> 0.85: namespace work Message-ID: I finished the bulk of the editing necessary to incorporate namespaces and element definitions as complex types instead of references into all UPDF schemas. I uploaded the following schemas to the UPDF site (ftp://ftp.pwg.org/pub/pwg/upd/0.85): - UPDF - UPDF Font Handling - UPDF Device Configuration - UPDF Option Configuration - UPDF User Policy - UPDF Command Sequences - UPDF Wildcards I have not changed the wildcard schema so far. But that's a short and easy one. We should discuss what namespace this should belong to. I'd like to discuss if we follow the MediaElements/MediaWellKnownValues idea and mainly group the attribute listings in one schema like UPDFWellKnownValues (previously UPDF Data Types) and global elements in another like UPDFElements. This is now possible more easily after the editing I did. Take a look and let me know. Regards Norbert Schade From norbertschade at attbi.com Fri Feb 28 09:29:53 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> positioning Message-ID: <001101c2df35$dc6baca0$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- // list of DRV_ keys // these keys have to be replaced with the proper values by the driver/client DRV_HorPos DRV_VertPos DRV_PageWidth DRV_PageLength DRV_RasterWidth DRV_RasterHeight DRV_NumberOfRasterImageBytes DRV_FontHeight // in hundredth of pt, where 72pt = 1inch // list of special entries for attributes without a dedicated constraint list select-first // select the first entry in the list available under the current dependencies From sommer at granitesystems.com Fri Feb 28 13:57:13 2003 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:00 2009 Subject: UPD> positioning In-Reply-To: <001101c2df35$dc6baca0$a8948018@ne1.client2.attbi.com> Message-ID: <5.2.0.9.2.20030228135430.00b3c328@incoming.verizon.net> I vote for positioning by dots in the current resolution. I vote for the origin to be in the upper left corner. I vote for adding the media size dimensions to the predefined variables. At 2/28/2003 09:29 AM, Norbert Schade wrote: >We have two predefined variables so far: DRV_HorPos and DRV_VertPos. >To further clarify the expected behavior, we have to specify details about >the resolution the driver is supposed to feed these variables in. >We basically have two choices: virtual units or current resolution. Both >have some plus and minus. I put that on vote. Default is current >resolution set by raster resolution. >Another item to be resolved is the specification of the origin and >therefore reference point for the positioning. >Two choices again: upper left (e.g. like Windows) or lower left (like >PostScript). I put that on vote too. Default is upper left. > >Whatever the decision is I think some people will need two more predefined >variables: DRV_PageWidth and DRV_PageLength. The driver will have to >provide these in the same units as DRV_HorPos/DRV_VertPos. >I will add them to DRV_keys.txt. Please indicate agreement. > >I will close the vote on March, 7th (next Friday). >Please vote and comment. Any other requirements in this area? > >Regards >Norbert > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030228/036bb4c3/attachment.html From norbertschade at attbi.com Sun Mar 2 14:44:16 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> How the create a print file: command sequences and events Message-ID: <000a01c2e0f4$202c2040$a8948018@ne1.client2.attbi.com> Haven't written that up this way. As David and Bob asked similar questions from different angles I thought this might be a good opportunity. How to define a print file The request to be able to provide parameters for features to be used in print files evolved into support of command sequences and events over time. Binary terms had to be supported as well as plain text. It was required to specify where in the print file a certain command sequence should appear. Later another decision was made: The real command sequences as used in PDL and probably job language was separated from the higher level device description, which is supposed to be more human readable. Therefore we created a separate schema for command sequences so that PDL experts could convert one PDL specification to another while keeping the device description almost aside. We did not want to work with gigantic switch definitions. So we attached parameter references to the features. To be able to do all this in XML we needed a tool we call Parameter Converter. This allows for the definition of binary terms in ASCII, references to keywords and attributes as well as simpel IF/ELSE statements. A high level description of the envisioned process may look like the following: 1. The driver holds a structure with the non-ambiguous setting of each attribute (means feature in many cases), but is prepared being overruled by the user's application. 2. The driver holds a structure with the non-ambiguous setting of all DRV_ keys. 3. Prepare a Parameter Converter function. 4. Any UPDF core driver is expected to understand all possible events, on start as well as on end of it. 5. When an event occurs for the driver, it checks the event list in the device description and checks all event records with that specific event. It may well find more than one record. They should be listed nicely, but I wouldn't rely on that. The order of records for the same event determine the order of command seqences. 6. For all records of this event: Feed the Parameter Converter with the command sequence of the corresponding XML file identified by the command sequence reference in the event. The other two parameter for the function are the pointer to the two structures of 1. and 2. (that's how I might do, feel free to do it a different way). Within the Parameter Converter 7. The command sequence may show references to unique attributes (dot works as separator, reference to Parameter is wrong as that's an element but no attribute, reference to ID is wrong as that's an attribute but ambiguous, reference to Parameter.ID is better but still ambiguous, reference to MediaSize_Record.Parameter.ID is fine) or DRV_ keys. The ID attribute will show another parameter reference for a special feature setting, which can then be finally resolved in the command sequence XML file (ResolvedParameters section). Check next event and start with 6. until done with all events. Some background info on the Parameter Converter: It started out as reverse Polish notation, but the request was a more human readable syntax. It should understand either ASCII characters or terms of certain syntax. These terms start with a two-byte format string, which tell about the expected output format. IF/ELSE structures are supported, but I wouldn't rely too much on nesting when developing the XML for a device. That's what I think. Did I forget something or wasn't clear enough? Ask in detail! Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030302/90bb211f/attachment.html From norbertschade at attbi.com Mon Mar 3 09:32:27 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> 0.85 update Message-ID: <00b701c2e191$b72a37a0$a8948018@ne1.client2.attbi.com> I have just updated the 0.85 directory. Some changes: - The wildcard sample schema follows the element declaration with complex types. - The Parameter element is global and placed in the data types schema. All other schemas use it. The command sequence schema has a ResolvedParameter element with two attributes ID and Value now not to be ambiguous. - The current capabilities schema you can find on the PWG site is implemented temporarily. I used it for GenericFeatures. This will be our location to try it out the next days. - The sample XML for command sequences is updated as well. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030303/ebaf592b/attachment.html From NorbertSchade at oaktech.com Tue Mar 4 15:24:30 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> update of xml files Message-ID: As the last step of the current changes related to namespaces and element type definitions I updated all sample xml files. Now we have a complete set of schemas and sample xml in the 0.85 directory. Watch that I swichted the GenericFeatures back to the 0.84 definition (I will use that term when I use something from last November) to validate all the sample features. You see that I just comment out one of the lines and use the other one to switch. Makes it easy to switch between GenericFeatures from 0.84 and 0.85. That means now we have a complete set of files on the latest level. Prepared for WellKnownValues from the Semantic Model as well as a serious test of capabilities element types. Feel free to check it out. You'd be prepared for the next tests. Regards Norbert Schade norbertschade@attbi.com From NorbertSchade at oaktech.com Tue Mar 4 18:50:41 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:00 2009 Subject: UPD> more accurate font attributes Message-ID: Some days ago I laid out another task, which is strictly device font related. While the overall structure has proven right for a while, we had some items on our to-do list. The most important one was to specify the attribute types more accurately. My proposal: 1. DeviceFont.ID fine as is 2. DeviceFont.Font_Family enum: DONTCARE, ROMAN, SWISS, MODERN, SCRIPT, DECORATIVE 3. DeviceFont.Font_Vendor make mandatory, but leave as string 4. DeviceFont.Encoding make mandatory, stays on to-do list for further details, must be an enum eventually 5. DeviceFont.Passive_Font mandatory, boolean 6. DeviceFont.Parameter fine as is 7. DeviceFont.IFIMETRICS_INFO make all attributes boolean, which is the simplest method. if somebody wants to group some flags, speak now. add TECH_TRUETYPE, TECH_TYPE1, TECH_MM, TECH_CFF. 8. DeviceFont.PseudoDeviceFonts fine as is 9. IFIMETRICS_Selection make all attributes boolean That's it for today. More to come. Please comment by Thursday, 13th. Regards Norbert Schade norbertschade@attbi.com From norbertschade at attbi.com Thu Mar 27 12:28:12 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Generic UI Message-ID: <00a701c2f486$3e7141c0$a8948018@ne1.client2.attbi.com> Lately there are some further discussions going on how to store data for use to create a proper user interface for a driver/client. I'd like to inform the group about some statements. 1. UPDF We store UI strings in different locales for features and their record (like the 'Media Size:' label and records 'Letter' and 'A4'). We store dependencies including the messages to be shown. Currently we do not save any other UI content. We had some draft construction at some time to learn about requirements, but moved that to a later level of the spec. 2. PSI The PSI group is proposing a different way to store this information in a capabilities schema. This is currently discussed between UPDF and PSI. the ideal outcome would be a common format for the common elements between the two standards. The current proposal includes strings needed for features and dependencies. It shows one additional entry (displayGroup), where somebody can assign a feature to a group. Looks pretty Windows related and is more or less indended to tell, which tab a feature belongs to. 3. Free standards group I'm not too close to the Linux efforts right now, but I know that people are working hard to store all information necessary to handle printing. 4. Foomatic I'm even further away from this group, but I know there are similar efforts going on there too. 5. KDE I've heard this week that these people are working on a generic way to store UI info too. Knowing all this I will gather some info and comment on them today in short statements, all titled 'Generic UI: ...'. Feedback appreciated. I'm happy to send that to another reflector, too, if somebody wants me and tells me how. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/57a34719/attachment.html From norbertschade at attbi.com Thu Mar 27 13:00:06 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Generic UI, high level architecture of a UI structure Message-ID: <00d301c2f48a$b38fb8c0$a8948018@ne1.client2.attbi.com> Some ideas of mine: 1. complexity specific UI Each description should have at least one totally generic UI - the absolute fallback. this one might be pretty basic. The technical requirements of the display may be very different (e.g. two-line text display, full-screen graphic display, etc.) May result in an attribute for display a UI structure is targetted for. 2. platform specific UI It should be possible to define additional UI structures for special platforms. I don't think it's possible to define something, which can be used under Windows XP and Mac OS-X, not even Mac OS-9 and OS-X. A driver would have to know an awful lot to filter certain features out depending on the actual platforms and as result of that - if possible at all - filtering some parts of the dialog may look pretty orphaned. This might be handled by an attribute Platform with a predefined list of entries (e.g. Generic, Win9X, WinXP, OS9, OSX, KDE, etc.). Fall back to Generic in case there is no structure for the platform the actual driver is working on. Not thoroughly thought of. 3. locale specific UI might be good to have some locale specific structures. just thinking of different strings lengths or right-to-left issues. would result in an attribute Locale with a predefined list of entries. it is my personal belief that the information how a feature should be used in one or more user interfaces should not be stored with that feature. the driver would not expect to read it that way and it would be rather confusing to read and get the picture. Instead I think of multiple UI structures with references to features as needed. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/762cd08a/attachment.html From norbertschade at attbi.com Thu Mar 27 15:30:43 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Generic UI: grouping and levels Message-ID: <00e801c2f49f$bddf4a60$a8948018@ne1.client2.attbi.com> While some platforms have their own philosophy how to visualize certain controls (what is a tab under Windows, is a panel on the Mac), we may want to stay out of the business of defining each last detail of a UI in a generic description. I'd be mainly interested to group features and nest groups. that might be defined on a quite high level. A dialog must start with a group. A group may have a string reference and must have at least one of feature|group. So UI1 may be something like Group1 Feature1 Feature2 Feature3 Group2 Feature4 This basically leaves it open, if Group2 is shown together with the first three features or if it's realized as a button to call a subdialog with Feature4. An attribute Level could further indicate the intended structure. UI2 Group1 Group2 Feature1 Group3 Feature2 this could be a sample for tabs or panels. An attribute Composition (superimpose/juxtapose) could further indicate the intended structure. So with elements group and feature and attributes FeatureReference to a feature respectively String, Level and Composition to a group you have a nice set of tools to define what your UI shall look like while leaving the final appearance to the driver. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/d484c5d1/attachment.html From norbertschade at attbi.com Thu Mar 27 15:40:54 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: Fw: UPD> Generic UI: grouping and levels, treeview Message-ID: <00f201c2f4a1$29e23dc0$a8948018@ne1.client2.attbi.com> I think a driver might switch to a treeview automatically in case it detects a group with Composition=juxtapose and - depending on the space reverved for that part of the UI - it detects to many controls to show them in parallel. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Thursday, March 27, 2003 3:30 PM Subject: UPD> Generic UI: grouping and levels While some platforms have their own philosophy how to visualize certain controls (what is a tab under Windows, is a panel on the Mac), we may want to stay out of the business of defining each last detail of a UI in a generic description. I'd be mainly interested to group features and nest groups. that might be defined on a quite high level. A dialog must start with a group. A group may have a string reference and must have at least one of feature|group. So UI1 may be something like Group1 Feature1 Feature2 Feature3 Group2 Feature4 This basically leaves it open, if Group2 is shown together with the first three features or if it's realized as a button to call a subdialog with Feature4. An attribute Level could further indicate the intended structure. UI2 Group1 Group2 Feature1 Group3 Feature2 this could be a sample for tabs or panels. An attribute Composition (superimpose/juxtapose) could further indicate the intended structure. So with elements group and feature and attributes FeatureReference to a feature respectively String, Level and Composition to a group you have a nice set of tools to define what your UI shall look like while leaving the final appearance to the driver. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/513b2ad6/attachment.html From norbertschade at attbi.com Fri Apr 4 12:08:01 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Positioning Message-ID: <001b01c2facc$bfde8960$a8948018@ne1.client2.attbi.com> Just to confirm: We added two variables DRV_PageWidth and DRV_PageLength to the driver variables. The driver is supposed to feed these in the current resolution. When specifying the positioning object, please assume that the origin is the upper left corner of the logical (before N-Up or zooming is resolved) page. The hardware margins are supposed to be part of the positioning values. So it's calculated from the edge, not for the printable area. If you need it for the printable area, you have to subtract something in the record. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030404/7af5dfca/attachment.html From norbertschade at attbi.com Fri Apr 4 12:24:53 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> user interface proposal Message-ID: <002a01c2facf$1d649320$a8948018@ne1.client2.attbi.com> I have put a new UPDF.xsd schema into the 0.85 directory. This one has a proposal for user interface structures. The element is called TBD_UserInterfaces and is assigned to PrintCapabilities. I left out any attribute for a complexity level assuming that a driver can somehow resolve that itself. I left out any attribute to handle locales. So this is the minimal set of elements and attributes I think we'd need for a reasonable approach. 1. You can create as many user interfaces as you like. It is recommended to create at least one, which then is not supposed to have a Platform attribute. If there is no structure at all, the driver might work with a treeview-like UI. If you have more than one structure you may want to create one (generic) with the Platform attribute as a fallback and others, which then are expected to have specific Platform attributes. 2. The main purpose of the user interface structure is to group features and provide a chance to nest groups. That allows a driver to read a very simple structure from top to bottom, identify easily to top entry level, etc. 3. A UIFeature refers to a technical feature (required). 4. A UIGroup can hold a UIFeature or another UIGroup. It may have a display string, but must have a Composition attribute. 4.1. The display string would work as the group title or even as a button text, if the group is realized as a subdialog. 4.2. Composition = juxtaposed means the driver is expected to show the new group within the current group. you may have three features plus two groups on the same level. The driver may check its space conditions and work accordingly. Composition = superimposed means the new group is expected to be shown a level lower. That may result in a new tab, a new panel, a subdialog or whatever the driver decides is reasonable. All other attributes of features may be determined by the driver platform dependent by checking other UPDF attributes or platform settings. Let me know. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030404/756eed78/attachment.html From norbertschade at attbi.com Tue Jun 10 11:42:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> label position Message-ID: <005601c32f66$ee2556e0$a8948018@ne1.client2.attbi.com> > Michael, > I'd like to discuss that one on the reflector. > > Michael's statement: > > - In the first tab, labels are above the control widget, on the second > tab, > > labels are on the left. Is this left to the implementation? (Note that > > from a UI point of view, it's quite hard to guess the best label > > position that fits the human eye). > > Expected comment and good point. > Yes, this is left to the implementation in the current design. > I understand your concerns. > This issue is at the border of the design. Once we dive into this, we'll be > seeing other valid requirements. And my personal judgement is that this is > likely platform specific and rather subjective, too. > If it were my driver, I'd precalculate the whole user interface during > installation of the driver and create something like a preprocessed > structure (BTW: I'd do that with the whole device description). > > My default arrangement would be 'label left of control'. While interpreting > the UI structure I'll do some calculations. I'd have some ideas of a minimum > width for certain controls and labels. Additionally I'd have some idea about > my maximum UI. If I'd blow it up during my preprocessing, I'd have to start > all over again with a fallback. The first fallback may be to arrange labels > at top of control. > So my personal driver may never show a label top of control without a space > problem popping up. > > Conclusion: > Valid comment, but conscious limitation of current design. > Other people to second either side of the statement??? > > Regards > Norbert > > Norbert Schade > 69 Prescott Drive > North Chelmsford, MA 01863 > 978-251-1017 > norbertschade@attbi.com > From norbertschade at attbi.com Tue Jun 10 11:48:43 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:00 2009 Subject: UPD> Fw: User Interface sample Message-ID: <007d01c32f67$c5ebae80$a8948018@ne1.client2.attbi.com> I've noticed that this one didn't make it to the reflector last week. So I'm trying again. BTW: This time I leave the bitmaps out and copy them manually to the ftp site in some minutes. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Cc: Michael Goffioul Sent: Sunday, June 08, 2003 9:12 PM Subject: User Interface sample I played around over the weekend to get used to it and find out, if I missed some important pieces. At least it works for me. Please go and check: ftp://ftp.pwg.org/upd/0.86/ There are two samples I practiced with: IndependentUISample.xml, which shows a sample, which has nothing to do with drivers or UPDF other than using the structure. I just played around. you may compare to the bitmaps I set myself as a target (see attached). The other sample is DependentUISample.xml, which uses real references to UPDF features of the same description. The user interface is still pretty dumb, but good enough for a glance. Same issues: I was thinking, if I could live without a 'page-based' composition and somehow extract that information from a special superimposed UIGroup, but I didn't get it so far. So it stays in. I didn't think too much about groups without a title so far. While an ID of a UIGroup necessarily contains a string reference (typically resolved in a locale), an ID of a UIFeature must contain a reference to a technical feature. Agreed? I am not specifying anything about justification or if the label of a control should appear left or above the control. I leave all that to the implementation and their automatic routines. Have fun. Questions? Norbert p.s.: I'm working in other sections. so these files are by no means final. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/01128457/attachment.html From norbertschade at attbi.com Tue Jun 10 11:50:15 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> Fw: user interfaces Message-ID: <008801c32f67$fc76ffe0$a8948018@ne1.client2.attbi.com> Noticed that this one didn't make it either. Next attempt. BTW: By now I copied most of the files to a 0.86 directory on the ftp site. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Thursday, June 05, 2003 9:29 PM Subject: user interfaces I reviewed the user interface section. Find attached the schemas and the spec (Word format for now). Search for 'UserInterfaces' and you can go from there. I didn't copy it to the ftp site yet, as I'm still working on some other stuff. you will see the full set of files there soon. Some details: - I added an attribute to determine the position of a UI control within a group. The attribute has a pattern as a data type to prevent developers from making mistakes. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/13d21fe3/attachment.html From norbertschade at attbi.com Tue Jun 10 12:01:46 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> Re: User Interface sample References: <000b01c32e24$48747d40$a8948018@ne1.client2.attbi.com> <3EE58B5B.E1707E32@imec.be> Message-ID: <009d01c32f69$98dd0900$a8948018@ne1.client2.attbi.com> Michael, I'll take this to the reflector as well, as it looks interesting for the group. Michael's statement: > - I agree that a UIFeature should always be bound to a technical feature. > But if we ever want to extend the spec for some other UI enhancements > (for example: a line separator), this is not true anymore. Or you use > another tag name for any potential UI enhancement Excellent point. I have no problem agreeing that I stopped at a certain point with the current design. Thoughts I had, but haven't realized so far: 1. We could include the user interface structures from a separate schema, which more easily allows other developers to use it for implementations, which do not even have anything to do with UPDF at all. Is that a common request? With that in mind a statement that a UIFeature must refer to a technical UPDF feature has come to nothing anyhow. 2. We could carefully (very carefully and not easily) add wildcards at certain points of the user interface section. That would allow other developers to extend it to their needs. Proposals? A problem to consider: A UPDF implementation should always at least "work" without these UI wildcards. Other feedback to this point? Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com From norbertschade at attbi.com Tue Jun 10 12:50:46 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> update of 0.86 Message-ID: <00c601c32f70$70c04fc0$a8948018@ne1.client2.attbi.com> I updated the 0.86 directory on the ftp site (ftp://ftp.pwg.org/pub/pwg/upd/0.86/). items: - removed DependentUISample.xml. is implemented in the normal sample device description now. - added the simple bitmap files for the UI mockup. - added the specification document (not yet in PDF format), which I'm working on heavily to provide the current level. I'll finish the current level end of this week. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/e74f8beb/attachment.html From norbertschade at attbi.com Tue Jun 10 22:12:35 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> editable combo boxes and input patterns Message-ID: <001401c32fbe$eccdae20$a8948018@ne1.client2.attbi.com> We have been looking for a way to propose predefined values to a device description developer, but allow him/her to still overwrite them. By using memberTypes in a union this is possible. XML Spy supports that functionality properly. Try it out with the latest schemas, which I have updated a minute ago. You may check the FaceName element of the device font section as a sample. You can see three predefined typeface names, but you can enter your own one. That was the intended behavior. By following that syntax we get closer to the Semantic Model, too. Another goal of ours. Another detail of the syntax we use lately is patterns to help the developer entering the proper values when they are proprietary up to some degree. We praticed this syntax within the font handling first. That is now almost finished. This will help us merging the Predefined_ID and Proprietary_ID into one classifying ID in other areas of the schemas. This will get us again closer to the Semantic Model and the capabilities schema, which was developed by some people around Bob Taylor and is under discussion for a while. Try it out. You may check the data types schema first (study the font related types). Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/987cd00e/attachment.html From norbertschade at attbi.com Tue Jun 10 22:22:24 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> font handling review Message-ID: <001d01c32fc0$4be2ffe0$a8948018@ne1.client2.attbi.com> I have almost finished an effort I was shy off for some time: the review of the font handling. I collected the input of the last year and have spent some serious time with it. The ftp site (0.86 directory) is updated. I have to do some finishing touches with the DeviceFont attributes and in the area of modifying attributes. But that's minor now and may be done by tomorrow. Main efforts: - review of most data types. Before everything was a string, which allowed for too many mistakes. Now I think it guides a developer much better. - I edited the corresponding sample description as well. The two fonts still have some arbitrary settings, but now it's quite realistic and based on the new data types. - I renamed some elements and attributes to get closer to the Semantic Model syntax. - I reviewed the modifying attributes section. - I updated the complete font section in the specification documentation (almost finished). This is now much more informative! And properly formatted, too. We are waiting for some input on NameIDs from AGFA to provide at least some popular font names. I'll implement it as we get them. Get back to me, if you still miss something. Or have other feedback. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/619dd57f/attachment.html From norbertschade at attbi.com Wed Jun 11 14:46:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> review of font section Message-ID: <001301c33049$cc90e6a0$a8948018@ne1.client2.attbi.com> Task finished on the level I had in mind. All files updated on the ftp site (check the 0.86 directory). The spec is updated as well. Right now it's only a WinWord file in the 0.86 directory, but later today it will be the usual pdf file in the www/updf directory. Some details: - I changed two parameters in the data types: AtStartOf -> OnStart, AtEndOf -> OnEnd to follow usual patterns. - Today I mainly worked on the modifying attributes, created some command sequences for a font selection and an underline attribute to fill that part with a bit of life. Let me know, if you have any questions. The next two days I'll prepare and hold a UPDF presentation. After that I'll be back and review the well known values for the other features and continue coordinating our schemas with the Semantic Model and Bob's capabilities schemas. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030611/2b6cb02c/attachment.html From norbertschade at attbi.com Tue Jun 17 10:24:42 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:01 2009 Subject: UPD> update of updf site Message-ID: <000801c334dc$31ceed00$f5d12218@ne1.client2.attbi.com> I've updated the public UPDF site with the files of version 0.86. All links refer to this version now. The four dummy bitmaps representing the current dialogs are in the Current_Version directory. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030617/afefd51c/attachment.html From harryl at us.ibm.com Tue Jan 21 18:49:58 2003 From: harryl at us.ibm.com (Harry Lewis) Date: Wed May 6 14:05:17 2009 Subject: UPD> D.C. meeting Message-ID: Need to decide if UPDF will meet in D.C. Mar 31 week. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030121/a8d03f02/attachment-0001.html From NorbertSchade at oaktech.com Tue Feb 11 18:38:03 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> work for version 0.85 Message-ID: This lays out the work for the next weeks: 1. Further changes related to the use of namespaces. This is more work than we originally thought. I have created a 0.85 directory out on the ftp site (ftp.pwg.org/pub/pwg/upd/0.85), which will hold the current version of this work. We don't want to confuse the 'official' version out on the ftp site so that people can continue to use it. I'll let you know about the progress. 2. Incorporation of the semantic model schemas. We have started that already and will increase that effort. This includes the proper use of patterns. 3. Incorporation of the PSI capabilities schemas. We have started that already and will increase that effort. 4. Detailed attributes for font handling. So far many constrainsts don't exist. One can simply enter any string for many font attributes. We want to provide a bit more guidance. That will keep us busy before D.C. Regards Norbert Schade From norbertschade at attbi.com Thu Feb 13 08:35:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> 0.85, namespaces: Locale schema Message-ID: <002701c2d364$cdb3d3e0$a8948018@ne1.client2.attbi.com> I updated the locale schema on the ftp site. Details: - removed the user interface section. - changed all elements to complex types. - to do: we are still working with Predefined_ID, Proprietary_ID instead of a union. this is the next step. I assume some people would like a pattern for free entries (previously Proprietary_ID). If somebody is fast with those declarations, please jump in. - to discuss: watching other schemas in PWG I see that attribute and element declarations seem to be located in different schemas. We have the attributes in "UPDF Data Types.xsd" so far and I left the element declarations (the complex types) in the locale schema. questionable, if we want to source these out. Wouldn't be a big job. And wouldn't change anything for the developer creating the device descriptions (s/he wouldn't even notice). Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030213/33c97e21/attachment-0001.html From NorbertSchade at oaktech.com Wed Feb 19 18:16:59 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> 0.85, UPDF main schema Message-ID: I copied the master schema UPDF.xsd together with the updated 'UPDF Data Types.xsd' schema to the ftp site, subdir 0.85. The complete schema has been changed so that it follows the complextype declarations like the locale schema, which I changed previously. All required namespaces are imported/included including the PWG schemas and the capability schemas except the font handling schema, which I had to take out temporarily. That leaves the font handling schema for the namespace task and we are done with those changes. Then I'll add it back as an include in the UPDF schema. Feel free to check it out. I'll let you know. Norbert Schade From NorbertSchade at oaktech.com Wed Feb 26 10:04:57 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> 0.85: namespace work Message-ID: I finished the bulk of the editing necessary to incorporate namespaces and element definitions as complex types instead of references into all UPDF schemas. I uploaded the following schemas to the UPDF site (ftp://ftp.pwg.org/pub/pwg/upd/0.85): - UPDF - UPDF Font Handling - UPDF Device Configuration - UPDF Option Configuration - UPDF User Policy - UPDF Command Sequences - UPDF Wildcards I have not changed the wildcard schema so far. But that's a short and easy one. We should discuss what namespace this should belong to. I'd like to discuss if we follow the MediaElements/MediaWellKnownValues idea and mainly group the attribute listings in one schema like UPDFWellKnownValues (previously UPDF Data Types) and global elements in another like UPDFElements. This is now possible more easily after the editing I did. Take a look and let me know. Regards Norbert Schade From norbertschade at attbi.com Fri Feb 28 09:29:53 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> positioning Message-ID: <001101c2df35$dc6baca0$a8948018@ne1.client2.attbi.com> Skipped content of type multipart/alternative-------------- next part -------------- // list of DRV_ keys // these keys have to be replaced with the proper values by the driver/client DRV_HorPos DRV_VertPos DRV_PageWidth DRV_PageLength DRV_RasterWidth DRV_RasterHeight DRV_NumberOfRasterImageBytes DRV_FontHeight // in hundredth of pt, where 72pt = 1inch // list of special entries for attributes without a dedicated constraint list select-first // select the first entry in the list available under the current dependencies From sommer at granitesystems.com Fri Feb 28 13:57:13 2003 From: sommer at granitesystems.com (Jim Sommer) Date: Wed May 6 14:05:17 2009 Subject: UPD> positioning In-Reply-To: <001101c2df35$dc6baca0$a8948018@ne1.client2.attbi.com> Message-ID: <5.2.0.9.2.20030228135430.00b3c328@incoming.verizon.net> I vote for positioning by dots in the current resolution. I vote for the origin to be in the upper left corner. I vote for adding the media size dimensions to the predefined variables. At 2/28/2003 09:29 AM, Norbert Schade wrote: >We have two predefined variables so far: DRV_HorPos and DRV_VertPos. >To further clarify the expected behavior, we have to specify details about >the resolution the driver is supposed to feed these variables in. >We basically have two choices: virtual units or current resolution. Both >have some plus and minus. I put that on vote. Default is current >resolution set by raster resolution. >Another item to be resolved is the specification of the origin and >therefore reference point for the positioning. >Two choices again: upper left (e.g. like Windows) or lower left (like >PostScript). I put that on vote too. Default is upper left. > >Whatever the decision is I think some people will need two more predefined >variables: DRV_PageWidth and DRV_PageLength. The driver will have to >provide these in the same units as DRV_HorPos/DRV_VertPos. >I will add them to DRV_keys.txt. Please indicate agreement. > >I will close the vote on March, 7th (next Friday). >Please vote and comment. Any other requirements in this area? > >Regards >Norbert > >Norbert Schade >69 Prescott Drive >North Chelmsford, MA 01863 >978-251-1017 >norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030228/036bb4c3/attachment-0001.html From norbertschade at attbi.com Sun Mar 2 14:44:16 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> How the create a print file: command sequences and events Message-ID: <000a01c2e0f4$202c2040$a8948018@ne1.client2.attbi.com> Haven't written that up this way. As David and Bob asked similar questions from different angles I thought this might be a good opportunity. How to define a print file The request to be able to provide parameters for features to be used in print files evolved into support of command sequences and events over time. Binary terms had to be supported as well as plain text. It was required to specify where in the print file a certain command sequence should appear. Later another decision was made: The real command sequences as used in PDL and probably job language was separated from the higher level device description, which is supposed to be more human readable. Therefore we created a separate schema for command sequences so that PDL experts could convert one PDL specification to another while keeping the device description almost aside. We did not want to work with gigantic switch definitions. So we attached parameter references to the features. To be able to do all this in XML we needed a tool we call Parameter Converter. This allows for the definition of binary terms in ASCII, references to keywords and attributes as well as simpel IF/ELSE statements. A high level description of the envisioned process may look like the following: 1. The driver holds a structure with the non-ambiguous setting of each attribute (means feature in many cases), but is prepared being overruled by the user's application. 2. The driver holds a structure with the non-ambiguous setting of all DRV_ keys. 3. Prepare a Parameter Converter function. 4. Any UPDF core driver is expected to understand all possible events, on start as well as on end of it. 5. When an event occurs for the driver, it checks the event list in the device description and checks all event records with that specific event. It may well find more than one record. They should be listed nicely, but I wouldn't rely on that. The order of records for the same event determine the order of command seqences. 6. For all records of this event: Feed the Parameter Converter with the command sequence of the corresponding XML file identified by the command sequence reference in the event. The other two parameter for the function are the pointer to the two structures of 1. and 2. (that's how I might do, feel free to do it a different way). Within the Parameter Converter 7. The command sequence may show references to unique attributes (dot works as separator, reference to Parameter is wrong as that's an element but no attribute, reference to ID is wrong as that's an attribute but ambiguous, reference to Parameter.ID is better but still ambiguous, reference to MediaSize_Record.Parameter.ID is fine) or DRV_ keys. The ID attribute will show another parameter reference for a special feature setting, which can then be finally resolved in the command sequence XML file (ResolvedParameters section). Check next event and start with 6. until done with all events. Some background info on the Parameter Converter: It started out as reverse Polish notation, but the request was a more human readable syntax. It should understand either ASCII characters or terms of certain syntax. These terms start with a two-byte format string, which tell about the expected output format. IF/ELSE structures are supported, but I wouldn't rely too much on nesting when developing the XML for a device. That's what I think. Did I forget something or wasn't clear enough? Ask in detail! Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030302/90bb211f/attachment-0001.html From norbertschade at attbi.com Mon Mar 3 09:32:27 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> 0.85 update Message-ID: <00b701c2e191$b72a37a0$a8948018@ne1.client2.attbi.com> I have just updated the 0.85 directory. Some changes: - The wildcard sample schema follows the element declaration with complex types. - The Parameter element is global and placed in the data types schema. All other schemas use it. The command sequence schema has a ResolvedParameter element with two attributes ID and Value now not to be ambiguous. - The current capabilities schema you can find on the PWG site is implemented temporarily. I used it for GenericFeatures. This will be our location to try it out the next days. - The sample XML for command sequences is updated as well. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030303/ebaf592b/attachment-0001.html From NorbertSchade at oaktech.com Tue Mar 4 15:24:30 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> update of xml files Message-ID: As the last step of the current changes related to namespaces and element type definitions I updated all sample xml files. Now we have a complete set of schemas and sample xml in the 0.85 directory. Watch that I swichted the GenericFeatures back to the 0.84 definition (I will use that term when I use something from last November) to validate all the sample features. You see that I just comment out one of the lines and use the other one to switch. Makes it easy to switch between GenericFeatures from 0.84 and 0.85. That means now we have a complete set of files on the latest level. Prepared for WellKnownValues from the Semantic Model as well as a serious test of capabilities element types. Feel free to check it out. You'd be prepared for the next tests. Regards Norbert Schade norbertschade@attbi.com From NorbertSchade at oaktech.com Tue Mar 4 18:50:41 2003 From: NorbertSchade at oaktech.com (NorbertSchade@oaktech.com) Date: Wed May 6 14:05:17 2009 Subject: UPD> more accurate font attributes Message-ID: Some days ago I laid out another task, which is strictly device font related. While the overall structure has proven right for a while, we had some items on our to-do list. The most important one was to specify the attribute types more accurately. My proposal: 1. DeviceFont.ID fine as is 2. DeviceFont.Font_Family enum: DONTCARE, ROMAN, SWISS, MODERN, SCRIPT, DECORATIVE 3. DeviceFont.Font_Vendor make mandatory, but leave as string 4. DeviceFont.Encoding make mandatory, stays on to-do list for further details, must be an enum eventually 5. DeviceFont.Passive_Font mandatory, boolean 6. DeviceFont.Parameter fine as is 7. DeviceFont.IFIMETRICS_INFO make all attributes boolean, which is the simplest method. if somebody wants to group some flags, speak now. add TECH_TRUETYPE, TECH_TYPE1, TECH_MM, TECH_CFF. 8. DeviceFont.PseudoDeviceFonts fine as is 9. IFIMETRICS_Selection make all attributes boolean That's it for today. More to come. Please comment by Thursday, 13th. Regards Norbert Schade norbertschade@attbi.com From norbertschade at attbi.com Thu Mar 27 12:28:12 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> Generic UI Message-ID: <00a701c2f486$3e7141c0$a8948018@ne1.client2.attbi.com> Lately there are some further discussions going on how to store data for use to create a proper user interface for a driver/client. I'd like to inform the group about some statements. 1. UPDF We store UI strings in different locales for features and their record (like the 'Media Size:' label and records 'Letter' and 'A4'). We store dependencies including the messages to be shown. Currently we do not save any other UI content. We had some draft construction at some time to learn about requirements, but moved that to a later level of the spec. 2. PSI The PSI group is proposing a different way to store this information in a capabilities schema. This is currently discussed between UPDF and PSI. the ideal outcome would be a common format for the common elements between the two standards. The current proposal includes strings needed for features and dependencies. It shows one additional entry (displayGroup), where somebody can assign a feature to a group. Looks pretty Windows related and is more or less indended to tell, which tab a feature belongs to. 3. Free standards group I'm not too close to the Linux efforts right now, but I know that people are working hard to store all information necessary to handle printing. 4. Foomatic I'm even further away from this group, but I know there are similar efforts going on there too. 5. KDE I've heard this week that these people are working on a generic way to store UI info too. Knowing all this I will gather some info and comment on them today in short statements, all titled 'Generic UI: ...'. Feedback appreciated. I'm happy to send that to another reflector, too, if somebody wants me and tells me how. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/57a34719/attachment-0001.html From norbertschade at attbi.com Thu Mar 27 13:00:06 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> Generic UI, high level architecture of a UI structure Message-ID: <00d301c2f48a$b38fb8c0$a8948018@ne1.client2.attbi.com> Some ideas of mine: 1. complexity specific UI Each description should have at least one totally generic UI - the absolute fallback. this one might be pretty basic. The technical requirements of the display may be very different (e.g. two-line text display, full-screen graphic display, etc.) May result in an attribute for display a UI structure is targetted for. 2. platform specific UI It should be possible to define additional UI structures for special platforms. I don't think it's possible to define something, which can be used under Windows XP and Mac OS-X, not even Mac OS-9 and OS-X. A driver would have to know an awful lot to filter certain features out depending on the actual platforms and as result of that - if possible at all - filtering some parts of the dialog may look pretty orphaned. This might be handled by an attribute Platform with a predefined list of entries (e.g. Generic, Win9X, WinXP, OS9, OSX, KDE, etc.). Fall back to Generic in case there is no structure for the platform the actual driver is working on. Not thoroughly thought of. 3. locale specific UI might be good to have some locale specific structures. just thinking of different strings lengths or right-to-left issues. would result in an attribute Locale with a predefined list of entries. it is my personal belief that the information how a feature should be used in one or more user interfaces should not be stored with that feature. the driver would not expect to read it that way and it would be rather confusing to read and get the picture. Instead I think of multiple UI structures with references to features as needed. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/762cd08a/attachment-0001.html From norbertschade at attbi.com Thu Mar 27 15:30:43 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> Generic UI: grouping and levels Message-ID: <00e801c2f49f$bddf4a60$a8948018@ne1.client2.attbi.com> While some platforms have their own philosophy how to visualize certain controls (what is a tab under Windows, is a panel on the Mac), we may want to stay out of the business of defining each last detail of a UI in a generic description. I'd be mainly interested to group features and nest groups. that might be defined on a quite high level. A dialog must start with a group. A group may have a string reference and must have at least one of feature|group. So UI1 may be something like Group1 Feature1 Feature2 Feature3 Group2 Feature4 This basically leaves it open, if Group2 is shown together with the first three features or if it's realized as a button to call a subdialog with Feature4. An attribute Level could further indicate the intended structure. UI2 Group1 Group2 Feature1 Group3 Feature2 this could be a sample for tabs or panels. An attribute Composition (superimpose/juxtapose) could further indicate the intended structure. So with elements group and feature and attributes FeatureReference to a feature respectively String, Level and Composition to a group you have a nice set of tools to define what your UI shall look like while leaving the final appearance to the driver. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/d484c5d1/attachment-0001.html From norbertschade at attbi.com Thu Mar 27 15:40:54 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: Fw: UPD> Generic UI: grouping and levels, treeview Message-ID: <00f201c2f4a1$29e23dc0$a8948018@ne1.client2.attbi.com> I think a driver might switch to a treeview automatically in case it detects a group with Composition=juxtapose and - depending on the space reverved for that part of the UI - it detects to many controls to show them in parallel. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Thursday, March 27, 2003 3:30 PM Subject: UPD> Generic UI: grouping and levels While some platforms have their own philosophy how to visualize certain controls (what is a tab under Windows, is a panel on the Mac), we may want to stay out of the business of defining each last detail of a UI in a generic description. I'd be mainly interested to group features and nest groups. that might be defined on a quite high level. A dialog must start with a group. A group may have a string reference and must have at least one of feature|group. So UI1 may be something like Group1 Feature1 Feature2 Feature3 Group2 Feature4 This basically leaves it open, if Group2 is shown together with the first three features or if it's realized as a button to call a subdialog with Feature4. An attribute Level could further indicate the intended structure. UI2 Group1 Group2 Feature1 Group3 Feature2 this could be a sample for tabs or panels. An attribute Composition (superimpose/juxtapose) could further indicate the intended structure. So with elements group and feature and attributes FeatureReference to a feature respectively String, Level and Composition to a group you have a nice set of tools to define what your UI shall look like while leaving the final appearance to the driver. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030327/513b2ad6/attachment-0001.html From norbertschade at attbi.com Fri Apr 4 12:08:01 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:17 2009 Subject: UPD> Positioning Message-ID: <001b01c2facc$bfde8960$a8948018@ne1.client2.attbi.com> Just to confirm: We added two variables DRV_PageWidth and DRV_PageLength to the driver variables. The driver is supposed to feed these in the current resolution. When specifying the positioning object, please assume that the origin is the upper left corner of the logical (before N-Up or zooming is resolved) page. The hardware margins are supposed to be part of the positioning values. So it's calculated from the edge, not for the printable area. If you need it for the printable area, you have to subtract something in the record. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030404/7af5dfca/attachment-0001.html From norbertschade at attbi.com Fri Apr 4 12:24:53 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> user interface proposal Message-ID: <002a01c2facf$1d649320$a8948018@ne1.client2.attbi.com> I have put a new UPDF.xsd schema into the 0.85 directory. This one has a proposal for user interface structures. The element is called TBD_UserInterfaces and is assigned to PrintCapabilities. I left out any attribute for a complexity level assuming that a driver can somehow resolve that itself. I left out any attribute to handle locales. So this is the minimal set of elements and attributes I think we'd need for a reasonable approach. 1. You can create as many user interfaces as you like. It is recommended to create at least one, which then is not supposed to have a Platform attribute. If there is no structure at all, the driver might work with a treeview-like UI. If you have more than one structure you may want to create one (generic) with the Platform attribute as a fallback and others, which then are expected to have specific Platform attributes. 2. The main purpose of the user interface structure is to group features and provide a chance to nest groups. That allows a driver to read a very simple structure from top to bottom, identify easily to top entry level, etc. 3. A UIFeature refers to a technical feature (required). 4. A UIGroup can hold a UIFeature or another UIGroup. It may have a display string, but must have a Composition attribute. 4.1. The display string would work as the group title or even as a button text, if the group is realized as a subdialog. 4.2. Composition = juxtaposed means the driver is expected to show the new group within the current group. you may have three features plus two groups on the same level. The driver may check its space conditions and work accordingly. Composition = superimposed means the new group is expected to be shown a level lower. That may result in a new tab, a new panel, a subdialog or whatever the driver decides is reasonable. All other attributes of features may be determined by the driver platform dependent by checking other UPDF attributes or platform settings. Let me know. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030404/756eed78/attachment-0001.html From norbertschade at attbi.com Tue Jun 10 11:42:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> label position Message-ID: <005601c32f66$ee2556e0$a8948018@ne1.client2.attbi.com> > Michael, > I'd like to discuss that one on the reflector. > > Michael's statement: > > - In the first tab, labels are above the control widget, on the second > tab, > > labels are on the left. Is this left to the implementation? (Note that > > from a UI point of view, it's quite hard to guess the best label > > position that fits the human eye). > > Expected comment and good point. > Yes, this is left to the implementation in the current design. > I understand your concerns. > This issue is at the border of the design. Once we dive into this, we'll be > seeing other valid requirements. And my personal judgement is that this is > likely platform specific and rather subjective, too. > If it were my driver, I'd precalculate the whole user interface during > installation of the driver and create something like a preprocessed > structure (BTW: I'd do that with the whole device description). > > My default arrangement would be 'label left of control'. While interpreting > the UI structure I'll do some calculations. I'd have some ideas of a minimum > width for certain controls and labels. Additionally I'd have some idea about > my maximum UI. If I'd blow it up during my preprocessing, I'd have to start > all over again with a fallback. The first fallback may be to arrange labels > at top of control. > So my personal driver may never show a label top of control without a space > problem popping up. > > Conclusion: > Valid comment, but conscious limitation of current design. > Other people to second either side of the statement??? > > Regards > Norbert > > Norbert Schade > 69 Prescott Drive > North Chelmsford, MA 01863 > 978-251-1017 > norbertschade@attbi.com > From norbertschade at attbi.com Tue Jun 10 11:48:43 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> Fw: User Interface sample Message-ID: <007d01c32f67$c5ebae80$a8948018@ne1.client2.attbi.com> I've noticed that this one didn't make it to the reflector last week. So I'm trying again. BTW: This time I leave the bitmaps out and copy them manually to the ftp site in some minutes. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Cc: Michael Goffioul Sent: Sunday, June 08, 2003 9:12 PM Subject: User Interface sample I played around over the weekend to get used to it and find out, if I missed some important pieces. At least it works for me. Please go and check: ftp://ftp.pwg.org/upd/0.86/ There are two samples I practiced with: IndependentUISample.xml, which shows a sample, which has nothing to do with drivers or UPDF other than using the structure. I just played around. you may compare to the bitmaps I set myself as a target (see attached). The other sample is DependentUISample.xml, which uses real references to UPDF features of the same description. The user interface is still pretty dumb, but good enough for a glance. Same issues: I was thinking, if I could live without a 'page-based' composition and somehow extract that information from a special superimposed UIGroup, but I didn't get it so far. So it stays in. I didn't think too much about groups without a title so far. While an ID of a UIGroup necessarily contains a string reference (typically resolved in a locale), an ID of a UIFeature must contain a reference to a technical feature. Agreed? I am not specifying anything about justification or if the label of a control should appear left or above the control. I leave all that to the implementation and their automatic routines. Have fun. Questions? Norbert p.s.: I'm working in other sections. so these files are by no means final. Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/01128457/attachment-0001.html From norbertschade at attbi.com Tue Jun 10 11:50:15 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> Fw: user interfaces Message-ID: <008801c32f67$fc76ffe0$a8948018@ne1.client2.attbi.com> Noticed that this one didn't make it either. Next attempt. BTW: By now I copied most of the files to a 0.86 directory on the ftp site. Norbert ----- Original Message ----- From: Norbert Schade To: UPD group Sent: Thursday, June 05, 2003 9:29 PM Subject: user interfaces I reviewed the user interface section. Find attached the schemas and the spec (Word format for now). Search for 'UserInterfaces' and you can go from there. I didn't copy it to the ftp site yet, as I'm still working on some other stuff. you will see the full set of files there soon. Some details: - I added an attribute to determine the position of a UI control within a group. The attribute has a pattern as a data type to prevent developers from making mistakes. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/13d21fe3/attachment-0001.html From norbertschade at attbi.com Tue Jun 10 12:01:46 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> Re: User Interface sample References: <000b01c32e24$48747d40$a8948018@ne1.client2.attbi.com> <3EE58B5B.E1707E32@imec.be> Message-ID: <009d01c32f69$98dd0900$a8948018@ne1.client2.attbi.com> Michael, I'll take this to the reflector as well, as it looks interesting for the group. Michael's statement: > - I agree that a UIFeature should always be bound to a technical feature. > But if we ever want to extend the spec for some other UI enhancements > (for example: a line separator), this is not true anymore. Or you use > another tag name for any potential UI enhancement Excellent point. I have no problem agreeing that I stopped at a certain point with the current design. Thoughts I had, but haven't realized so far: 1. We could include the user interface structures from a separate schema, which more easily allows other developers to use it for implementations, which do not even have anything to do with UPDF at all. Is that a common request? With that in mind a statement that a UIFeature must refer to a technical UPDF feature has come to nothing anyhow. 2. We could carefully (very carefully and not easily) add wildcards at certain points of the user interface section. That would allow other developers to extend it to their needs. Proposals? A problem to consider: A UPDF implementation should always at least "work" without these UI wildcards. Other feedback to this point? Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com From norbertschade at attbi.com Tue Jun 10 12:50:46 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> update of 0.86 Message-ID: <00c601c32f70$70c04fc0$a8948018@ne1.client2.attbi.com> I updated the 0.86 directory on the ftp site (ftp://ftp.pwg.org/pub/pwg/upd/0.86/). items: - removed DependentUISample.xml. is implemented in the normal sample device description now. - added the simple bitmap files for the UI mockup. - added the specification document (not yet in PDF format), which I'm working on heavily to provide the current level. I'll finish the current level end of this week. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/e74f8beb/attachment-0001.html From norbertschade at attbi.com Tue Jun 10 22:12:35 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> editable combo boxes and input patterns Message-ID: <001401c32fbe$eccdae20$a8948018@ne1.client2.attbi.com> We have been looking for a way to propose predefined values to a device description developer, but allow him/her to still overwrite them. By using memberTypes in a union this is possible. XML Spy supports that functionality properly. Try it out with the latest schemas, which I have updated a minute ago. You may check the FaceName element of the device font section as a sample. You can see three predefined typeface names, but you can enter your own one. That was the intended behavior. By following that syntax we get closer to the Semantic Model, too. Another goal of ours. Another detail of the syntax we use lately is patterns to help the developer entering the proper values when they are proprietary up to some degree. We praticed this syntax within the font handling first. That is now almost finished. This will help us merging the Predefined_ID and Proprietary_ID into one classifying ID in other areas of the schemas. This will get us again closer to the Semantic Model and the capabilities schema, which was developed by some people around Bob Taylor and is under discussion for a while. Try it out. You may check the data types schema first (study the font related types). Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/987cd00e/attachment-0001.html From norbertschade at attbi.com Tue Jun 10 22:22:24 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> font handling review Message-ID: <001d01c32fc0$4be2ffe0$a8948018@ne1.client2.attbi.com> I have almost finished an effort I was shy off for some time: the review of the font handling. I collected the input of the last year and have spent some serious time with it. The ftp site (0.86 directory) is updated. I have to do some finishing touches with the DeviceFont attributes and in the area of modifying attributes. But that's minor now and may be done by tomorrow. Main efforts: - review of most data types. Before everything was a string, which allowed for too many mistakes. Now I think it guides a developer much better. - I edited the corresponding sample description as well. The two fonts still have some arbitrary settings, but now it's quite realistic and based on the new data types. - I renamed some elements and attributes to get closer to the Semantic Model syntax. - I reviewed the modifying attributes section. - I updated the complete font section in the specification documentation (almost finished). This is now much more informative! And properly formatted, too. We are waiting for some input on NameIDs from AGFA to provide at least some popular font names. I'll implement it as we get them. Get back to me, if you still miss something. Or have other feedback. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030610/619dd57f/attachment-0001.html From norbertschade at attbi.com Wed Jun 11 14:46:41 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> review of font section Message-ID: <001301c33049$cc90e6a0$a8948018@ne1.client2.attbi.com> Task finished on the level I had in mind. All files updated on the ftp site (check the 0.86 directory). The spec is updated as well. Right now it's only a WinWord file in the 0.86 directory, but later today it will be the usual pdf file in the www/updf directory. Some details: - I changed two parameters in the data types: AtStartOf -> OnStart, AtEndOf -> OnEnd to follow usual patterns. - Today I mainly worked on the modifying attributes, created some command sequences for a font selection and an underline attribute to fill that part with a bit of life. Let me know, if you have any questions. The next two days I'll prepare and hold a UPDF presentation. After that I'll be back and review the well known values for the other features and continue coordinating our schemas with the Semantic Model and Bob's capabilities schemas. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030611/2b6cb02c/attachment-0001.html From norbertschade at attbi.com Tue Jun 17 10:24:42 2003 From: norbertschade at attbi.com (Norbert Schade) Date: Wed May 6 14:05:18 2009 Subject: UPD> update of updf site Message-ID: <000801c334dc$31ceed00$f5d12218@ne1.client2.attbi.com> I've updated the public UPDF site with the files of version 0.86. All links refer to this version now. The four dummy bitmaps representing the current dialogs are in the Current_Version directory. Regards Norbert Norbert Schade 69 Prescott Drive North Chelmsford, MA 01863 978-251-1017 norbertschade@attbi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.pwg.org/archives/upd/attachments/20030617/afefd51c/attachment-0001.html