nbsp character is passed to nsFontMetrics GetTextDimensions

NEW
Assigned to

Status

()

Core
Layout: Text
14 years ago
8 years ago

People

(Reporter: Brian Ryner (not reading), Assigned: dbaron)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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().
Are there any issues in measuring complex text where the non breaking space
would cause a different layout?
(Reporter)

Comment 2

14 years ago
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;
(Reporter)

Comment 3

14 years ago
Er, make that "I don't think so", in response to "Are there any issues"
(Reporter)

Comment 4

14 years ago
Created attachment 162039 [details] [diff] [review]
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.
(Reporter)

Updated

14 years ago
Attachment #162039 - Flags: superreview?(dbaron)
Attachment #162039 - Flags: review?(dbaron)
(Assignee)

Updated

14 years ago
Attachment #162039 - Flags: superreview?(dbaron)
Attachment #162039 - Flags: superreview+
Attachment #162039 - Flags: review?(dbaron)
Attachment #162039 - Flags: review+
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.
(Reporter)

Comment 6

14 years ago
(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

14 years ago
(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 )
You need to log in before you can comment on or make changes to this bug.