onday, June 24, 2019 10:38:10 AM
To: dev@daffodil.apache.org
Subject: Re: Character Encodings - No Statement
Slightly different issue from what I was expecting. Daffodil appears to be
output U+00A0 as " " instead of as a literal character.
This is not wrong, and I believe a compliant X
e simply a padding character. In my test data,
I observed the string: "ADP ADP ".
From: Beckerle, Mike
Sent: Tuesday, June 18, 2019 9:28:07 AM
To: dev@daffodil.apache.org
Subject: Re: Character Encodings - No Statement
One other possible mechanism:
ni
ke
Sent: Monday, June 17, 2019 5:17:20 PM
To: dev@daffodil.apache.org
Subject: Re: Character Encodings - No Statement
This sounds like fixed length data fields, or min-length data fields. So the
character to use wants to be similar in concept to the pad character - i.e., it
is used to a
: dev@daffodil.apache.org
Subject: Re: Character Encodings - No Statement
This sounds like fixed length data fields, or min-length data fields. So the
character to use wants to be similar in concept to the pad character - i.e., it
is used to add length to a fixed length field, but has no significance
e, Brandon
Sent: Monday, June 17, 2019 4:55:09 PM
To: dev@daffodil.apache.org
Subject: Character Encodings - No Statement
I am going through link16 (mil-std-6016e, not publically available) to add
support for some of the special character encodings to Daffodil (simmilar to
dfi264:dui001 that has al
I am going through link16 (mil-std-6016e, not publically available) to add
support for some of the special character encodings to Daffodil (simmilar to
dfi264:dui001 that has already been added).
While doing so, I came across DFI 311 DUI 002. Several bitcodes are
"UNDEFINED", which I intend to
