Discussion:
rs-274x nits
(too old to reply)
Dave Curtis
2014-08-12 17:51:10 UTC
Permalink
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
Dave Kerber
2014-08-12 18:46:47 UTC
Permalink
-----Original Message-----
Sent: Tuesday, August 12, 2014 1:51 PM
Subject: [geda-user] rs-274x nits
I'm trying to interpret the gerber format specification document
authored by Ucamco.
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.
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.
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
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.

#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
Dave Curtis
2014-08-12 20:50:52 UTC
Permalink
Post by Dave Kerber
-----Original Message-----
Sent: Tuesday, August 12, 2014 1:51 PM
Subject: [geda-user] rs-274x nits
I'm trying to interpret the gerber format specification document
authored by Ucamco.
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.
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.
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
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?
Post by Dave Kerber
#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
Cirilo Bernardo
2014-08-12 22:15:45 UTC
Permalink
----- Original Message -----
Sent: Wednesday, August 13, 2014 6:50 AM
Subject: Re: [geda-user] rs-274x nits
-----Original Message-----
Sent: Tuesday, August 12, 2014 1:51 PM
Subject: [geda-user] rs-274x nits
I'm trying to interpret the gerber format specification document
authored by Ucamco.
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.
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.
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
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
Dave Curtis
2014-08-12 22:48:31 UTC
Permalink
Post by Cirilo Bernardo
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?
I think the spec is clear at least with respect to the comment G-code (Is that G04? I don't have the spec handy..) and in the aperture macro "0" primitive. Spaces with the exception of the space required immediately after the 0 in a macro are part of the string, and spaces are not allowed elsewhere.
Post by Cirilo Bernardo
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.
That I will have to study. I haven't yet looked at the attributes in as much detail.

-dave
Gabriel Paubert
2014-08-15 21:52:33 UTC
Permalink
Post by Cirilo Bernardo
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.
Well, the format specification is changing quite fast, there are significant
differences with respect to spaces between J1 (February 2014) and J3 (July 2014).

In J1: "The character code 32 (SP, Space) is reserved for use in comments."
In J3: "SP can only be used inside strings and comments. They cannot be used anywhere else, not
inside or between commands, not between data blocks, etc."

But this last sentence is contradicted by:

Strings are made up of all valid characters except the reserved characters SP, CR, LF, ‘%’, ‘*’,
‘,’ and ‘;’.

In J1 the comma was not listed as a reserved character.

However in the regular expression they give (same in both versions), I have seen neither
the square brackets, nor the dollar sign (allowed in names!), nor the backquote nor a few
others and there is a dash which is obviously in the wrong place ("+-/" includes the comma!).
Furthermore, there seems to be a space before the closing bracket.

In other words, it might be worth contacting UCAMCO because the documentation is inconsistent.

I believe that the correct regex for strings (provided you use the C locale) is:
[][a-zA-Z0-9 !"#$&'()+./:<=>?@\^_`{|}~-]

Gabriel
Dave Curtis
2014-08-17 16:18:58 UTC
Permalink
Post by Gabriel Paubert
However in the regular expression they give (same in both versions), I have seen neither
the square brackets, nor the dollar sign (allowed in names!), nor the backquote nor a few
others and there is a dash which is obviously in the wrong place ("+-/" includes the comma!).
Furthermore, there seems to be a space before the closing bracket.
Quite right. The RE they give rejects the very next example in the
document.

-dave

Cirilo Bernardo
2014-08-12 20:49:39 UTC
Permalink
----- Original Message -----
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.
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.
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.
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
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.

- Cirilo
Dave Curtis
2014-08-12 21:26:42 UTC
Permalink
Post by Cirilo Bernardo
----- Original Message -----
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.
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.
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.
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
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
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?
Post by Cirilo Bernardo
- Cirilo
Cirilo Bernardo
2014-08-12 22:20:17 UTC
Permalink
----- Original Message -----
Sent: Wednesday, August 13, 2014 7:26 AM
Subject: Re: [geda-user] rs-274x nits
Post by Cirilo Bernardo
----- Original Message -----
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.
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.
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
Post by Cirilo Bernardo
in long data blocks.
The line separators have no effect on the image.
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
Post by Cirilo Bernardo
CR and LF should simply be expunged, and that CR/LF could even split
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
Post by Cirilo Bernardo
reading RS-274X, should CR/LF's that split lexical units be
ignored?
Post by Cirilo Bernardo
Although I realize that even if legal, I doubt if anyone writes gerber
that way.
-dave
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?

- Cirilo
Dave Curtis
2014-08-12 22:57:11 UTC
Permalink
Post by Cirilo Bernardo
----- Original Message -----
Sent: Wednesday, August 13, 2014 7:26 AM
Subject: Re: [geda-user] rs-274x nits
Post by Cirilo Bernardo
----- Original Message -----
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.
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.
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
Post by Cirilo Bernardo
in long data blocks.
The line separators have no effect on the image.
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
Post by Cirilo Bernardo
CR and LF should simply be expunged, and that CR/LF could even split
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
Post by Cirilo Bernardo
reading RS-274X, should CR/LF's that split lexical units be
ignored?
Post by Cirilo Bernardo
Although I realize that even if legal, I doubt if anyone writes gerber
that way.
-dave
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
Post by Cirilo Bernardo
- Cirilo
John Doty
2014-08-12 23:19:29 UTC
Permalink
Post by Dave Curtis
Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?
Often, specs for readers say “be liberal in what you accept” while specs for writers say “be conservative in what you emit”. That seems to be the case here. Don’t make a big deal of it.

John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd-***@public.gmane.org
Dave Curtis
2014-08-13 03:35:44 UTC
Permalink
Post by John Doty
Post by Dave Curtis
Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?
Often, specs for readers say “be liberal in what you accept” while specs for writers say “be conservative in what you emit”. That seems to be the case here. Don’t make a big deal of it.
Yes, I totally understand that philosophy. If I was writing a reader, I
would have no problem being liberal. If I was writing a writer, I would
have no problem being conservative. But... I am writing a validation
tool, which leaves zero margin for lack of precision.

I first did logic design on mainframe CPU's in 1981. I spent a large
part of my life combing architecture documents for nits, making the
lives of the spec authors quite miserable until they told me precisely
what they meant. Logic design mistakes in CPUs can be expensive. At
one point in my life I signed off on the Pentium processor errata sheet
every month before it went out.....
Post by John Doty
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
John Doty
2014-08-13 13:17:31 UTC
Permalink
Post by John Doty
Post by Dave Curtis
Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?
Often, specs for readers say “be liberal in what you accept” while specs for writers say “be conservative in what you emit”. That seems to be the case here. Don’t make a big deal of it.
Yes, I totally understand that philosophy. If I was writing a reader, I would have no problem being liberal. If I was writing a writer, I would have no problem being conservative. But... I am writing a validation tool, which leaves zero margin for lack of precision.
Well, commonly you have “errors” and “warnings”. Issue an error for anything that a liberal reader cannot interpret, and a warning for anything that a conservative writer should not emit.
I first did logic design on mainframe CPU's in 1981. I spent a large part of my life combing architecture documents for nits, making the lives of the spec authors quite miserable until they told me precisely what they meant. Logic design mistakes in CPUs can be expensive. At one point in my life I signed off on the Pentium processor errata sheet every month before it went out.....
Post by John Doty
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd-***@public.gmane.org
Dave Curtis
2014-08-13 17:36:56 UTC
Permalink
Post by John Doty
Post by John Doty
Post by Dave Curtis
Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?
Often, specs for readers say “be liberal in what you accept” while specs for writers say “be conservative in what you emit”. That seems to be the case here. Don’t make a big deal of it.
Yes, I totally understand that philosophy. If I was writing a reader, I would have no problem being liberal. If I was writing a writer, I would have no problem being conservative. But... I am writing a validation tool, which leaves zero margin for lack of precision.
Well, commonly you have “errors” and “warnings”. Issue an error for anything that a liberal reader cannot interpret, and a warning for anything that a conservative writer should not emit.
Yes, obviously. So you understand why I am asking.
Post by John Doty
I first did logic design on mainframe CPU's in 1981. I spent a large part of my life combing architecture documents for nits, making the lives of the spec authors quite miserable until they told me precisely what they meant. Logic design mistakes in CPUs can be expensive. At one point in my life I signed off on the Pentium processor errata sheet every month before it went out.....
Post by John Doty
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
Gabriel Paubert
2014-08-15 21:55:58 UTC
Permalink
Post by Dave Curtis
Post by John Doty
Post by Dave Curtis
Because if "CR and LF have no effect", then why the admonition against CR/LF against places after a comma?
Often, specs for readers say “be liberal in what you accept” while specs for writers say “be conservative in what you emit”. That seems to be the case here. Don’t make a big deal of it.
Yes, I totally understand that philosophy. If I was writing a
reader, I would have no problem being liberal. If I was writing a
writer, I would have no problem being conservative. But... I am
writing a validation tool, which leaves zero margin for lack of
precision.
I first did logic design on mainframe CPU's in 1981. I spent a large
part of my life combing architecture documents for nits, making the
lives of the spec authors quite miserable until they told me
precisely what they meant. Logic design mistakes in CPUs can be
expensive. At one point in my life I signed off on the Pentium
processor errata sheet every month before it went out.....
And it still was mass-produced with some "floating point division issues" ;-)

Gabriel
Cirilo Bernardo
2014-08-13 00:04:07 UTC
Permalink
----- Original Message -----
Sent: Wednesday, August 13, 2014 8:57 AM
Subject: Re: [geda-user] rs-274x nits
Post by Cirilo Bernardo
----- Original Message -----
Sent: Wednesday, August 13, 2014 7:26 AM
Subject: Re: [geda-user] rs-274x nits
Post by Cirilo Bernardo
----- Original Message -----
Sent: Wednesday, August 13, 2014 3:51 AM
Subject: [geda-user] rs-274x nits
I'm trying to interpret the gerber format specification
document
Post by Cirilo Bernardo
Post by Cirilo Bernardo
authored by Ucamco.
The line separators CR and LF have no effect; they can be
ignored when
Post by Cirilo Bernardo
Post by Cirilo Bernardo
processing the file. It
is recommended to use line separators to improve human
readability.
Post by Cirilo Bernardo
Post by Cirilo Bernardo
It is recommended to add line separators between data blocks
for
Post by Cirilo Bernardo
Post by Cirilo Bernardo
readability. Do not
put a line separator within a data block, except after a comma
separator
Post by Cirilo Bernardo
in long data blocks.
The line separators have no effect on the image.
The ‘%’ must immediately follow the ‘*’ of the last data block
without
Post by Cirilo Bernardo
Post by Cirilo Bernardo
intervening line separators.
This is an exception to the general rule that a data block can
be
Post by Cirilo Bernardo
Post by Cirilo Bernardo
followed by a line separator.
#3 is clear enough.
#1 and #2 seem to be in conflict.  A strict reading of #1 would
say
Post by Cirilo Bernardo
that
Post by Cirilo Bernardo
CR and LF should simply be expunged, and that CR/LF could even
split
Post by Cirilo Bernardo
Post by Cirilo Bernardo
G
03
X
123
*
Which seems odd, but is a result of strict reading of #1.  But
is in
Post by Cirilo Bernardo
Post by Cirilo Bernardo
conflict with the advice of #2.
It's easy enough to comply with the advice of #2 while
writing. 
Post by Cirilo Bernardo
But if
Post by Cirilo Bernardo
reading RS-274X, should CR/LF's that split lexical units be
ignored?
Post by Cirilo Bernardo
Although I realize that even if legal, I doubt if anyone writes
gerber
Post by Cirilo Bernardo
Post by Cirilo Bernardo
that way.
-dave
1. The CR/LF are optional; you do not need them but they are
recommended
Post by Cirilo Bernardo
Post by Cirilo Bernardo
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
Post by Cirilo Bernardo
Post by Cirilo Bernardo
CR/LF after a comma.
NO!  That directly conflicts with #1 "CR and LF no effect." 
Which is
Post by Cirilo Bernardo
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
Post by Cirilo Bernardo
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
I can only suggest that you read the specifications carefully, make notes,
maybe read over the specs again, and formulate a letter to UCAMCO. They
promise they'll respond (gerber at UCAMCO com), but out of professional
courtesy make sure that you did read the specs carefully. Specifications
are rarely if ever perfect, but I think this is one case where there is
a good opportunity to clarify some issues and make the specification
more solid. Your issue with splitting a lexical unit with CR/LF is a good
example of ambiguity in the specification - was the text really intended
that way or did they intend to recommend using CR/LF only at the end of
a command block and after a comma within a data block.

With regards to CR/LF and the comma, I see no ambiguity at all. CR/LF is
optional but recommended for human readability, but within any data block
it may only be placed immediately after a comma.

- Cirilo
Dave Curtis
2014-08-13 03:27:44 UTC
Permalink
Post by Cirilo Bernardo
With regards to CR/LF and the comma, I see no ambiguity at all. CR/LF is
optional but recommended for human readability, but within any data block
it may only be placed immediately after a comma.
Well, then that is proof that the spec is ambiguous, because that would
conflict with some readings of the spec. You may be correct, but the
spec is soft.
Post by Cirilo Bernardo
- Cirilo
Loading...