Sorry if my use of terrible offended you. I thought I was pretty clear that I thought throwing a useful error and/or logging a useful message indicating the non-compliance would IMO be the correct response.
I agree that the patch does not make Batik non-conforming. In my experience patches like the proposed one slow down conformant rendering (a bunch of extra checks for non-conforming content), make the code base a mine field for following developers (what is this weird check - is this part of the spec? why are we generating infinite rectangles, how does dropping them help, etc) and tend to lead to harder and harder to understand error conditions (like this patch could lead to non-conformant elements silently being dropped not generating proper update regions etc). Thomas On Fri, Jun 7, 2024 at 10:11 AM Peter Hull <peterhul...@gmail.com> wrote: > 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 > >
