RE: [cgmo-webcgm] Updated DTD and sample instance

[Lofton Henderson <lofton@rockynet.com>]

(...catching up on some past issue dialogs.)

Here is another point of clarification/opinion on this thread...

I agree with Dieter's assertion -- the valid use cases for a *standarized* 
font-sub capability should not include the correction of invalid WebCGM 
instances.  Although fixing bogus legacy metafiles is indeed a needed and 
valuable service, IMO it is out-of-scope for standard WebCGM features.

Mapping standard WebCGM font requests to available font resources should be 
the supported use case, if we finally chose to include this functionality.

-Lofton.

At 12:50 PM 3/24/2008 -0400, Weidenbrueck, Dieter wrote:
>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