Support #2682
closed
we shouldn’t be using exponential notation when numbers are too big for the number of digits allowed.
Fixed in Maintenance Release:
Description
we shouldn’t be using exponential notation when numbers are too big for the number of digits allowed.
is there the setting that we should not to use exponential notation?
/ConsecutiveGothicBold findfont
[12 0 0 -12 0 0] makefont setfont
0 118.543 moveto
<31> show
9 118.543 moveto
<2e> show
22.2 118.543 moveto
<30> show
31.2 118.543 moveto
<30> show
40.2 118.543 moveto
<31> show
49.2 118.543 moveto
<45> show
62.4 118.543 moveto
<36> show
From developer: When we used msxml it displayed correctly.
The first check as shown below prints “1.001E6” instead of the equivalent 1001000. As soon as it increments to the next page the trailing zeros become numbers and the length including the exponential notation becomes bigger than the window, so the gothic wraps to the next line on the vouchers and shrinks to fit on the check (which may be window configuration error as well).
Files
The XPath 2.0 specification here is incompatible with XPath 1.0; XPath 2.0 changed the rules so that xs:double values outside the range 1e-6 to 1e+6 will always be output in exponential form. It's easy to get numbers in integer form simply by casting to xs:integer before converting to a string, or by using format-number to control the formatting more precisely. Ideally, avoid using xs:double in the first place: for example, if @page has the lexical form of an integer, use xs:integer(@page)+1 rather than @page+1.
One thing I did notice in your code is very extensive use of constructs like
<xsl:with-param name="PadNumber">
<xsl:value-of select="$SAMPLESHT1FRONTStartNbr1" />
</xsl:with-param>
<xsl:with-param name="PadString">
<xsl:value-of select="'0000000'" />
</xsl:with-param>
<xsl:with-param name="FieldLength">
<xsl:value-of select="7" />
</xsl:with-param>
It's always better to write this as
<xsl:with-param name="PadNumber" select="$SAMPLESHT1FRONTStartNbr1" />
<xsl:with-param name="PadString" select="'0000000'" />
<xsl:with-param name="FieldLength" select="7" />
not just for brevity, but because you really don't want these variables to be result tree fragments. Saxon tries hard to optimize the more verbose form, but the two forms aren't 100% equivalent in edge cases, so there's a limit to what's possible. Ideally, add a type declaration (e.g. as="xs:integer") as well, which gives you better diagnostics, better documentation, and better performance.
- Tracker changed from Bug to Support
- Status changed from New to Rejected
- Assignee set to Michael Kay
I am closing this with no action because Saxon is behaving in the way that is required by the W3C specification.
Please register to edit this issue
Also available in: Atom
PDF