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
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Feature

Sign in to add a comment

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

Reported by, 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:

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.


Comment 1 by, Jul 2 2012

Labels: -Area-Undefined Area-UI Feature-DevTools

Comment 2 by, Aug 7 2012

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.

Comment 3 by, Aug 7 2012

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.


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, Oct 15 2012

Labels: -Area-UI Area-WebKit
Status: Assigned

Comment 5 by, Oct 18 2012

Labels: -Type-Bug Type-Feature

Comment 6 by, Nov 6 2012

 Issue 159403  has been merged into this issue.

Comment 7 by, Nov 6 2012


Comment 8 by, Nov 8 2012


Comment 9 by, Nov 14 2012

The feature is put on hold until this will be done:

Comment 10 by, Mar 10 2013

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

Comment 11 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 12 by, Aug 15 2013

Status: Started

Comment 13 by, Aug 21 2013

Project Member
The following revision refers to this bug:

r156505 | | 2013-08-21T21:44:21.230609Z

Changed paths:

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.


Review URL:

Comment 14 by, Aug 22 2013

Attaching a screenshot as a current implementation of the UI
136 KB View Download

Comment 15 by, Aug 22 2013

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.

Comment 16 by, Aug 23 2013

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.

Comment 17 by, Aug 23 2013

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

Comment 20 by, Aug 27 2013

Status: Fixed
This has successfully landed in Canary.

Comment 21 by, Aug 30 2013

 Issue 231001  has been merged into this issue.

Comment 22 by, Aug 30 2013

Status: Assigned
Re-opened for future UX improvements

Comment 24 by, Aug 30 2013

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:

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.

Comment 25 by, Sep 2 2013

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.

Comment 26 by, Sep 3 2013

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.

Comment 27 by, Jun 3 2015

 Issue 236268  has been merged into this issue.

Comment 28 Deleted

Comment 29 by, Sep 7 2015

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.

Comment 30 by, Dec 18 2015

Labels: Cr-Platform-DevTools-Editing

Comment 31 by, Mar 23 2016

Components: -Blink

Comment 32 by, Sep 29 2016

Components: Platform>DevTools>Authoring

Comment 33 by, Dec 10 2017

 Issue 570726  has been merged into this issue.

Sign in to add a comment