RE: case-insensitive SF

[Lofton Henderson <lofton@rockynet.com>]

I agree with your proposal.

-Lofton.

At 09:42 AM 2/9/01 -0800, Cruikshank, David W wrote:

> > 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.
> >
> >
> >
> >
> >