RE: case-insensitive SF

["Cruikshank, David W" <David.Cruikshank@PSS.Boeing.com>]

> Group,
> 
> This is a second try at this email, since the mail server bounced to back at me for using a reserved word in the first line of the message!
> 
> My proposed solution this this issue is to take out the case insensitive statement from the non-graphical text area, but put it into the profile for Metafile Description, Font List, and Font Properties.
> 
	Comments??

> Release 2 editing is progressing well, but I need to finalize this one.
> 
> thx...Dave
> 
> 	----------
> 	From: 	Dieter@isodraw.de[SMTP:Dieter@isodraw.de]
> 	Reply To: 	Dieter
> 	Sent: 	Tuesday, February 06, 2001 12:26 AM
> 	To: 	Lofton Henderson; cgmopen-members@lists.oasis-open.org
> 	Subject: 	Re: case-insensitive SF
> 
> 	Lofton,
> 	 
> 	good point. I agree with 2.
> 	 
> 	Dieter
> 	 
> 
> 		----- Original Message ----- 
> 		From: Lofton Henderson 
> 		To: cgmopen-members@lists.oasis-open.org 
> 		Sent: Tuesday, February 06, 2001 12:44 AM
> 		Subject: case-insensitive SF
> 
> 		CGM Open Members --
> 
> 		In the teleconference for resolution of WebCGM Second Release issues, we decided that the "case-insensitive" spec for type SF, non-graphical text, T.14.5, was incorrect.  Specifically, it clashes with XML specifications and could make a real mess of attempting to implement a companion-file architecture.
> 
> 		However, it has some impacts that we might not have intended.  For example, the ATA conformance test FNTLST04 contains this font list:
> 
> 		1 >TiMeS_RomAN<
> 		2 >TIMES-italic<
> 		3 >helvetica-oblique<
> 		4 >courier-BOLD<
> 
> 		This would now be invalid.  So the question we need to address is the scope of the correction.  Options:
> 
> 		1. all SF parameters (telcon decision);
> 		2. all SF data in APS and APS attributes are case-sensitive, but elsewhere is case-insensitive.  (Note this leaves BegPic 'id' indeterminant, as it enters into fragment specifications).
> 		3. all SF parameters unless specifically excepted (e.g., could give exception to Font List, etc).
> 
> 		I think #2 is a reasonable combination of minimal impact on legacy CGMs, and achieving what we intended with the correction.  
> 
> 		Other thoughts?
> 
> 		-Lofton.
> 
> 
> 
> 
>