Yep, those properties disable the padding behavior (textPadKind="none"), but those skipped bytes will be filled with the character "f" (fillByte="f").
Most likely if someone is using the pattern #,###, they probably want the number right justified and space padded. So you would want the properties: textPadKind="padChar" textNumberPadCharacter="%SP;" textNumberJustification="right" - Steve On 6/25/19 2:38 PM, Costello, Roger L. wrote: > Hi Steve, > > I see that my defaults.dfdl.xsd file has these: > > fillByte="f" > textPadKind="none" > > Will those produce the behavior you describe? > > /Roger > > > -----Original Message----- > From: Steve Lawrence <[email protected]> > Sent: Tuesday, June 25, 2019 2:34 PM > To: [email protected] > Subject: [EXT] Re: 0,100 --> parse --> 100 --> unparse --> 100ff ... Huh? > > There are no defaults value for these properties. And actually, > dfdl:textNumberPadKind isn't a thing, it should be dfdl:textPadKind. But if > textPadKind="none" then no padding will be added. > > But another option is that dfdl:fillByte is being used to fill those extra > bytes. Perhaps dfdl:fillByte="f"? > > - Steve > > On 6/25/19 2:28 PM, Costello, Roger L. wrote: >> Hi Steve, >> >>> I would guess that you have: >>> textNumberPadKind="padChar", >>> textNumberPadCharacter="f", and >>> textNumberJustification="left" >> >> Actually, I looked at my defaults.dfdl.xsd file and it doesn't mention any >> of those properties. If those properties are not specified, do they default >> to the values you list? >> >> /Roger >> >> -----Original Message----- >> From: Steve Lawrence <[email protected]> >> Sent: Tuesday, June 25, 2019 2:14 PM >> To: [email protected] >> Subject: [EXT] Re: 0,100 --> parse --> 100 --> 100ff ... Huh? >> >> This is a good example of the difference between # and 0 pattern characters >> when unparsing. >> >> With the pattern "0,000", the value "100" will be padded with zero's and so >> will unparse to "0,100", which matches the expected length of 5. >> >> However, with the pattern "#,###", the value "100" will unparse to >> "100"--no comma is needed and it will not zero pad. But your test1 >> element is defined as having a length of 5 and the the unparsed value >> has a length of 3. In this case, Daffodil uses textNumberPadKind and >> related properties (textNumberPadCharacter, textNumberJustification, >> etc.) to pad the unparsed value up to the needed 5 characters. >> >> So I would guess that you have textNumberPadKind="padChar", >> textNumberPadCharacter="f", and textNumberJustification="left". Those three >> properties will cause Daffodil to add extra "f" characters as padding to the >> right of the string. >> >> I don't think I would say to never use the '#' character. There are >> certainly going to be times where you don't want extra padding characters, >> like in some delimited formats where numbers do not have explicit lengths. >> >> - Steve >> >> On 6/25/19 1:32 PM, Costello, Roger L. wrote: >>> Hello DFDL community, >>> >>> My input file has this: >>> >>> 0,100 >>> >>> 0,100 >>> >>> My DFDL schema is this: >>> >>> <xs:elementname="input"> >>> <xs:complexType> >>> <xs:sequencedfdl:separator="%NL;"dfdl:separatorPosition="infix"> >>> <xs:elementname="test1"type="xs:unsignedInt" >>> dfdl:length="5"dfdl:lengthKind="explicit" >>> dfdl:textNumberCheckPolicy="strict" >>> dfdl:textNumberPattern="#,###"/> >>> <xs:elementname="test2"type="xs:unsignedInt" >>> dfdl:length="5"dfdl:lengthKind="explicit" >>> dfdl:textNumberCheckPolicy="strict" >>> dfdl:textNumberPattern="0,000"/> </xs:sequence> >>> </xs:complexType> </xs:element> >>> >>> The output of parsing is this: >>> >>> <input> >>> <test1>100</test1> >>> <test2>100</test2> >>> </input> >>> >>> The output of unparsing is this: >>> >>> 100ff >>> 0,100 >>> >>> Huh? >>> >>> Why am I getting 100ff? >>> >>> I think the lesson learned is never use the pound (#) symbol in >>> dfdl:textNumberPattern. Do you agree? >>> >>> /Roger >>> >> >
