FYI I just saw your attempted fix in the bug thread. I personally think that is a terrible idea to add hacks/work arounds to partially fix the invalid content. It is helpful to tell people their content is invalid and ideally where and why - doing partial work arounds for invalid content IMO does no-one any favors - it's adding complexity and still going to lead to failures in other areas that are likely going to be harder to find/debug/explain.
If you feel that single precision float is too limiting it would be much better to try and migrate everything to double precision - but I suspect that would be a long road. On Fri, Jun 7, 2024 at 9:12 AM Thomas DeWeese <thomas.dewe...@gmail.com> wrote: > 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 >> >>
