[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: font mapping (continued)
[...3rd of two...] Having looked in previous messages at some of the technical issues around the font-sub file ... I actually don't have a real strong opinion about including it or not, provided that 1.) it is targeted at the valid use case, and 2.) is principally understood as a viewer-time standard syntax for Boeing-like users to unify their handling of numerous viewers that support equivalent functionality. Since some users and vendors seem to really want it, I'm inclined to "okay". A couple more comments are embedded... At 04:18 PM 4/9/2008 -0600, Robert Orosz wrote: >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. I don't like this either. At one time we were talking about unifying it with XCF (incl. having some inclusion-by-reference syntax). >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. True enough, and I think a lot more could be done with Font Properties. But I see some problems: 1.) I suspect that useful implementation of Font Properties is rare in viewers (shall we poll it? test it?); 2.) it is a collection of generator-time, generic substitution guidance to the viewer -- there is no way to force a specific substitution. All for now, -Lofton. >-----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 > >--------------------------------------------------------------------- >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]