RE: [cgmo-webcgm] Updated DTD and sample instance

["Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>]

David,

Re 1)
Nobody denies font mapping or objects to it as far as I can see.

Re 2)
>2) The question of whether we should have a standardized syntax for font mapping.

>This seems to be where the big disconnect is.

Right.

>The new configurable items chapter describes a standard method of doing the font mapping. 

>There are two methods for associating this config file with a WebCGM instance 1) via the

>fragment syntax (ref 3.1.1.2); and 2) using a Processing Instruction (PI) in the XCF file (ref 4.1, Scenario 4).

I am strongly opposed to any fragment change of this kind, as well as the inclusion of the PI in the XCF. This raises the parsing and processing complexity in a serious way.

Not only it would be required for an application to be prepared for all variations of simple or combined fragments (xcf plus aci), there is also a significant difference in processing.

Some of the scenarios an application must prepare for:

 

(BTW, why can an aci only be combined with an xcf? This means that aci files can not be used if any other form of fragment is needed)

 

Case 1: #fragment without aci and xcf

normal processing as we did so far, i.e. first load the CGM, then parse the fragment and execute

 

Case 2: #fragment with aci, without xcf

significant change: we have a pre-loading step now with the aci, then load the CGM, then apply the aci stuff

 

Case 3: #fragment without aci, with xcf

significant change: we now have to preload the xcf to find out whether there is an aci referenced from within the xcf, then load the CGM, then apply the aci, then apply the rest of the xcf. Sounds difficult? Not yet...

 

Case 4: #fragment with aci and xcf

significant change, even more complex. Now we have a pre-loading step AND a post-loading step.

And more than that: we have to pre-load the aci and apply it, then we have to pre-load the xcf, look for an aci reference (where is defined which one prevails?) then apply the aci, then load the CGM, then apply the XCF

 

Now all fragment parsing happens AFTER the CGM has been loaded. Please remember: we need the BHO to retrieve the fragment AFTER we have the CGM, we don't even _see_ the fragment before we go to the BHO.

 

More questions:

What happens with an aci reference that sits in an XCF that is applied _after_ the CGM has been loaded?

What happens with an aci fragment that is used after the CGM has been loaded?

An XCF is not file-specific, so the aci isnt' either?

 

I personally dislike the combination of defaultStyleProp and font substitution in one file. I can see the importance of defaultStyleProp, however, this is hardly a feature that would be used on a per file base, most people would want to set these values once and never change them again.

 

 

>As I've said before, the major use case is interoperability.  Rather than carrying around 4 difference font mapping files

>(with 4 difference syntaxes), I would rather only have to work with one mapping file.

This means that you did the work already, and that no further work is needed on your side.

In the future you wouldn't be able to work with one single mapping file either, because you have no idea which font is installed on the target computer, and which platform it runs on. So you may end up shipping one mapping for UNIX, one for Windows.

>The second use case that I've seen is a desire to have mulitple font mapping files in the context of a compound document.  We have mulitple illustration creation systems and they don't always match exactly.  We have found it necessary to map fonts differently between our maintenance illustrations and our wiring diagrams in our compound document presentation product to make the display readable.  It's an ugly process doing that kind of thing via scripting and renaming files in the background.

 

Understood and appreciated. All your use cases are very valid use cases, however, the current proposal

- will not fix these problems

- will introduce extreme parsing complexity

- will not work for any URL that needs a fragment other than xcf and aci

- will create a substantial workload for all vendors for close to zero mileage.

 

My suggestion:

let's standardize on a format for a font mapping file that gets sent to the end computer separately, and that will be maintained as needed on that target computer. That way you can send out a single file, and we can be sure that the end user has a way to adjust it to his needs.

 

Other observations:

In 3.1.1.2:

webcgmfragment ::= picterm "." objterm |
picterm |
objterm |
picid "." objid |
objid |
xcfterm

The term xcfterm is not used. This should be resrcterm (if we would adopt this).

