I want to throw in my 2 cents on these.
Item 5 - Parameter Converter and UI Strings
It would make my life easier if we didn't use the parameter converter for
UI strings but I can see the usefulness of this function. If we do allow
it, I think the place for it is in the Name_ID and not the string itself.
My main reason it that this keeps our locale files clean for easy
translation which was the whole point of moving the UI strings to separate
files in the first place
Item 11 - IDs
Though I appreciate the concept behind making the classifying attributes
unique, I think it creates two problems.
1) The UPDF becomes less readable. For instance, media sizes and margins
would be separate items and you'd have to go to a third place to find how
they are related.
2) Composite Features or Interdependencies would be required to do just a
simple printer description. These are powerful and very useful features
and, I imagine, every printer description will use at least one of them.
However, in the course of creating a printer description or driver, it will
be much easier to do the device description first and verify it. After that
is complete, the user interface (composite features and interdependencies)
can be considered. By separating margins from media sizes, they must be
connected by either a composite feature or interdependencies. So, just to
get something to print correctly, these functions would have to be
implemented. Also, since either function could be used, there would be no
common method of relating media size with margins.
I think we'd create more problems than we'd fix by eliminating the unique IDs.
Jim
mailto:sommer at granitesystems.com
978-486-3068