model: "stroke" prefix on Shape properties; lineCap property name

[mtbc]

On http://www.openmicroscopy.org/site/support/omero5.2/developers/Model/EveryObject.html#shape in OMERO Shape has a few stroke-related properties:

• strokeColor
• strokeDashArray
• strokeDashOffset
• strokeLineCap
• strokeLineJoin
• strokeMiterLimit
• strokeWidth

The OME-XML schema at http://www.openmicroscopy.org/Schemas/Documentation/Generated/OME-2015-01/ROI_xsd.html#Shape has:

• StrokeColor
• StrokeDashArray
• StrokeWidth
• LineCap

For OMERO 5.3 to harmonize with OME-XML we've thus already merged commits that drop:

• strokeDashOffset
• strokeLineJoin
• strokeMiterLimit

There remains a question about what to do about strokeLineCap seeing as OME-XML names it only LineCap:

1. Should OMERO use lineCap to match OME-XML?
2. Should OME-XML use StrokeLineCap to fit the other Stroke- properties?
3. Should the "stroke-" prefix be dropped in either or both for all the properties? (What about color though?)

For that last list item @rleigh-dundee makes an interesting point in https://trello.com/c/9ZsIFHcJ/38-discrepancies:

Regarding StrokeLineCap, are Stroke and Line not used interchangeably? So would it be better to standardise upon Line or Stroke entirely rather than using both? Or is this a special case?

[mtbc]

Frankly for expediency I suggest just dropping linecap from both, as being fiddly presentation detail our model doesn't need, and to brush the more general prefixing issue under the rug for now.

[ghost]

Mentioned while talking with Mark just now: one consideration here is the difference in usage between measurement and annotation.

If I'm using a region to measure a distance, I expect that distance to be displayed accurately. So if I have a line which is 50µm long, I expect it to be 50, not 54 with 2µm linecaps at each end.

If I'm using it to draw something purely for presentation, e.g. a hand-drawn outline around a feature, then I might start to consider aesthetics; but even here the use of linecaps would be limited. We have included features like this historically because it mapped onto the jhotdraw svg model; but they don't really have a place in the domain we're modelling here. We might, as part of future work, wish to separate regions by their purpose, e.g. measurement and annotations, which can potentially influence the renderer by choosing between accuracy (for measurement) and presentation (for annotations).

Removing these SVG-specific features also aids future work to have multiple implementations of the ROI rendering, i.e. OMERO, OMERO.web, OpenGL, WebGL, etc.

[will-moore]

I think you can have a lineCap without affecting the accurate length of a line.
In OMERO.figure the lineCap (I presume this means Arrow head) fits within the end points of the line (I think ImageJ does the same):

I think we do need lineCap, since we otherwise wouldn't be able to store arrows at-all, right?

[mtbc]

No, I thought arrow heads are markerStart/markerEnd, #18.

[mtbc]

I'd interpreted linecap to be about something like http://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Reference/PSL2s.html#setlinecap.

[will-moore]

Ah, OK - sorry. I think we can just get rid of lineCap then. Seems unnecessary for us to implement the display of this in all clients, for no real reason. Purely cosmetic.

[mtbc]

The current plan is to just drop LineCap from OME-XML and strokeLineCap from OMERO.

[mtbc]

Fixed by ome/bioformats#2286 in ome/bioformats@a7e189d and by ome/openmicroscopy#4533 in ome/openmicroscopy@37ae205.