New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 28 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Feature



Sign in to add a comment

Dev Tools Feature Request: show which font from the font stack is actually being used for render

Reported by blordstu...@gmail.com, Jul 2 2012

Issue description

Often font stacks are long and complicated. And often two similar fonts are tricky to distinguish.

There is a chrome plug-in that does a decent job of what I'm asking for:

https://chrome.google.com/webstore/detail/jabopobgcpjmedljpbcaablpmlmfcogm

But the plugin feels like toolbar clutter for a very basic feature. There are also some clever tricks on Stack Overflow. But again, needlessly complicated.

It would be great if we could just get some kind of visual indicator in the computed styles pane of the Element Inspector. For example, all the fonts in the stack except the used font could be rendered with an overstrike. This feature would be very much of-a-piece with the existing functionality and interface.

Thanks.
 
Labels: -Area-Undefined Area-UI Feature-DevTools
The history of this issue is that text has font fallthrough. If a certain typeface doesn't contain a particular glyph that's needed it falls through to the font beneath it. This is why crazy unicode symbols still work with your webfont; because it's falling through to your system's base font, which supplies the actual glyph.

So that's generally why devtools doesn't point out which font is in play.
I do know Opera does a fairly good job at this feature though.

I realize that per-character rendering is the big wrinkle in the pudding here. Still, there's got to be a better way than the current implementation, which just hands you the whole stack with no info at all about what fonts are loaded and actually being used. Seems like the two big ways to go would be either:

a) On a per element basis. In other words, do what the plugin does. Of the loaded and available fonts, indicate which is topmost in the stack. This would be (conceptually) easy to integrate with the element inspector. It has the big limitation you point out: If a used character is missing a glyph in the current font, ach, so be it. Still better than the current situation, though.

or

b) On a per character basis. I have no idea if this would even be possible but I'm dreamin' out loud here. I want to be able to text-select individual characters in the render and see what font has been used to render them somewhere in Dev Tools. If it's "Apple Symbols" I'm seeing then please tell me so.  If more than one character is selected, and more than font is being used to render those characters, show me a list of all those fonts, so I can go through them manually to tease it out.

(I'm starting work on a multilingual reference encyclopedia-type site chock full of way- far-out unicode characters. The need is real.)

Comment 4 by yu...@chromium.org, Oct 15 2012

Cc: pfeldman@chromium.org
Labels: -Area-UI Area-WebKit
Owner: apavlov@chromium.org
Status: Assigned
Labels: -Type-Bug Type-Feature
 Issue 159403  has been merged into this issue.
Cc: vsevik@chromium.org lushnikov@chromium.org
Cc: apavlov@chromium.org
Owner: lushnikov@chromium.org
The feature is put on hold until this will be done: http://code.google.com/p/skia/issues/detail?id=977
Project Member

Comment 10 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Feature-DevTools Cr-Platform-DevTools Cr-Content
Project Member

Comment 11 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Status: Started
Project Member

Comment 13 by bugdroid1@chromium.org, Aug 21 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156505

------------------------------------------------------------------------
r156505 | lushnikov@chromium.org | 2013-08-21T21:44:21.230609Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector-protocol/css-get-platform-fonts-expected.txt?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/inspector/InspectorCSSAgent.h?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/cocoa/FontPlatformDataCocoa.mm?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/InlineTextBox.cpp?r1=156505&r2=156504&pathrev=156505
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector-protocol/css-get-platform-fonts.html?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/FontPlatformData.h?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/chromium/FontPlatformDataChromiumWin.cpp?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/rendering/InlineTextBox.h?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/protocol.json?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/harfbuzz/FontPlatformDataHarfBuzz.cpp?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/chromium/FontPlatformDataChromiumWin.h?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/inspector/InspectorCSSAgent.cpp?r1=156505&r2=156504&pathrev=156505
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/platform/graphics/harfbuzz/FontPlatformDataHarfBuzz.h?r1=156505&r2=156504&pathrev=156505

DevTools: Add CSS.getPlatformFontsForNode in protocol.json

This patch adds method CSS.getPlatformFontsForNode to the protocol.
The method returns platform fonts that were used to render child text
nodes for the given node.

BUG=135489

Review URL: https://chromiumcodereview.appspot.com/22923010
------------------------------------------------------------------------
Attaching a screenshot as a current implementation of the UI
platform-fonts.png
136 KB View Download
Can these glyph counts be noted along with the font-family computed style above? It seems awkward to create a secondary pane for the other part of computed font-family.
We've thought about it, but computed styles are rebuilt and collapsed every time you change a node or attribute. If you want to use this feature to bisect smth related to font rendering, it will get considerably more time.
I don't understand.. why duplicate "font-family: "Times New Roman"" and create a new secondary location for supplemental info that's associated with where everyone is pointing their attention?
Screen Shot 2013-08-23 at 2.29.12 AM.png
39.0 KB View Download
Status: Fixed
This has successfully landed in Canary.
 Issue 231001  has been merged into this issue.
Status: Assigned
Re-opened for future UX improvements
Thank you! This is a massive step forward in font tooling. It is great to see this actually landing. I have two thoughts:

1) Is it by design that descendant nodes aren't getting their glyphs counted? To be totally clear, for example look at:

