[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: font mapping (continued)
[...2nd of two...] Again, I'm a little confused about some assertions, and might have missed some peoples' meaning... At 05:34 PM 4/9/2008 -0400, Weidenbrueck, Dieter wrote: >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. Hmmm. That is not how I have been understanding the user arguments such as Boeing's. I thought that the font-sub file would be prepared on the user/viewer end, based on the fonts that are requested in the WebCGM file and the fonts that are available on the local display system(s). Not at metafile-generation time. Have I missed or misunderstood something in the thread? Clarification: When I read "viewer-independent way to do font-sub", I understand it to mean a standardized syntax to submit to viewers. I do not understand it to mean a generator-time specification of font substitution that is to happen on any and every destination platform/viewer. Scenario: So Dave is using viewers from XYZ Corp and Bogus Software Inc. The fonts in his 5000 metafiles are Helvetica. It is available on his unix box, but not on his Windows systems, where Arial is available and the two viewers are installed. He can then hand the same font-sub file to the viewers of XYZ and Bogus on his Windows boxes. (I realize that one can push the scenario to the limits, and postulate "what if he specifies a font-sub that one of the viewers doesn't support?" Could happen, and if we pursue font-sub, we should say what is expected if a resource is lacking. But I think it would be a fringe case, if I understand Dave's scenario correctly.) >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. For the record, as I said earlier, I do not support this as a use case to justify the feature. IMO, correction of erroneous input should be out-of-scope. >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 The latter is something that we *could* do. I tend to think it would be pretty disruptive at this stage to invent "virtual font names", with an embedded priority-ordered fallback (substitution) list. Also -- except for generics like "serif", I question the wisdom of generator-time embedding of font-substitution into the metafile. (SVG, for example, would allow a font something like this for the font request, at metafile-generation time: "Helvetica, Arial, Boeings-own-Arial-like-font, sansSerif" >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. Again, I'm not reading the valid use case as "buggy" files. -Lofton. >-----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]