Regards,

Dieter



-----Original Message-----
From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
Sent: Montag, 14. April 2008 22:59
To: Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance

I'm back, sort of....I'm still working from home, but feeling much better....had some combination of a cold and ??

It seems to me on this issue there are two pieces that have arisen.

1) the existence of font mapping

All the vendors seem to do font mapping of some type(and WebCGM Chapter 6 T.26.6 allows it).

WebCGM has a list of recommended fonts:
Times-Roman
Times-Bold
Times-Italic
Times-BoldItalic
Helvetica
Helvetica-Bold
Helvetica-Oblique
Helvetica-BoldOblique
Courier
Courier-Bold
Courier-Oblique
Courier-BoldOblique
Symbol

Almost none of the fonts on my platform match those names exactly:

Times family: 
Times New Roman; Times New Roman Bold; Times New Roman Bold Italic; Times New Roman Italic

Helvetica (swiss) family:
Arial; Arial Black; Arial Black Italic; Arial Bold; Arial Bold Italic; Arial Italic; Arial Narrow; Arial Narrow Bold; Arial Narrow Bold Italic; Arial Narrow Italic; Arial Unicode; Swiss 721 Bold; Swicc 721 Bold Italic; Swizz 721 Bold Outline; Swiss 721; Swiss 721 Light Condensed; Swiss 721 Light Condensed Italic

Courier family:
Courier 10 Pitch Bold; Courier 10 Pitch Bold Italic; Courier 10,12,15; Courier New; Courier New Bold; Courier New Bold Italic; Courier New Italic

Symbol family:
Symbol; Symbol 8,12,12,14,18,24; Symbol Monospaced; Symbol Proportional

I think most of us would agree that the comman mapping here would most likely be:
Times-Roman -> Times New Roman, etc.
Helvetica -> Arial, etc.
Courier -> Courier New, etc.
Symbol -> Symbol

But the existence of font mapping support by the vendors allows me to make substitutions as I desire.

I think we can agree that font mapping exists currently.

2) The question of whether we should have a standardized syntax for font mapping.

This seems to be where the big disconnect is.

The new configurable items chapter describes a standard method of doing the font mapping.  There are two methods for associating this config file with a WebCGM instance 1) via the fragment syntax (ref 3.1.1.2); and 2) using a Processing Instruction (PI) in the XCF file (ref 4.1, Scenario 4).

In the absence of any font mapping information in the application configurable items instance, I'm happy to let the vendors to do mapping as they chose or.  If mapping is unsatisfied, I would expect the vendors to recover however they do now.  If mapping is specified, I would expect it to be honored.

As I've said before, the major use case is interoperability.  Rather than carrying around 4 difference font mapping files (with 4 difference syntaxes), I would rather only have to work with one mapping file.

The second use case that I've seen is a desire to have mulitple font mapping files in the context of a compound document.  We have mulitple illustration creation systems and they don't always match exactly.  We have found it necessary to map fonts differently between our maintenance illustrations and our wiring diagrams in our compound document presentation product to make the display readable.  It's an ugly process doing that kind of thing via scripting and renaming files in the background.

We can carry on this discussion during the telecon on Wednesday, April 16.

I've also seen discussion about embedding fonts into the CGM file like PDF and SVG do.  The question that keeps coming to my mind is that of font copyright and distribution rights?  I haven't seen anyone address that yet?  How does SVG get around it?

Thx...Dave


Technical Fellow - Graphics/Digital Data Interchange Boeing Commercial Airplane 206.544.3560, fax 206.662.3734 david.w.cruikshank@boeing.com

-----Original Message-----
From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Monday, April 14, 2008 6:27 AM
To: CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance

Hi Lofton,

Say I open an Illustrator file (or Word, or just about any format I know) which contains text using 'Denver Colorado' font... I don't have such a font on my system, what happens?

i) I get prompt with a dialog box for me to choose alternate fonts.
ii) Or my text doesn't look right.