http://jsfiddle.net/zaKph/

and inspect the outermost div. Look in Elements>computed styles, and you see only:

font-family: serif;
  Times Roman - 18 glyphs

which is obviously not taking account of the other two descendant "sans-serif" and "cursive" paragraphs. IMHO this is limiting, and also counterintuitive given the conventions of the DOM. For example, it would be great to be able to inspect the html element (or a root iframe) and see all the fonts used for render, on all descendant elements. If it's by design that any descendant node's glyph counts aren't going to be returned, then I second Paul's suggestion that the glyph counts be integrated into the existing nested list for computed 'font-family', just for visual cleanliness. (Though note that it's not "duplicate information" exactly, because "cursive" obviously isn't the same as "Apple Chancery" on a system other than a Mac, etc.)

2) The other limitation with this implementation so far is that it doesn't really offer a workflow for debugging glyph availability issues. Say for example that I need to set a long paragraph in Gujarati, a language I don't speak or read. (This isn't a contrived example, it happens in academic writing all the time).  I find a font the boss likes that covers all the standard glyphs, and another font that I don't love but covers some ligatures and symbols I think I might need. I declare them both in a stack. The current implementation might return me something like:

font-family: myGujarati1, myGujarati2;
  myGujarati1 - 300 glyphs
  myGujarati2 - 2 glyphs

Okay, great, Skia is returning the info, but how do I figure out which two glyphs are falling through? I could probably run a script to wrap every character in a (numbered) span, and iterate through them, checking. But that will get tedious really fast.

What would be exceedingly useful would be checkboxes to toggle the availability of individual fonts on and off in the render. In my example, I could simply check and uncheck 'myGujarati2' and immediately visually see what was going on. This is arguably beyond the scope of my original feature request, but since it's so closely related I thought it made to sense to describe it here.

Thanks again.
Thank you for the great feedback!
So would it be enough for your aims to see character codes that were rendered with myGujarati1 and myGujarati2? E.g. every entry of platform fonts would be expandable to reveal sorted list of character codes that were rendered with this font.
SGTM: an expandable list of all character codes of rendered characters, organized per font, collapsible/expandable. It would also be great to see the glyph itself, next to the character code, for speed of reference.
 Issue 236268  has been merged into this issue.

Comment 28 Deleted

I recently run into a case where I could not tell why a fallback font was used and I was hoping devtools could help me with my problem. The feature described in this bug thread was the closest I could get.

The problem I had was with a font that was used to draw icons. For example the font Icons might have had a little house icon stored as a glyph for character 'a'. The programmer would then write 'a' and set the font to "Icons" where ever a house icon was wanted.

For some reason the font would work when I would not define any fallback for the font. The working font-family definition would look as follows.

font-family: "Icons";

However when I defined a textual fallback font for rendering the 'a' character in case the "Icons" font failed to load I would never see the icons but everything would be rendered in the fallback font. This problematic font-family definition would look as follows.

font-family: "Icons", sans-serif;

The feature of displaying which glyphs are used seems useful but sometimes it would also be useful to know why those glyphs are being used. Thus I am wondering if it would be possible to somehow present the reasoning behind glyph selection in the same user interface where the selected fonts and glyphs are shown.
Labels: Cr-Platform-DevTools-Editing

Comment 31 by tkent@chromium.org, Mar 23 2016

Components: -Blink
Components: Platform>DevTools>Authoring
Cc: e...@chromium.org paulir...@chromium.org yio...@gmail.com drott@chromium.org
 Issue 570726  has been merged into this issue.

Sign in to add a comment