[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance
All, We use our non standard font mapping file mostly for working with legacy files and files generated by applications that pay no attention to profiles. I would still like to see a standard method of mapping fonts in a font list to fonts available on the system displaying, editing or converting the CGM. Regards, Forrest -----Original Message----- From: Lofton Henderson [mailto:lofton@rockynet.com] Sent: Tuesday, April 15, 2008 11:32 AM To: Bezaire, Benoit; CGM Open WebCGM TC 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 --------------------------------------------------------------------- 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]