Non-breaking spaces appearing as extra-wide spaces

  • kokkieh · Staff ·

    would still like to see the nbsp funkiness addressed in the product. I get this behavior in both the classic and new editors. I have detected three circumstances when I can fairly reliably get an nbsp to remain in the text:

    1. After typing a comma
    2. After pressing ctrl-i or ctrl-b to itailicize or boldface
    3. In existing text, selecting a word and typing a different word in its place.

    I do all of these things all the time and would surely like it if the editors did not leave those nbsp’s in the text, to avoid any unfortunate rendering around line breaks and such. I hope you all can give this some attention.

    As I said, I think this might be intentional behaviour, but I’m following up on that and will let you know if I hear anything new.

    Meanwhile, have a great weekend.

  • kokkieh · Staff ·

    I was just informed that the font issue has been previously reported as a bug in Chromium. They fixed it at that time, but it seems to be back:
    https://code.google.com/p/chromium/issues/detail?id=454108#c1

    I’m not familiar with Chromium at all, but if you are you could perhaps report the problem to them as well, as this affects any site using Neuton, not just WordPress.com (we were also, for example, able to replicate this in CodePen).

  • jimgrey · Member ·

    Thanks, I opened a bug with Chromium.

    FWIW, I’m unable to reach the Customizer in Chrome today, but can do it all day long in Firefox. Font changes I made there are not reflecting on Chrome, but do on Firefox.

  • kokkieh · Staff ·

    Hi, Jim

    Sorry for the delay. Are you still having problems with the Customizer in Chrome? It loads for me, so most likely the problem is something local. Have you tried the usual cache/cookies routine?

    When I view your blog it’s still displaying the Neuton font, but it also appears your settings are still to display that font.

  • jimgrey · Member ·

    Hi Kokkieh,

    The challenge with the Customizer was transitory; it’s fine now.

    I’ve left my blog on Neuton for now as I am going to share this whole thing with my QA team at work as a troubleshooting case study.

    After that, I’ll change fonts. But I’m also considering changing templates, as I’ve just had challenge after challenge on Photolia. I’ve been experimenting with Ryu and I think I can make it work.

  • kokkieh · Staff ·

    I’m glad to hear it’s working now.

    I hope your case study isn’t titled “how not to do troubleshooting”. I’m fairly new at this ;)

    I’m sorry to hear the theme has been giving you so much trouble. Let me know if there’s anything else I might be able to help with.

  • jimgrey · Member ·

    This was great, actually. We got to the bottom of my issue, and I learned a lot about how WordPress works and how it interacts with various browsers. Good stuff. Thanks for all your good work!

  • kokkieh · Staff ·

    You’re very welcome :)

  • jimgrey · Member ·

    Just closing the loop on this. It turns out that the Neuton font has a glyph for the nbsp that is wide, and with a recent on-purpose change, Chrome renders nbsps using the font’s nbsp glyph.

    > As of chrome 38 we use the non breaking space glyph from the font if
    > available, in some fonts a non-breaking space has a different width
    > than a regular space. That is as expected and up to the font author.

    Here is the Chromium bug report I wrote, in which you’ll find that comment.

    https://code.google.com/p/chromium/issues/detail?id=569054

    So this is an artifact of the Neuton font itself and how Chrome renders it, and has nothing to do with either WordPress.com or the Photolia theme.

    I consider this matter resolved.

  • jimgrey · Member ·

    p.s. Though I do still question why WordPress leaves nbsps in the text in the first place, and would like to see my earlier thread on that topic resolved.

1 2
  • The topic ‘Non-breaking spaces appearing as extra-wide spaces’ is closed to new replies.