Here is a summary of last Friday's telecon.
1. People still have problems understanding the inclusion of a child dtd file in a parent dtd file.
The necessary syntax is a 3-step mechanism.
First you have to tell the child's dtd file path and name in the parent and connect the top element of the child with that file.
Next you have to refer to the top element of the child in an element description of the parent.
Third you have to call the top element of the child as the substitute for the element's description in the parent.
We want to use the same entity dtd file over and over to avoid adding them to all dtd files.
As an entity dtd typically does not have a top element with a subsequent tree structure (entities are just lists), I had to invent a dummy element for the connection: OptionalDummyElementForExternalEntities.
This dummy element has no semantic meaning in a device description. So I made it optional and do not add it to any XML.
You will find this dummy element mentioned these three times almost at the beginning of every parent dtd that needs the entities included like the master dtd 'UPDF.dtd'.
Child dtd files must not have the entities included again. There is nothing like in 'C' language: if included already, ignore.
Tha'ts why a dtd like 'UPDF PrintMediaHandling.dtd' must not include the entities itself, when it is part of the whole system. Otherwise the XML editor would complain.
But when you want to edit the 'UPDF PrintMediaHandling.dtd' with your dtd editor, it does not recognize that it is part of a larger tree and will not find the reference to the entities in the parent 'UPDF.dtd'. All the references to entities would cause errors.
That's why you temporarily have to add/remove the references to entities in dtd files depending on what you want to do: edit a dtd or a XML file.
In the meantime I do that blindly and tons of times per day, when I work on that stuff. So it can happen that some dtd file like 'UPDF PrintMediaHandling.dtd' I sent around after having edited is saved for dtd editing or XML editing.
Do the three step change to switch to the other mode.
We have to get more familiar with our dtd and XML editors and used to do simple changes like this more or less automatically.
2. We have implemented the global media handling spec into UPDF and talked about advantages and disadvantages.
This will be a separate email later today sent to the IPP group.
Here is the short version:
The spec is fully implented. Basically it works and we will stay with it.
Typical problems known within driver development are that keywords are saved in application files as well as in driver files. One unit system for media sizes would make it way easier for drivers to convert between two different workstations. A driver could solve that by providing search routines, but this is extra work and slows down performance.
mm/10 is causing rounding errors in a number of cases. mm/1000 as the only global unit would solve that. Like in PostScript a driver could work with a rounding range, but this is extra work and we'd like more precision.
There are more media type keywords used nowadays than the media type list provides so far. IBM's list has a number of keywords commonly used within drivers nowadays.
It is not apparent, why a small number of media colors are predefined with a name instead of using triples like 255-255-0 to define yellow. For us it would be sufficient to define the syntax for these triples. If there are popular triples, ok. Let's predefine them and describe them with a name like in media type:
media type keyword: stationery
media type description: Separately cut sheets of an opaque material
proposed media color keyword: 255-255-0
media color description: The specified media should be yellow
A driver may be very interested in the RGB values.
We need more global lists of media keywords in the UPDF descriptions like for media sources, destinations, etc. We are providing that with our own standard so far.
3. Global list of locales
We are in the process of finishing our entity for locales.
There is some effort going on to coordinate a Linux list with our list. This is one of our goals.
We will support the definition of proprietary locales (on special request). Driver developers should be aware that those locales may not be used in all platforms.
4. We talked about print media handling in general and how much it is completed within UPDF.
There is an infinite number of details, which I cannot cover here.
I need written feedback coming in so that nothing gets lost.
Check out today's version of print media handling.
We agreed not to work with generic features with print media handling.
The documentation is becoming an increasing problem. I didn't find time so far to write even a short documentation on print media handling.
Regards
Norbert Schade
Principle Software Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 10:43:26 EDT