Project

Profile

Help

Support #2682

closed

we shouldn’t be using exponential notation when numbers are too big for the number of digits allowed.

Added by Olga Abramovich about 8 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2016-03-21
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
9.6
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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

DAE71B.XSL (62 KB) DAE71B.XSL Olga Abramovich, 2016-03-21 15:59
DAE71B.XML (47 KB) DAE71B.XML Olga Abramovich, 2016-03-21 15:59
out.xml (2.11 MB) out.xml Olga Abramovich, 2016-03-21 15:59
Actions #1

Updated by Michael Kay about 8 years ago

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.

Actions #2

Updated by Michael Kay about 8 years ago

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.

Actions #3

Updated by Michael Kay about 8 years ago

  • 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