While discussing device fonts in the sample implementation group, I had to reactivate larger pieces of the font specification anyhow in my mind. Additionally I had to write some notes, how and why fonts are designed the way they are. So I looked at the fonts in detail again.
During that process I am taking the time to add all the notes and all other information about fonts and add it to the 'UPDF Functional Specification'.
I am reviewing the dtd and the documentation and updating it, as the whole UPDF spec has got to a higher level.
I'll keep you informed about the details.
The dtd only changes in very few items, as we considered the design final last summer.
I have converted the element DeviceFont.Encoding to an attribute Encoding of the DeviceFont element.
I have added a Font_CommandSequence_ID attribute to the DeviceFont element and therefore removed the DeviceFont.FontSelection element.
I think we do not need the NameIDOrder element any more. We define that the face name has to be followed by the style and weight name and could be closed by a Character_Set_Name_ID, if available.
I removed the event handlers from the font section, as we have a global event handler section now. Similar entries may appear there again.
I am changing the names of elements and attributes over time to make it more consistent with other parts of the spec.
E.g. I have changed element name 'WidthTable' to 'CharacterList', attribute name 'CommandSequence_ID' to 'Font_CommandSequence_ID', attribute name 'Character_Code' to 'Character_PrintOutput'.
I have added a TransparentCharacter_CommandSequence_ID attribute to the Character element.
The FontReference element has been renamed to FontReferenceList and has FontReference elements by itself now. We want a clear structure. On the level of FontReferenceList we do not want multiple elements. And we need a FontReference_ID attribute, which we have now.
All the latest changes are a preparation for a sample implementation of one or two fonts, just to see whether it's complete and consistent.
Another reason doing this now is to free the whole font specification as much of device implementation issues as possible. This shall ease the work for font developers to create font descriptions in UPDF, which will be a device independent as possible. I assume we have to learn by doing a bit more.
I know very much that I have not edited all of the font handling documentation. But I rather have some documentation for most of the font handling elements and attributes (even if not up-to-date in all cases) than not having documentation at all. You should easily detect, which elements and attributes are up-to-date.
I will continue working on that.
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 : Fri Jul 06 2001 - 17:57:23 EDT