X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Yahoo-Newman-Property:	ymail-3
X-Yahoo-Newman-Id:	251796 DOT 5038 DOT bm AT omp1040 DOT mail DOT ne1 DOT yahoo DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1407881746; bh=ITBvmx6yYYPUp+CIzIZzvHqOqZQYpVyCYiHpeMPe8E0=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0V7mosYVGSxcSXCwvcEOLdaG2hPa5vS75Ca1e71cE7hTQMh18veJYk5AE4587B+AnkIRE9Ifsn4q4Oq1A+wyFSSQwnodWkEy5rS0578Kp7//pmXHRtWg43JI27GDFgeLl5dtMg51zXn4PQhFy/5GGumWdhXmhKtofM0yG4Pnpts=
X-YMail-OSG:	E0S0iiIVM1kZDlF7qy.tDW_48McRoYQnb.pUySXA6mGl1sF
	UPYMVaGYKmRT32iKxY.3AX_DZyqjZi1Fn96YKbNSbS9qlFyqdLBgyuViYI3G
	MAcKrUhAHvzHdb_qkXNn8kQrjHIy6sq6cFWY8Acs4FC8T7orsjTSTO4Lc4gI
	HpluJYICN99h0psRk5yQL9YAAOKiy801rTUiY5aSFI8P3c18nFTiJPg2uY00
	0zOrdsGPstGwy_EmwbiQxkHPR1qg0IQ7Mw8LIbEWpsD.bI53gKWmFLYqcCsV
	lbipUSlVP9dut51EQQ4c6HjBYrf03s8FSyjXTfGGrOAWVVVmPa8ToJ1Jq2Su
	a8DBM4ZzJDYom.sfc28vm4.Ts6ddY9dUx7ERVE.O9Pb4Bc1sTjgu6h4xnsd0
	lUmEGu_IgwxGGjyuAknvtI7N05NeAb0_Oetqfwx6MzC.wFLEN83TbrZjChO9
	9QdwF8kgWB3EeTJ9WAKfIU1WYjgWYfz497pIse0k.EwCm_8RkU_T0wddqoFD
	EU9GnF4CJfMPsQwI1k9y9r3rE.77olTThUEHo7vdvDcQGttqPs63rj2Ie8wU
	-
X-Rocket-MIMEInfo:	002.001,LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBEYXZlIEN1cnRpcyA8ZGF2ZWN1cnRpc0Bzb25pYy5uZXQ.Cj4gVG86IGdlZGEtdXNlckBkZWxvcmllLmNvbQo.IENjOiAKPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxMywgMjAxNCA2OjUwIEFNCj4gU3ViamVjdDogUmU6IFtnZWRhLXVzZXJdIHJzLTI3NHggbml0cwo.IAo.IE9uIDA4LzEyLzIwMTQgMTE6NDYgQU0sIERhdmUgS2VyYmVyIHdyb3RlOgo.Pj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4.PiAgRnJvbTogRGF2ZSBDdXIBMAEBAQE-
X-Mailer:	YahooMailWebService/0.8.201.700
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
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id s7CMFo08029547
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

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

- Raw text -