238598 - nbsp character is passed to nsFontMetrics GetTextDimensions

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Brian Ryner (not reading)]

Right now, the text frame code may convert spaces back to nbsp characters prior
to measuring the text.  See nsTextFrame::RevertSpacesToNBSP and its callers.

This causes a performance problem on xft because in the (fairly common) event
that the best-match font does not have a character for nbsp, we fall back to
calling FcFontSort(), which is much slower, since it has to do a sort of all
fonts on the system.

I would say we should replace the nbsp characters with a space character
somewhere here, either in the text frame code or in nsFontMetricsXft::FindFont().

Comment 1

[Christopher Blizzard (:blizzard)]

Are there any issues in measuring complex text where the non breaking space
would cause a different layout?

Comment 2

[Brian Ryner (not reading)]

I think so, given this code snippet in Pango (pangofc-font.c):

  /* Replace NBSP with a normal space; it should be invariant that
   * they shape the same other than breaking properties.
   */
  if (wc == 0xA0)
          wc = 0x20;

Comment 3

[Brian Ryner (not reading)]

Er, make that "I don't think so", in response to "Are there any issues"

Comment 4

[Brian Ryner (not reading)]

Attachment: patch

We could also take care of this in nsTextFrame, but I don't want to penalize
platforms where the font implementation already handles this detail.

Comment 5

[Christopher Blizzard (:blizzard)]

What happens when you go to measure or render that bit of text?  Rewriting as a
space at that level means that you will still go looking for the non-breaking
space later on when it comes time to render or measure.

Comment 6

[Brian Ryner (not reading)]

(In reply to comment #5)
> What happens when you go to measure or render that bit of text?  Rewriting as a
> space at that level means that you will still go looking for the non-breaking
> space later on when it comes time to render or measure.

Hm, I'm not sure what XftTextExtents32() does when you pass in a character not
in the font.  Backing this out until I know for sure.

Comment 7

[Jungshik Shin]

(In reply to comment #4)

> We could also take care of this in nsTextFrame, but I don't want to penalize
> platforms where the font implementation already handles this detail.

Is it really handled well in other Gfx ports? At least, Gfx:Gtk (X11core)
doesn't handle it well (in case anyone cares )

Comment 8

[Jonathan Kew [:jfkthame]]

The code this was about no longer exists.