CGM is not the only one with this problem, many formats have the same issue. Other formats (PDF, Illustrator, SVG etc...) have chosen font embedding as the solution. But, the working group is not willing to go there.

What would I put into that metafile between Helvetica or Arial? I would put the one that will please most users. Boring answer right... but with what WebCGM has to offer, I have no other choice.

I mean, we're talking about a 'couple of decades' as you say. I was under the impression that CGMs were revised. After 15-20 years, you would think that these files would use FONT PROPERTIES and/or RESTRICTED TEXT.

I hear most viewers offer convenience font mapping methods for these files (which I hope are on the decline). Do we really all have to change our implementation?

No point going on, I'm repeating myself.

Benoit.

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Saturday, April 12, 2008 2:47 PM
To: CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance

[...1st of two...]

Hi Benoit, All --

After reading the whole thread, I'm a little confused about some assertions, and might have missed some peoples' meaning.  Onward ... here are some opinions, taking off from Benoit's first question.

At 09:37 PM 3/24/2008 -0400, Bezaire, Benoit wrote:
>1) I do not understand why you would want to set Helvetica as the font
>and wish for Arial to be used for display? I do not know of any
>technology that has an 'internal font' and a 'desired display font'.

If the metafile might be interpreted on two systems, one of which has Helvetica available, and the other of which has Arial available ... what would you put into the metafile?  Two different metafiles for the different target systems?  (Clearly not.)  So we have to do something else.

We're facing a long legacy (couple of decades) of this CGM/WebCGM
design:  a small core set of fonts is mandated, which are almost universally available in some naming/proprietary variant or another;  and a descriptive method to go outside of this set (Font Properties).

As you have proposed elsewhere, it might be nice if WebCGM had, amongst its features, a font-spec capability similar to SVG and its ilk of standards.  SVG allows a list of priority-ordered fall-backs in the original font request -- including generic specifiers like "sans-serif".  Font Properties meet some of this functionality.  (However, I also see a down side to a mechanism like SVG's, where a font-sub list is essentially specified at generation time.)

My opinion:  it would be too disruptive to redesign WebCGM's font-request method at this point.  We might come up with a clever syntax for "virtual"
or "functional" font names in the FONT LIST element (e.g., each font "name"
is actually a priority-ordered list), but this (again IMO) would be more disruptive to implementations than other things being discussed.

If we don't redesign the font-spec mechanism in WebCGM, then either:

1.) we rely solely on what you can achieve with FONT PROPERTIES at metafile generation time;
2.) or, supplement that with viewer-time font mapping.

While both have some place, there are valid use cases where the former is not possible, and the latter is the only option.  Mainly, legacy metafiles which legally call for Helvetica-Bold, and which were not written with FONT PROPERTIES.  (Which latter, I suspect, is probably not well implemented in any case)

So ... users are going to do #2 (viewer-time font substitution).  The key question is whether we are going to make a standard format/syntax, as requested by users such as Boeing.

-Lofton.

