X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [geda-user] rs-274x nits
From: Dave Curtis <davecurtis AT sonic DOT net>
In-Reply-To: <1407882017.64999.YahooMailNeo@web120501.mail.ne1.yahoo.com>
Date: Tue, 12 Aug 2014 15:57:11 -0700
Message-Id: <C62EE316-BE2E-4667-8238-B7644A8E722E@sonic.net>
References: <53EA540E DOT 9000609 AT sonic DOT net> <1407876579 DOT 79247 DOT YahooMailNeo AT web120502 DOT mail DOT ne1 DOT yahoo DOT com> <53EA8692 DOT 4090902 AT sonic DOT net> <1407882017 DOT 64999 DOT YahooMailNeo AT web120501 DOT mail DOT ne1 DOT yahoo DOT com>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1084)
X-Sonic-CAuth: UmFuZG9tSVY9iBHp3j6SSm1QLoAOanaKXmXlUudMcUL5E79TkRtamkn393Fq2xVOQC1q2+YhUik7FPdFisnOwPsWiV9B+ubpeeEASFvShv0=
X-Sonic-ID: C;qEab/nMi5BGHoM2354E5FQ== M;HHvt/nMi5BGHoM2354E5FQ==
X-Spam-Flag: No
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id s7CMvHdc031849
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Aug 12, 2014, at 3:20 PM, Cirilo Bernardo wrote:

> 
> 
> 
> 
> ----- Original Message -----
>> From: Dave Curtis <davecurtis AT sonic DOT net>
>> To: geda-user AT delorie DOT com
>> Cc: 
>> Sent: Wednesday, August 13, 2014 7:26 AM
>> Subject: Re: [geda-user] rs-274x nits
>> 
>> On 08/12/2014 01:49 PM, Cirilo Bernardo wrote:
>>> ----- Original Message -----
>>> 
>>>> From: Dave Curtis <davecurtis AT sonic DOT net>
>>>> To: geda-user AT delorie DOT com
>>>> Cc:
>>>> Sent: Wednesday, August 13, 2014 3:51 AM
>>>> Subject: [geda-user] rs-274x nits
>>>> 
>>>> I'm trying to interpret the gerber format specification document
>>>> authored by Ucamco.
>>>> 
>>>> 1. On page 35 it says:
>>>> The line separators CR and LF have no effect; they can be ignored when
>>>> processing the file. It
>>>> is recommended to use line separators to improve human readability.
>>>> 
>>>> 2. On page 36 it says:
>>>> It is recommended to add line separators between data blocks for
>>>> readability. Do not
>>>> put a line separator within a data block, except after a comma 
>> separator
>>>> in long data blocks.
>>>> The line separators have no effect on the image.
>>>> 
>>>> 
>>>> 3. on page 40, talking about closing parameter blocks it says:
>>>> The ‘%’ must immediately follow the ‘*’ of the last data block without
>>>> intervening line separators.
>>>> This is an exception to the general rule that a data block can be
>>>> followed by a line separator.
>>>> 
>>>> #3 is clear enough.
>>>> 
>>>> #1 and #2 seem to be in conflict.  A strict reading of #1 would say 
>> that
>>>> CR and LF should simply be expunged, and that CR/LF could even split
>>>> G-coded, numbers, etc., like this:
>>>> G
>>>> 03
>>>> X
>>>> 123
>>>> *
>>>> Which seems odd, but is a result of strict reading of #1.   But is in
>>>> conflict with the advice of #2.
>>>> 
>>>> It's easy enough to comply with the advice of #2 while writing.  
>> But if
>>>> reading RS-274X, should CR/LF's that split lexical units be 
>> ignored?
>>>> Although I realize that even if legal, I doubt if anyone writes gerber
>>>> that way.
>>>> 
>>>> -dave
>>>> 
>>> 
>>> There is no conflict at all:
>>> 
>>> 1. The CR/LF are optional; you do not need them but they are recommended
>>> to make the file look better to humans.
>>> 
>>> 2. If you use CR/LF to make a data block look prettier, you can only use
>>> CR/LF after a comma.
>> 
>> NO!  That directly conflicts with #1 "CR and LF no effect."  Which is 
>> it?
>> 
> 
> 
> Well, as 2 of us have already said, it's both. If you look at #2 the
> specification does state that data blocks are an exception and that
> CR/LF are only allowed after a ',' within a data block. The specification
> is very clear that this is an exception, so why do you insist that it
> violates the other general rule?
> 

Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?  I suppose you could say that the operative word in placing CR/LF only after comma is *recommendation*, which would then by my reading allow CR/LF arbitrarily.  Certainly it would make the file look like hash, but if the aim is a reader that accepts all correct RS-274X files, then these pedantic nits matter.  

As you suggest, it is probably worth inconveniencing a few electrons by sending an e-mail to Ucamco.  I'm not holding my breath about getting a reply, but I'd be happy to be wrong about that.

-dave

> - Cirilo
> 
>