[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
At 11:02 AM 4/15/2008 -0400, Bezaire, Benoit wrote: >I'm not proposing font embedding. It's just an observation. > >I could be in favor of proposing multiple font indexes (as oppose to a >single index) for text elements. If at all doable with the profile? I >think it would be sufficient to fix the Windows/Unix font mapping issues. >Note: this would take care of new files, it doesn't address the legacy >problem. Multiple font indices, in my opinion, would be difficult and would do significant violence to the core principles CGM:1999. If people wanted to go this way (the SVG-like font referencing mechanism), here is how I would define it: Change the rules of the individual FONT LIST entry to accommodate it. So a single FONT LIST entry could be something like a semicolon-separated list: "Helvetica; Arial; Boeings-own; sanSerif". (This is the SVG way.) I am *not* endorsing that at this time. Even though the SVG way has some appealing aspects, on the other hand there are things about it that I dislike (in concept or principle). I think a hasty attempt to layer this on top of the current WebCGM scheme is not wise, and there are significant unanswered questions (e.g., what about FONT PROPERTIES and non-core fonts in the list?) Plus ... it is going to mean a fair amount of new implementation effort. My overview: What I have heard so far is that a couple people dislike standardized font substitution. But a lot of people have been living for a long time (CALS, PIP, ATA, and now the WebCGM profiles) with a small simple core font set, plus FONT PROPERTIES, plus proprietary viewing-time font substitution. If lots of people are unhappy with the combined capabilities for WebCGM (and its ancestor tech-illustration profiles), they have been keeping pretty quiet about it. -Lofton. >-----Original Message----- >From: Lofton Henderson [mailto:lofton@rockynet.com] >Sent: Monday, April 14, 2008 7:26 PM >To: Cruikshank, David W; CGM Open WebCGM TC >Subject: RE: [cgmo-webcgm] Updated DTD and sample instance > >Dave, > >In your message, I agree that: 1.) yes, font mapping is common amongst >CGM products; and 2.) yes, the question is whether WebCGM 2.1 should >define a standard syntax or not. I think you have expressed and >illustrated why Boeing wants it. > >But there is one particular, different point in your message that I want >to ask the TC about: > >At 01:58 PM 4/14/2008 -0700, Cruikshank, David W wrote: > >[...] > > > >I've also seen discussion about embedding fonts into the CGM file like > >PDF and SVG do. > >Is anyone actually proposing this for WebCGM?! Or simply observing that it >is the only rock-solid guaranteed way to get a specific result with >graphic-arts precision? > > >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? > >It (embedded fonts) is a pandora's box. A real quagmire. (Take your pick.) > >Read here for a few minutes to see the scope of it (complex and ugly): >http://www.w3.org/TR/SVG11/fonts.html#Introduction >(which normatively references the equally voluminous: >http://www.w3.org/TR/REC-CSS2/fonts.html#q1 ) > >My opinions: >1.) SVG's font-related requirements far exceed WebCGM's; >2.) WebCGM's requirements would not justify the huge technical (and legal) >investments required by standardized embedded fonts; > >Like all graphics standards, SVG has probably spent more time and energy >on text/font topics than any other single output-graphics topic (maybe >more than all of 'em together!). > >-Lofton. > > > >-----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.ph > > >p > > > > > > > > >--------------------------------------------------------------------- > > >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.ph > > >p > > > > > > > > >--------------------------------------------------------------------- > > >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.ph > > >p > > > > > > > >--------------------------------------------------------------------- > >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]