Closed mtbc closed 8 years ago
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.
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.
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?
No, I thought arrow heads are markerStart/markerEnd, #18.
I'd interpreted linecap to be about something like http://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Reference/PSL2s.html#setlinecap.
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.
The current plan is to just drop LineCap
from OME-XML and strokeLineCap
from OMERO.
Fixed by https://github.com/openmicroscopy/bioformats/issues/2286 in https://github.com/openmicroscopy/bioformats/pull/2286/commits/a7e189dc0945de5431d79648e8cde510a4e13a22 and by https://github.com/openmicroscopy/openmicroscopy/issues/4533 in https://github.com/openmicroscopy/openmicroscopy/pull/4533/commits/37ae20534d27f01aab6884e3172dbe33e12ac048.
On http://www.openmicroscopy.org/site/support/omero5.2/developers/Model/EveryObject.html#shape in OMERO
Shape
has a few stroke-related properties:The OME-XML schema at http://www.openmicroscopy.org/Schemas/Documentation/Generated/OME-2015-01/ROI_xsd.html#Shape has:
For OMERO 5.3 to harmonize with OME-XML we've thus already merged commits that drop:
There remains a question about what to do about
strokeLineCap
seeing as OME-XML names it onlyLineCap
:lineCap
to match OME-XML?StrokeLineCap
to fit the otherStroke-
properties?color
though?)For that last list item @rleigh-dundee makes an interesting point in https://trello.com/c/9ZsIFHcJ/38-discrepancies: