RE: [cgmo-webcgm] ISSUE: font mapping (continued)

["Weidenbrueck, Dieter" <dweidenbrueck@ptc.com>]

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