[sv-ac] set all new text in blue

All:

Shalom is right about the requirement that the new text 
all be in blue, even if it is for an entirely new section.
We need to follow this rule.  For the proposals under ballot,
please adjust them to conform to this as a friendly amendment.

Shalom suggests setting syntax that is required to be red
in the LRM but that appears in added text that is otherwise 
blue be set in red.  Maybe it will be better to use purple
in this case and always include a note to the editor that
explains that purple means things that need to be red in the LRM
but that are inside blue added text.

J.H.

> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.16,584,1175497200"; 
>    d="pdf'?scan'208";a="255068139"
> X-MIMEOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Thu, 26 Jul 2007 16:12:46 +0300
> X-MS-Has-Attach: yes
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] call to vote on Mantis 1681
> Thread-Index: AcfPeXvghgzeAK8CSR6Yy9kyUQQ83QADEt4A
> From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> Cc: <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 26 Jul 2007 13:12:47.0658 (UTC) FILETIME=[A95118A0:01C7CF86]
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C7CF86.A91E02AC
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> X-Former-Content-Transfer-Encoding: quoted-printable
> 
> John,
> 
> I have atached a copy of the latest SV DB Procedures.
> 
> Section 1d says clearly, "add text using blue".
> I see no reason why new text should be different from changed text in
> that respect.
> 
> If you look through Draft 3a, for example, you will see that the editor
> has also used that convention.
>  
> As for red terminals in syntax productions, I think that is clearly an
> exception. In a new syntax, it should all be blue, except for the red.
> If there is any ambiguity, there should be a note to the editor. But the
> editor should be able to rely on the colors as much as possible. He has
> so much to do without having to also try to figure out whether black
> text is old or new.
> 
> Regards,
> Shalom
> 
> > -----Original Message-----
> > From: John Havlicek [mailto:john.havlicek@freescale.com] 
> > Sent: Thursday, July 26, 2007 2:37 PM
> > To: Bresticker, Shalom
> > Cc: sv-ac@eda-stds.org
> > Subject: Re: [sv-ac] call to vote on Mantis 1681
> > 
> > Hi Shalom:
> > 
> > Are the rules that are the basis of these comments written 
> > down so that we can refer to them?
> > 
> > I know of many places in the LRM with inconsistencies in the 
> > use of fonts, and I would like to be able to judge 
> > independently whether or not they are correct.
> > 
> > Regarding the setting of new text in blue, this makes sense 
> > to me when we have red strikethrough, blue, and black text 
> > mixed in describing a change.  But if we are describing a new 
> > section, how do we represent other LRM conventions, like red 
> > terminals in syntax productions, underneath a completely blue 
> > font?  I am not sure there is a consistent set of rules on 
> > how to represent these things.
> > 
> > Best regards,
> > 
> > J.H.
> > 
> > > 
> > > Hi,
> > > 
> > > There seems to be some inconsistent formatting in the proposal.
> > > 
> > > For example, on page 3, if 14.13 is new, it should all be in blue.
> > > 
> > > At the bottom of page 3, "endclocking" should be bold.
> > > 
> > > At the top of page 4, "sys" should be in Courier font.
> > > 
> > > In M.2, "#define vpiGlobalClocking" should be in blue.
> > > 
> > > Some of the references to the "global clocking" statement 
> > are in bold 
> > > Courier font, and some are in regular Times font.
> 
> ------_=_NextPart_001_01C7CF86.A91E02AC
> Content-Type: text/plain; charset=us-ascii
> X-Former-Content-Type: application/octet-stream;
> 	name="SV_DB_Proc.pdf"
> Content-Transfer-Encoding: 7bit
> X-Former-Content-Transfer-Encoding: base64
> Content-Description: SV_DB_Proc.pdf
> X-Former-Content-Disposition: attachment;
> 	filename="SV_DB_Proc.pdf"
> 
> [file:/home/r8aaau/svac/administration/detached/SV_DB_Proc.pdf]
> 
> ------_=_NextPart_001_01C7CF86.A91E02AC--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.