On Fri, 7 Jun 2024 at 14:31, Thomas DeWeese <thomas.dewe...@gmail.com> wrote: > 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. I don't like it either, but I'd stop short of "terrible" (I've had some terrible ideas in the past, and this doesn't come close!) because it's consistent with "from a compliance perspective the renderer is free to do whatever is convenient for it" and doesn't fail any tests. I think this is a judgement call, so it needs the judgement of someone who knows what they're talking about (ie. you), so I'm grateful for that. As far as I can see, browsers take a different approach, and try to render something, which is consistent with the way they treat invalid HTML, isn't it? What do you think would be the best - throwing an error, printing a log message or something else?
> 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. I agree. Also it will still be possible to write an out-of-bounds literal. --------------------------------------------------------------------- To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
