References: <53EA540E DOT 9000609 AT sonic DOT net> <2aabf5abd73cc057e4a0193bf4a2d101 AT mail DOT gmail DOT com> <53EA7E2C DOT 40804 AT sonic DOT net>
Message-ID: <1407881745.18877.YahooMailNeo@web120505.mail.ne1.yahoo.com>
Date: Tue, 12 Aug 2014 15:15:45 -0700
From: Cirilo Bernardo <cirilo_bernardo AT yahoo DOT com>
Subject: Re: [geda-user] rs-274x nits
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
In-Reply-To: <53EA7E2C.40804@sonic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

----- Original Message -----

> From: Dave Curtis <davecurtis AT sonic DOT net>
> To: geda-user AT delorie DOT com
> Cc: 
> Sent: Wednesday, August 13, 2014 6:50 AM
> Subject: Re: [geda-user] rs-274x nits
> 
> On 08/12/2014 11:46 AM, Dave Kerber wrote:
>>>  -----Original Message-----
>>>  From: Dave Curtis [mailto:davecurtis AT sonic DOT net]
>>>  Sent: Tuesday, August 12, 2014 1:51 PM
>>>  To: geda-user AT delorie DOT com
>>>  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.
>> 
>>  I don't see any conflict there.  #1 is saying that *when processing* 
> you
>>  must ignore line breaks, but it is recommended to put them in for
>>  readability.  Your example of splitting G-codes, etc, certainly does NOT
>>  improve readability.'
> 
> So, then it is your interpretation that a correct RS-274X parser should 
> not reject G-codes (and other lexical units) that have been split by 
> CR/LF's?
> 

Based solely on the 3 points you posted, no - but that is only a tiny
fraction of the specification and you will have to look through all of
it to determine that. However, splitting a lexical unit with a CR/LF
wouldn't make it more legible to humans, would it?

If the specification is silent about breaking a lexical unit then to be
safe a parser should accept such a broken unit even if your particular
writer never breaks a unit.

In this case it may be worthwhile writing to UCAMCO for clarification
on the issue. Make sure to present a few clear examples to illustrate
your points. I suspect the response would be along the lines of
"it's really silly to split a lexical unit given its length and the
stated purpose of CR/LF being for human readability only - so what 
do you think?"  However, perhaps the role of spaces could be
clarified. Where are spaces allowed other than after the '0' in a
block comment and within strings? Can spaces exist at the ends of a
string and will they be part of the string or discarded? The latter
is of particular importance since Value Attributes are strings; the
examples never show a space in a value attribute, but spaces are not
expressly forbidden.

- Cirilo


> 
>> 
>>  #2 is saying to put line blocks where they will improve readability, just
>>  not at random spots in a data block.
>> 
>> 
>>> 
>>>  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
>>> 
>>> 
>>