OASIS Static Analysis Results Interchange Format (SARIF) TC

Also, the reason we got hung up on non-raster images was in coming up with an acceptable set of units.

The unit for an svg are svg units and are mapped to physical units by the renderer. Units for pdfs are 1/72". Both can be specified as just numbers if we specify the units are the natural unit for the format. One additional wrinkle is that pdf uses a natural Cartesian coordinate system where increasing Y is upwards, whereas svg and raster formats increasing Y is downwards. If you said that units are the natural units and did not specify which of the points is the (top, left), which is unnecessary, then specification works with rasters, svg and pdf formats. Jim On 05/04/2018 01:37 PM, Larry Golding (Comcast) wrote: Also, the reason we got hung up on non-raster images was in coming up with an acceptable set of units.
Original Message----- From: Larry Golding (Comcast) <larrygolding@comcast.net> Sent: Friday, May 4, 2018 11:34 AM To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; 'James A. Kupsch' <kupsch@cs.wisc.edu>; 'sarif@lists.oasis-open.org' <sarif@lists.oasis-open.org> Subject: RE: [sarif] Image files: wait just a minute here! Michael, I agree with what you say, _if_ we restrict to raster images. Jim asked why we should restrict to raster images. My reason was that we got hung up attempting to define a useful set of units for non-raster images. Jim, is there a simple way to do this? Remember, the original motivation for this was screenshots. From my standpoint, generalizing to raster images is just gravy -- it falls out easily. Incorporating non-raster images and IMO is not worth the trouble (we could add them in a future SARIF as a non-breaking change). (Michael, remember we've come to a meeting of the minds on the acceptability of a SARIF 2.1 that incorporates _only_ additive, non-breaking changes.)

And so we've come back to the outcome that was decided upon in the TC, correct? i.e., make the following changes and ship the thing. We need to add a note that the consumer needs to be aware of the target coordinate system in addition to the image unit when evaluating this content. Jim: make values float and change pixels to units appropriate for format
Original Message----- From: James A. Kupsch <kupsch@cs.wisc.edu> Sent: Friday, May 4, 2018 12:26 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org Subject: Re: [sarif] Image files: wait just a minute here! The unit for an svg are svg units and are mapped to physical units by the renderer. Units for pdfs are 1/72". Both can be specified as just numbers if we specify the units are the natural unit for the format. One additional wrinkle is that pdf uses a natural Cartesian coordinate system where increasing Y is upwards, whereas svg and raster formats increasing Y is downwards. If you said that units are the natural units and did not specify which of the points is the (top, left), which is unnecessary, then specification works with rasters, svg and pdf formats. Jim On 05/04/2018 01:37 PM, Larry Golding (Comcast) wrote: > Also, the reason we got hung up on non-raster images was in coming up with an acceptable set of units. > >
Original Message----- > From: Larry Golding (Comcast) <larrygolding@comcast.net> > Sent: Friday, May 4, 2018 11:34 AM > To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; 'James A. > Kupsch' <kupsch@cs.wisc.edu>; 'sarif@lists.oasis-open.org' > <sarif@lists.oasis-open.org> > Subject: RE: [sarif] Image files: wait just a minute here! > > Michael, I agree with what you say, _if_ we restrict to raster images. > > Jim asked why we should restrict to raster images. My reason was that we got hung up attempting to define a useful set of units for non-raster images. Jim, is there a simple way to do this? > > Remember, the original motivation for this was screenshots. From my standpoint, generalizing to raster images is just gravy -- it falls out easily. Incorporating non-raster images and IMO is not worth the trouble (we could add them in a future SARIF as a non-breaking change). > > (Michael, remember we've come to a meeting of the minds on the > acceptability of a SARIF 2.1 that incorporates _only_ additive, > non-breaking changes.) > >