[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: font mapping (continued)
I'm pretty much in agreement with Dieter (and Benoit) here. As Benoit pointed earlier and Dieter reiterates here, the only way to guarantee usage of a particular font on the target system is to embed that font into the CGM. The CGM standard currently does not have a mechanism for doing this. I have a couple of things to add to what has already been said. 1) Users might not react favorably if they have to maintain two companion files (normal XCF plus font mapping) for each CGM. 2) Dieter states below: "... or we should specify rules how a viewer should be looking for a similar font on the target computer." The Font Properties element is intended for this exact purpose; i.e. it lets the CGM creator specify to the viewer how it should be looking for a substitute font. Each property has a priority value attached to it which specifies the weight to give to that particular property when evaluating the suitability of an alternate font. Rob -----Original Message----- From: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com] Sent: Wednesday, April 09, 2008 3:34 PM To: Don; david.w.cruikshank@boeing.com; CGM Open WebCGM TC Subject: RE: [cgmo-webcgm] ISSUE: font mapping (continued) Don and all, The more we get into this discussion, the less I understand what it really is that we want to standardize. Let's recap: - we have a standardized and unambiguous way to specify fonts inside a WebCGM file - we recognize that such a font needs to be specified by the creator of the file, who has no idea about the actual font installation on any target computer - current viewer implementations provide font mapping on the client side, i.e. where the font installation of the target computer is known. Now the suggestion is to prepare a font mapping file on the creator side (which still has no clue which fonts will be installed on the target systems, and how much this varies from computer to computer), and to send this out with the WebCGM file. More than that, the proposal below suggests recovery methods for mistyped fonts in the font mapping file. So we are talking about a recovery method for a recovery method for a standardized font mechanism inside WebCGM. My position is: - font mapping can only happen reliably on the target computer itself, because this is the only place where the fonts are known that could be used for substitution purposes. - as Lofton pointed out wrt other things, we are defining how things SHOULD be done, not the recovery methods for files that are not compliant to the spec. - if flexibility is needed on the font side, we should specify alternatives inside the WebCGM file, similar to SVG, or we should specify rules how a viewer should be looking for a similar font on the target computer Font mapping should remain a viewer feature, as much as the excellent recovery methods that Don described below. We have dozends of such workarounds in our code to deal with lots of buggy files from the past. Regards, Dieter -----Original Message----- From: Don [mailto:dlarson@cgmlarson.com] Sent: Mittwoch, 9. April 2008 17:12 To: david.w.cruikshank@boeing.com; CGM Open WebCGM TC Subject: re: [cgmo-webcgm] ISSUE: font mapping (continued) dave Here's my thoughts on font substitution issue. I think that we need standard (viewer independent way) to do font substitution in the viewer for all the reasons you have mentioned. I do think though, that variances in font names like whitespaces, hyphens and upper/lower case will cause a matching problem as Benoit suggested, e.g. Courier-BoldOblique Courier BoldOblique CourierBoldOblique My thinking is that we need to further specify that when the viewer is trying to match fonts in CGM for substitution, it should ignore whitespace, hyphens, and convert to lower case in the font names. We do this now in our font substitution algorithm and it has worked well for us. Regards, Don > There was a long thread (primarily between PTC and Boeing) concerning > the font mapping requirement. > See: > http://lists.oasis-open.org/archives/cgmo-webcgm/200803/msg00111.html > It's time to get other's opinions. Please review the thread and reply > with you're thoughts (vendors?, users?) > My position is that when the font in the CGM file is not a match to a > font on the user platform, I want a "standard" method to specify which > font to substitute.. > Thx...Dave > 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_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]