Any content that uses values outside of the range specified to be supported by the standard is relying on undefined behavior so from a compliance perspective the renderer is free to do whatever is convenient for it. I agree that someone should notify XChart that their generated SVG is not spec compliant (at least with 1.1).
As for what it would be nice for an implementation to do, it would be nice if it gave clear warnings/errors that the content is not compliant with the specification and thus may render incorrectly. Batik does it's own number parsing (it was substantially faster than the built in float parsers at the time) so that might not even be that hard to do. On Fri, Jun 7, 2024 at 7:13 AM Peter Hull <peterhul...@gmail.com> wrote: > On Wed, 5 Jun 2024 at 23:30, Thomas DeWeese <thomas.dewe...@gmail.com> > wrote: > > Unless stated otherwise for a particular attribute or property, a > <number> has the capacity for at least a single-precision floating point > number and has a range (at a minimum) of -3.4e+38F to +3.4e+38F. > > What's your feeling on what should happen for a number outside this > range? Ideally I suppose every implementation should give the actual > range it supports and what happens to out-of-range values. Which seems > unlikely to happen. > > This clause from the standard would be useful to tell XChart that > their code generates SVG that is not guaranteed to be handled by every > standard-compliant implementation. > > Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org > >
