[Photoshop CC 2015] Font style field is disabled, but shouldn't be

  • 1
  • Problem
  • Updated 4 years ago
In Photoshop CC 2015 I've noticed a weird bug.
If I got a text with different font styles, then the font-style field is disabled on the main panel, but it still works in the Character Window:
Photo of Johnny Snow

Johnny Snow

  • 38 Posts
  • 3 Reply Likes
  • sad

Posted 4 years ago

  • 1
Photo of David

David, Official Rep

  • 3143 Posts
  • 499 Reply Likes
Hi Johnny,

What you're seeing is correct behavior.  When attributes do not match, they are suppressed, in order to indicate the mismatch to you, the user.  If the two words had different point sizes or colors, those fields would also be blank / indeterminate.

Thanks,
David
Photo of Johnny Snow

Johnny Snow

  • 38 Posts
  • 3 Reply Likes
The top field is not just blank. Unlike the bottom field that is just black, the top field is disabled.

So this is inconsistent behavior. One field is enabled, another one is not. But both fields do the same job.
They both should be enabled.
Photo of David

David, Official Rep

  • 3143 Posts
  • 499 Reply Likes
No, actually, this is consistent behavior.  The field is disabled for a reason.  It's indicating to you that the fonts have different attributes (one looks like it's bolded).

Keep in mind, a bolded version of Courier is literally a different font (it is a separate file, linked only by name) from Courier Regular.  The field here is disabled because there's no way for the app to know if the two fonts which you've selected both have all the same attributes available (bold, italic, oblique, semi-bold, etc), so to prevent a bogus, inconsistent result, it's disabled until the font is selected.  It's been this way for a VERY long time...

Thanks,
David
Photo of Johnny Snow

Johnny Snow

  • 38 Posts
  • 3 Reply Likes
I know about different font files. But it doesn't matter.

This is still inconsistent behavior because the user still can change a font style from the Character panel. But he can't do it from the top panel.
How come?

Why 2 equal field have different behaviors?
http://i.imgur.com/TJAvh22.png
Look at the picture. I tried to explain what I mean.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
You're saying that it should indicate a mixed state, but the control should not be disabled so that you could change the state if you wish?
Photo of Johnny Snow

Johnny Snow

  • 38 Posts
  • 3 Reply Likes
I'm saying that both of those fields should behave equally.
They both should be enabled.
Photo of David

David, Official Rep

  • 3143 Posts
  • 499 Reply Likes
Actually, Johnny, Chris is correct.  It is true that the two controls aren't quite behaving the same way, but there's a long, complicated reason for that.  If you did NOT have a text box with mismatched stuff in it, you would get consistent results in both fields.  And, I suppose this could appear buggy, but really, it's not -- the panel is trying to give you the chance to make your text "uniform" while the option bar doesn't check that level of detail..

Thanks,
David
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
I think that both the panel and options bar should both be enabled so you can change the text, even if it doesn't currently all have the same state (which is shown by the blank contents). Plus, we really need something better than blank to indicate a mixed selection/state.
Photo of Johnny Snow

Johnny Snow

  • 38 Posts
  • 3 Reply Likes
Totally agree with Chris ))
Photo of David

David, Official Rep

  • 3143 Posts
  • 499 Reply Likes
We use blank all over the app to show "unknown" or "mixed" state.

The UI discrepancy here is due to architecture and age.  The Character Panel used to show the current value and was updated now to show the selection (or blank for mismatch), populating the dropdown with what's available.  The newer Options Bar follows the model used in other parts of the app and indicates a mixed state with a blank box and further disables the font style if the font face doesn't match.  Sure, it could be fixed if we rewrite all this, but I think there are much bigger fish to fry...particularly given the age and limitation of the existing type engine.