RE: case-insensitive SF

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

My recollection of the decision was to move the case insensitive statement to the Metafile Description String, but it could also be included in Font List...?

thx...Dave

> ----------
> From: 	Kevin O'Kane[SMTP:kevoka@AUTO-TROL.com]
> Sent: 	Tuesday, February 06, 2001 8:04 AM
> To: 	Dieter; Lofton Henderson; cgmopen-members@lists.oasis-open.org
> Subject: 	RE: case-insensitive SF
> 
> I agree with # 2 also.
> 
> Kevin
> 
> > -----Original Message-----
> > From:	Dieter@isodraw.de [SMTP:Dieter@isodraw.de]
> > Sent:	Tuesday, February 06, 2001 1:27 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 <mailto:lofton@rockynet.com> 
> > 	To: cgmopen-members@lists.oasis-open.org
> > <mailto: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.
> > 	
> > 	
> > 
>