2

I have a website where I would prefer to use &shy ; (soft hyphen) to break words the way I want.

Click here for screenshot from Chrome

The problem computers run OS X (multiple versions) and the problem occurs in both Chrome and Safari (multiple versions). Computers with exact same OS and browser version can show this differently. The screenshot is taken on OS 10.8, with Chrome v. 21.0.1180.75.

It looks like soft hyphen works, because it divides the word, and insert a hyphen "-", but it also generates that rectangle with the cross.

The website uses @fontface, if that should have anything to do with it.

Thank you!

nle
  • 57
  • 1
  • 9
  • 3
    It is possible that the character is missing from your chosen font family. – Jared Aug 09 '12 at 17:18
  • 1
    The crossed out box means that the render encountered a missing character in the used font. Try using another (default) font to see which character it's supposed to render at that position. – Torsten Walter Aug 09 '12 at 17:22
  • What does the markup contain in detail? Just `effekter/­animasjoner`? Or did you try to enter the soft hyphen character as such? In any case, the soft hyphen should *not* be used here, because such expressions, when divided into two lines, should not be hyphenated but simply divided after “/” (use e.g. `` for that). But the technical problem remains and is relevant in situations where the soft hyphen is used. Support to it in modern browsers is generally very good, so there is probably something special going on. – Jukka K. Korpela Aug 09 '12 at 19:35
  • Thank you for your answers. @Jukka: Yes, just that. I just picked a long word for testing. Anyways, I did some digging, and as far as I can tell the HEX code for the hyphen character is 00AD (which can be defined in css). I checked the open type font (we got the webfonts from the font foundry, but I guess they converted them from the OTFs) and there was no HEX code assigned to the hyphen character. I checked other fonts, and they have the 00AD assigned correctly to the hyphen. Could this be the the issue? And is it possible to verify in the webfonts (eot, svg, svgz and woff) somehow? – nle Aug 09 '12 at 20:17
  • @nle, if the data contains U+00AD and not the entity reference `­`, it is quite possible that character encoding problems emerge. So I would first test with `­` instead. I don’t quite get the reference to CSS – do you mean that you are adding soft hyphens with CSS generated content, or what? Anyway, the presence or absence of a glyph for soft hyphen should not matter, but browsers have their oddities. For an analysis, probably an actual URL is needed. – Jukka K. Korpela Aug 09 '12 at 20:31
  • @jukka: It's you that have the extensive website about the subject, right? (http://www.cs.tut.fi/~jkorpela/shy.html). What I ment about the CSS, is that you can use `-webkit-hyphenate-character:"\00AD";` (or any other hex) to specify which character to use (only for webkit). I must admit I'm in a bit over my head on this one. And a few months back I mailed the font foundry and font designer about the issue, but since it only showed on very few machines, I let it go. But this week it became an issue again on multiple machines (for some weird reason). – nle Aug 09 '12 at 20:42
  • I can try to set up a dummy site, and try to recreate the issue. It would be nice to figure out the issue. (I prefer not to "out" the website here). – nle Aug 09 '12 at 20:54
  • [Here is the fonttest website](http://bit.ly/QKaPSP) and here is [a screenshot](https://img.skitch.com/20120809-bfaxt1fntbp6cpijspmqix9tuf.jpg) of the page on OS X (10.8) with Chrome v. 21.0.1180.75 (I tested this on another Mac, with the exact same OS and Chrome, and it showed correctly. So I have no idea why it only fails on some) – nle Aug 09 '12 at 21:18
  • Hmm, some of the key links are dead; this makes it hard to really follow the question now... – SamB May 14 '16 at 16:56

3 Answers3

3

I've investigated this at length on soft hyphen bug in Webkit. In short the problem seems to be a combination of a bug in Helvetica Light (and some other fonts such as Avenir) and a font stack bug in Webkit. You can fix it by including Arial in your fontstack, eg.

font-family:"Apercu Light", Arial, sans-serif;

Richard Rutter
  • 131
  • 1
  • 2
2

Especially considering your fonttest website, it seems that the problem is caused by two factors: some WebKit browsers on OS X a bug that make them render a soft hyphen character inside a line of text using a glyph for it, instead of just treating it as a control character; and the StagSansWeb font either has no glyph for it (making the browsers use a dummy glyph) or have an odd-looking glyph for it. If these browsers additionally treat the soft hyphen as allowing hyphenation, this would explain the symptoms, provided that Helvetica has an empty glyph for the soft hyphen.

This is highly speculative, or conjectural.

On a more solid basis, the rendering of text where hyphenation has taken place has not been rigorously defined in standards. If browsers apply hyphenation on foo­bar, they are supposed to render “foo” followed by a hyphen at the end of a line, but the standards don’t say which hyphen. It could be HYPHEN-MINUS (i.e., the Ascii hyphen), or HYPHEN, or even SOFT HYPHEN, if it has a glyph. Maybe even something else. And it may even depend on language, as some languages have hyphens of their own.

So it is understandable that WebKit browsers have started supporting the proprietary property -webkit-hyphenate-character. However, it does not seem to be properly implemented. Testing -webkit-hyphenate-character: "\00AD" on Chrome and Safari on Windows 7, I notice that they “hyphenate” words (containing soft hyphens) without adding any hyphen (as if they used an empty glyph), even though other values for the property work OK.

To conclude, I would expect that you can avoid the issue by avoiding fonts like StagSansWeb for texts that may get hyphenated. It is possible that the problem can be fixed by modification to the font.

Jukka K. Korpela
  • 195,524
  • 37
  • 270
  • 390
  • Great, I really appreciate this, Jukka! :) The only thing I think is really strange is that it renders different on the exact same software. We prefer not to change the font, due to it is the brand font. I will take this matter up with the font foundry and see what happens. – nle Aug 09 '12 at 22:30
  • A small update: I got new font files from the Foundry, and they sorted out the issue. Thank you all again! :) – nle Aug 13 '12 at 11:40
  • As of Chrome Version 57, when used for hyphenating ASCII characters, Chrome renders glyph for HYPHEN-MINUS character, even if the used font has a separate glyph for SOFT HYPHEN – andrybak Apr 04 '17 at 12:17
2

I had the same issue happening on webkit/mac. The foundry that created the font helped me and gave this solution that worked (Added Arial)

font-family:"Apercu Light", Arial, Calibri, sans-serif;

instead of

font-family:"Apercu Light", Calibri, sans-serif;

This as an interim solution until the font files are updated. I assume Arial has better support than helvetica on webkit/mac for this particular case.

joe_g
  • 685
  • 1
  • 6
  • 17