[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.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]