model: specifying font #19

mtbc opened this Issue Feb 11, 2016 · 13 comments


None yet

6 participants

mtbc commented Feb 11, 2016

On in OMERO Shape has a few font-related properties:

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

The OME-XML schema at 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?


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?


I am guessing the best is to match CSS style font-*

mtbc commented Feb 17, 2016

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.


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?

@sbesson sbesson added the model label Feb 24, 2016

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:

ghost commented Feb 24, 2016

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

mtbc commented Feb 24, 2016

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

ghost commented Feb 24, 2016

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:

MacOS X Cocoa font descriptor:

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 commented Feb 24, 2016

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

ghost commented Feb 24, 2016

@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.


I agree with @rleigh-dundee. fontStyle with:

  • regular
  • bold
  • italic
  • bold italic

should be enough for most use cases.

mtbc commented Feb 26, 2016

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 mtbc referenced this issue in openmicroscopy/openmicroscopy Mar 17, 2016

adjust OMERO for OME-XML Shape changes #4533

@mtbc mtbc closed this Mar 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment