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

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

Dave,

re 1)
valid use case for a non-compliant viewing of a CGM. The standard is all about what a compliant CGM is, and how to render it. The font mapping deviates from this. Again, for me this is a viewer feature, similar to colors and hundreds of other details that you can set in the IE options (including char sets, font size for display, etc etc).

re 2)
If you provide a font mapping to your end users, how is that different from specifying a font inside the CGM itself?
if the CGM asks for Helvetica, and Helvetica is not on the user's computer, he's stuck.
if you substitute Helvetica with Arial, and Arial is not on the user's computer, he's stuck as well.
The second case is an interesting one, because the file might be displayed on a Mac where Helvetica is present, however, because of the prescribed font mapping Arial would have to be used, which does not exist on a lot of Macs.
Font mapping makes an assumption about installed fonts as much as any CGM font table does. The CGM is independent from a single computer, whereas a font mapping file should be adjusted to a particular computer. It makes no sense to map to fonts where the best you can say about the target computer is "this display font should really be there".

Regards,
Dieter

-----Original Message-----
From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com] 
Sent: Montag, 24. März 2008 22:33
To: Weidenbrueck, Dieter; Galt, Stuart A; Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance

Dieter,

Ok, lets consider 2 use cases not related to legacy data

1)  I have a compound document with 5000+ WebCGM files and associated XCFs (and ACIs).  All of the CGM files call out Helvetica as the font.  Because of display characteristics I want to ensure that Arial is used during presentation, I specify that mapping in the ACI file.  I'm not making any assumption about the CGM viewer here because I know they are all interoperable.  Am I to assume all WebCGM CGM viewer will automatically map Helvetica to Arial?

2)  I have a dream that in the future I will be able to just distribute my compound document (from above) and not have to maintain the client configuration on the receiver's platform.  Again, it is an interoperability issue because I don't want to have to tell my users what they have to have on their computers.  I just want the font mapping to work with any WebCGM viewer.  If the user wants to remap the fonts, he is free to do so without wondering where the font mapping file is for a particular product.

Just my thoughts.

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: Weidenbrueck, Dieter [mailto:dweidenbrueck@ptc.com]
Sent: Monday, March 24, 2008 9:50 AM
To: Galt, Stuart A; Bezaire, Benoit; CGM Open WebCGM TC
Subject: RE: [cgmo-webcgm] Updated DTD and sample instance

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