model: specifying font

[mtbc]

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

• fontFamily
• fontSize
• fontStretch
• fontStyle
• fontVariant
• fontWeight

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

• FontFamily
• FontSize
• FontStyle

For OMERO 5.3 to harmonize with OME-XML would it be okay to drop those other three (in bold) from OMERO and assume that anything important they would have been used for can be expressed using the remaining properties? Or, would some different course of action be preferred?

[gusferguson]

@mtbc It seems strange to have fontStyle but not fontWeight. Certainly when labelling some histology slides for screenshots of OMERO.learning I have used bold font, but it was not critical. @aleksandra-tarkowska - what do you think?

[atarkowska]

I am guessing the best is to match CSS style font-* http://www.w3schools.com/cssref/pr_font_font.asp

[mtbc]

So one proposal is to drop just fontStretch?

Though, CSS is non-trivial and I expect we also want freedom to move away from JHotDraw: there's the larger issue of what is important to encode in our actual model, against what micro-presentation features we can avoid requiring of new/other rendering engines. I guess it depends partly on if the model is mainly for recording measurements and analysis results or also more for the kinds of things that OMERO.figure might offer.

[joshmoore]

My primary concern would be the consumability of these. Previously, we likely went too far down the road of adding properties. Will all clients be able to implement what's here? With SVG as a model, that wasn't the case. Will CSS be ok or still too flexible?

[will-moore]

I would have thought that we could drop fontStretch and fontVariant (since this is just for small-caps)? That should be enough for most cases, without supporting all of css. NB: one feature request I had for figure was labels that allowed some characters to be in italics (not the whole label) since that's how genotypes are usually presented, although I'm not currently planning on supporting this user seemed happy enough to workaround: https://trello.com/c/BNjiEiAZ/46-labels-italics

[ghost]

What's the difference between style and weight? Isn't weight part of the style? e.g. "Bold Italic"

[mtbc]

Not in CSS but we could certainly allow "bold" in our "style".

[ghost]

I would suggest that simplicity needs to be the goal here. Fonts are hard, and being CSS-specific is going to be as constraining as being SVG-specific. These are some APIs in common use which could be used by a renderer:

Qt: http://doc.qt.io/qt-4.8/qfont.html Windows: https://msdn.microsoft.com/en-us/library/windows/desktop/dd183499%28v=vs.85%29.aspx MacOS X Cocoa font descriptor: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontDescriptor_Class/index.html#//apple_ref/doc/uid/TP40004042 Fontconfig: http://xfree86.org/4.3.0/fontconfig.3.html#sect5

Given that we are not modelling a full drawing and font rendering API, I would propose that we keep the model to the bare minimum here. I'd suggest that an enum which maps onto all the above APIs would be sufficient. It could be as simple as "bold" and "italic". I don't think having to cope with arbitrary style and weight metrics (including numeric and text value mappings) is something we should be doing!

[sbesson]

@rleigh-dundee: so your proposal would be a single fontStyle (or fontXXX) property, is that correct?

[ghost]

@sbesson Yes. I'd suggest that it be restricted to a list of enumerated values such as regular bold italic which individual renderers can easily map onto their platform-specific font API. This ensures that its scope is clearly defined, and that it's simple to implement.

Edit: we might want to ensure that the object is annotatable to allow application-specific annotations for renderers which want to support extended attributes here.

[will-moore]

I agree with @rleigh-dundee. fontStyle with:

• regular
• bold
• italic
• bold italic

should be enough for most use cases.

[mtbc]

The current plan is to drop OMERO's fontStretch, fontVariant, fontWeight. In OME-XML FontStyle is already an enum of Bold, BoldItalic, Italic, Normal so it includes weight: I suggest we leave that as it is as better not to perturb something that is already by and large good enough.

[mtbc]

Fixed by https://github.com/openmicroscopy/openmicroscopy/issues/4533 in https://github.com/openmicroscopy/openmicroscopy/pull/4533/commits/be1ae87d8b79c6b9e2ab0db9c5806d75f75b5070.