>2) I think the only way this is possible is by embedding the fonts into
>the CGM.
>
>In my opinion, font mapping should be used as a last resort, thus,
>being a viewer feature is sufficient.
>
>Ben
>
>-----Original Message-----
>From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
>Sent: Monday, March 24, 2008 5:33 PM
>To: Weidenbrueck, Dieter; Galt, Stuart A; Bezaire, Benoit; CGM Open
>WebCGM TC
>Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
>
>Dieter,
>
>Ok, lets consider 2 use cases not related to legacy data
>
>1)  I have a compound document with 5000+ WebCGM files and associated
>XCFs (and ACIs).  All of the CGM files call out Helvetica as the font.
>Because of display characteristics I want to ensure that Arial is used
>during presentation, I specify that mapping in the ACI file.  I'm not
>making any assumption about the CGM viewer here because I know they are
>all interoperable.  Am I to assume all WebCGM CGM viewer will
>automatically map Helvetica to Arial?
>
>2)  I have a dream that in the future I will be able to just distribute
>my compound document (from above) and not have to maintain the client
>configuration on the receiver's platform.  Again, it is an
>interoperability issue because I don't want to have to tell my users
>what they have to have on their computers.  I just want the font
>mapping to work with any WebCGM viewer.  If the user wants to remap the
>fonts, he is free to do so without wondering where the font mapping
>file is for a particular product.
>
>Just my thoughts.
>
>dave
>
>
>
>
>
>Technical Fellow - Graphics/Digital Data Interchange Boeing Commercial
>Airplane 206.544.3560, fax 206.662.3734 david.w.cruikshank@boeing.com
>
>-----Original Message-----
>From: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]
>Sent: Monday, March 24, 2008 9:50 AM
>To: Galt, Stuart A; Bezaire, Benoit; CGM Open WebCGM TC
>Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
>
>Stuart,
>
>I understand Benoit's position, and I don't think I am far away from it.
>
>Your CGMs are not compliant with WebCGM to begin with, and I understand
>that you are looking for a solution for your users (which are our users
>as well).
>
>However, let me quote Lofton here:
>"If you look throughout the CGM standard, and the WebCGM profile, it
>(mostly) does not say what a viewer does with invalid input.  It does
>not tell the viewer what to do with an invalid, non-existent linetype,
>for example.  It only defines valid content/input, and what the viewer
>does with valid input.
>
>I'm sure we can find a few exceptions somewhere in WebCGM (e.g., some
>Exception stuff in DOM sections), but that is the overall philosophy
>that has been around ever since CGM:1999 and WebCGM 1.0.  See for
>example
>T.26.8 here:
>
>http://docs.oasis-open.org/webcgm/v2.0/OS/WebCGM20-Profile.html#webcgm_4_15"
>
>So we are working on a standard that
>- defines valid content
>- defines expected behavior for valid content
>
>According to Lofton (and the spec), we do not deal with uncompliant
>content or input, we reject or ignore it.
>
>In a similar way one could say that there are a lot of old files around
>with erroneuous character height statements. IsoView is expected to
>cure this on the fly, i.e. ignore the invalid content detail. So this
>is a courtesy of the viewer vendor, as well as the font mapping is.
>Would we now also want to standardize
>- character height mapping schemes for files with zero character height
>from the early 90s?
>- color mapping tables for Auto-trol files that had inverted colors for
>black and white?
>- APS mapping tables for old ActiveCGM files so that they would work in
>a WebCGM environment?
>
>This list could be endless.
>
>I believe that font mapping is an important feature of a viewer, and
>potentially an editor as well. However, as Benoit has mentioned several
>times, it is a feature, not a part of WebCGM IMO.
>And even if we would standardize font mapping, the current approach is
>underspecified IMO, because everything is CDATA only, and I can't find
>specific rules for font selection for display fonts.
>
>Regards,
>Dieter
>
>
>-----Original Message-----
>From: Galt, Stuart A [mailto:stuart.a.galt@boeing.com]
>Sent: Montag, 24. März 2008 16:50
>To: Bezaire, Benoit; CGM Open WebCGM TC
>Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
>
>Benoit,
>
>It isn't always that easy.  We have several million graphics that have
>been produced over a long period of time that use an abnormal font.
>They were designed when everything was delivered in paper form.
>Our printers had that font and everything was fine.  We now want to
>deliver the graphics digitally and have found some acceptable font
>substitutions that work and make it so that users don't need to figure
>out how to obtain these esoteric fonts.  All of the viewers have a
>configuration file that facilitates this substitution but every one is
>different.
>The goal was to have a standard way of specifying the font substitution.
>
>Stuart.
>
>
>
> > -----Original Message-----
> > From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
> > Sent: Monday, March 24, 2008 7:09 AM
> > To: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > Dave,
> >
> > I simply think that standardizing font mapping in WebCGM to solve
> > the problem is the wrong approach.
> >
> > Why would you put Helvetica in the CGM file if you want Tahoma as
> > the display font?
> >
> > Ben
> >
> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Friday, March 21, 2008 11:59 AM
> > To: Bezaire, Benoit; CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > Ben,
> >
> > My desire for having a standardized font mapping file is really an
> > interoperability issue.  As a company that creates products based on
> > the technology and integrated with html text, My ideal situation
> > would be that I deliver the html and graphics as a package and the
> > end user accesses it with whatever web browser and cgm viewer he desires.
> > Currently we are tied to IE, although both Boeing and Airbus have
> > expressed a desire to be platform/browser independent.
> > Even so, if I (or the user) decides to use a different cgm viewer, I
> > should not have to maintain multiple font mapping files in my
> > distribution of the package.
> >
> > If WebCGM is truly interoperable, it shouldn't make any difference
> > which viewer is installed and the font mapping shouldn't be affected.
> >
> > The viewer vendors may want to distribute, as they do now, a sample
> > config file with what they consider "standard" font mapping for
> > their product, but as data creators, we know what font names are in
> > our cgm files and we know what fonts we want to use for display.  It
> > could turn out in one of our datasets, Tahoma is a better display
> > font than Helvetica and we want that font substitution across all
> > viewers whenever that dataset is displayed.
> >
> > Hopefully, that's a little insight into the requirement.
> >
> > Dave
> >
> >
> > Technical Fellow - Graphics/Digital Data Interchange Boeing
> > Commercial Airplane 206.544.3560, fax 206.662.3734
> > david.w.cruikshank@boeing.com
> >
> > -----Original Message-----
> > From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
> > Sent: Thursday, March 20, 2008 10:11 AM
> > To: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > Thanks for the pointers.
> >
> > I am personally not in favor of this.
> >
> > I think it should remain a user agent feature. An implementer may
> > want to provide a User Interface for resolving font substitution
> > issues (for example).
> >
> > I think the problem of font substitution should be dealt with
> > differently (ex: modifying the profile) instead of standardizing a
> > font mapping file.
> >
> > I also think authors need to be informed about the problem.
> > They should be using fonts that can be found on several platforms.
> > Not relying on optional font substitution mechanisms.
> >
> > I also have a lot of questions about the two elements:
> > <cgmFont> and <displayFont>? About <cgmFont>, where are the font
> > names defined? I see for example: Courier-BoldOblique in the profile.
> >
> > Is there any chance that font name could be?
> > <cgmFont>COURIER_BOLDOBLIQUE</cgmFont>
> > <cgmFont>COURIER BOLD OBLIQUE</cgmFont>
> > <cgmFont>COURIER-BOLD_OBLIQUE</cgmFont>
> > <cgmFont>COURIER   BOLDOBLIQUE</cgmFont>
> >
> > What are the rules?
> >
> > Same thing applies for <displayFont>...
> >
> > Sorry, but I see many headaches for implementers. From a users
> > perspective, they are likely familiar with our preferences file and
> > would probably appreciate status quo.
> >
> > My opinion,
> > Ben
> >
> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Thursday, March 20, 2008 11:02 AM
> > To: Bezaire, Benoit; CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > Actually the WebCGM Profile does address font substitution for
> > interpreters.  See T.26.6.  I agree that implementing a standard
> > font mapping file requires a change to that table with a reference
> > to the new Chapter 9.
> >
> > It also addresses it on the generator side in T.25.4.
> >
> > Dave
> >
> >
> >
> >
> > Technical Fellow - Graphics/Digital Data Interchange Boeing
> > Commercial Airplane 206.544.3560, fax 206.662.3734
> > david.w.cruikshank@boeing.com
> >
> > -----Original Message-----
> > From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
> > Sent: Thursday, March 20, 2008 7:34 AM
> > To: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > Dave, not sure if you have email access by now. I wouldn't mind
> > getting your thoughts on this?
> >
> > -----Original Message-----
> > From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
> > Sent: Wednesday, March 19, 2008 8:53 AM
> > To: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > I was under the impression the spec allowed a font mapping
> > mechanism, but it doesn't. The only thing the spec says is that if
> > the font is not present, the default font should be used.
> >
> > This, to me, is a user agent feature. If it gets standardize, the
> > profile would need to change.
> >
> > I would be in favor (if doable) to change the profile and help the
> > situation by, for example:
> > - allowing a list of font index (instead of one) on text elements,
> > (if the first font is not available, try the following one, and so on).
> > - allowing generic font-families: serif, sans-serif, cursive,
> > fantasy, monospace
> > - modifying the list of allowed fonts in the profile, i.e., select
> > fonts that are available on multiple platforms.
> >
> > Overall, I would try to get rid of the font mapping mechanism
> > instead of standardizing it. Also I wonder if something that has
> > been around for 17 years should be modified. If users are accustomed
> > to the vendors files, why change them and possibly risk new font
> > related issues.
> >
> > Ben
> >
> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Tuesday, March 18, 2008 2:14 PM
> > To: Bezaire, Benoit; CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> >
> >  Every CGM product (viewer and illustrating packages) I've worked
> > with over the last 17 years has a font mapping mechanism.  This was
> > an attempt to standardize that file.
> > Whether my computer (platform independent)has helvetica, arial,
> > swiss, etc., it allows me to control the display font that I want to
> > use from what is called out in the CGM file.
> > The WebCGM Profile calls out the Adobe 13 fonts.  Included in that
> > list is 'Helvetica' (case insensitive).  Helvetica is not a font
> > that Microsoft distributes in windows.  It does distribute Arial.  I
> > do have Helvetica in my unix box, but I also have Swiss on that box.
> > I may want to use it instead.
> >
> > Font mapping has been around for a long time in the CGM community.
> >
> > dave
> >
> >
> > Technical Fellow - Graphics/Digital Data Interchange Boeing
> > Commercial Airplane 206.544.3560, fax 206.662.3734
> > david.w.cruikshank@boeing.com
> >
> > -----Original Message-----
> > From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
> > Sent: Monday, March 17, 2008 1:04 PM
> > To: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
> >
> > I've been thinking about this for a while, and I'm not convinced
> > this will help interoperability. I'm referring mostly to the font
> > mapping section.
> >
> > Are there any restrictions on the content of <cgmFont>?
> > Are there any restrictions on the content of <displayFont>?
> >
> > Are the problems mainly when going from Unix to Windows (and vice
> > versa)?
> > What's a typical (frequent) scenario?
> >
> > Ben
> >
> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Sunday, March 16, 2008 6:23 PM
> > To: CGM Open WebCGM TC
> > Subject: [cgmo-webcgm] Updated DTD and sample instance
> >
> > I found a problem in the WebCGM configuration DTD, fixed it, and
> > created sample instance to demonstrate its usage.
> >
> > The instance is made up using some of the PTC font mapping table and
> > some Boeing settings for the style properties.
> >
> > I have not incorporated scaling of the font glyphs in the x and y
> > direction yet, but will do that at the mapping level.
> >
> > The font mapping was set up only to be used by viewers.  I could
> > extend it to cover both import and export, so it could be applied to
> > illustrating packages (thoughts?)
> >
> > Thx...Dave
> >  <<webcgmConfig.dtd>>  <<myconfig.xml>>
> >
> > Technical Fellow - Graphics/Digital Data Interchange Boeing
> > Commercial Airplane 206.544.3560, fax 206.662.3734
> > david.w.cruikshank@boeing.com
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC
> > that generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>oups.php
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC
> > that generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>oups.php
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC
> > that generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>oups.php
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC
> > that generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>oups.php
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC
> > that generates this mail.  You may a link to this group and all your
> > TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>oups.php
> >
> >
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in
>OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php