New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

model: specifying font #19

Closed
mtbc opened this Issue Feb 11, 2016 · 13 comments

Comments

Projects
None yet
6 participants
@mtbc
Member

mtbc commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gusferguson

gusferguson Feb 15, 2016

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

gusferguson commented Feb 15, 2016

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

@aleksandra-tarkowska

This comment has been minimized.

Show comment
Hide comment
@aleksandra-tarkowska

aleksandra-tarkowska Feb 15, 2016

Member

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

Member

aleksandra-tarkowska commented Feb 15, 2016

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

@mtbc

This comment has been minimized.

Show comment
Hide comment
@mtbc

mtbc Feb 17, 2016

Member

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.

Member

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.

@joshmoore

This comment has been minimized.

Show comment
Hide comment
@joshmoore

joshmoore Feb 23, 2016

Member

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?

Member

joshmoore commented Feb 23, 2016

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

@will-moore

This comment has been minimized.

Show comment
Hide comment
@will-moore

will-moore Feb 24, 2016

Member

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

Member

will-moore commented 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: https://trello.com/c/BNjiEiAZ/46-labels-italics

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 24, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@mtbc

mtbc Feb 24, 2016

Member

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

Member

mtbc commented Feb 24, 2016

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost 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:

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!

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:

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

This comment has been minimized.

Show comment
Hide comment
@sbesson

sbesson Feb 24, 2016

Member

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

Member

sbesson commented Feb 24, 2016

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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.

@will-moore

This comment has been minimized.

Show comment
Hide comment
@will-moore

will-moore Feb 24, 2016

Member

I agree with @rleigh-dundee. fontStyle with:

  • regular
  • bold
  • italic
  • bold italic

should be enough for most use cases.

Member

will-moore commented Feb 24, 2016

I agree with @rleigh-dundee. fontStyle with:

  • regular
  • bold
  • italic
  • bold italic

should be enough for most use cases.

@mtbc

This comment has been minimized.

Show comment
Hide comment
@mtbc

mtbc Feb 26, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment