Skip to content

Commit

Permalink
Bypass rendering of missing glyphs.
Browse files Browse the repository at this point in the history
1. on font initialization - creates font.missingGlyphs = string of all the available characters in the loaded font file
2. sanitize (to be valid regexp) and build font.missingGlyphsRegexp
3. on render process: if "part" (as defined in cufon call) has a missing char - then don't render it and pass it on normally.


This allows both non-rendered and renders fonts to be (unilke the original cufon which replaces non existing glyphs with $missingGlyph  (default blank))
  • Loading branch information
oori committed Aug 12, 2010
1 parent b647682 commit a1e1d91
Showing 1 changed file with 10 additions and 0 deletions.
10 changes: 10 additions & 0 deletions js/cufon.js
Expand Up @@ -339,6 +339,12 @@ var Cufon = (function() {
return glyphs;
})(data.glyphs);

this.missingGlyphs = '';
for (var i in this.glyphs) {
this.missingGlyphs += i;
}
this.missingGlyphsRegexp = new RegExp("[^" + this.missingGlyphs.replace(/[-[\]{}()*+?.,\\^$|#\s]/g, "\\$&") + "]");

this.w = data.w;
this.baseSize = parseInt(face['units-per-em'], 10);

Expand Down Expand Up @@ -618,6 +624,10 @@ var Cufon = (function() {
if (/\s$/.test(text)) parts.push('');
}
for (var i = 0, l = parts.length; i < l; ++i) {
if (font.missingGlyphsRegexp.test(parts[i])) {
fragment.appendChild(document.createTextNode(parts[i]));
continue;
}
processed = engines[options.engine](font,
needsAligning ? CSS.textAlign(parts[i], style, i, l) : parts[i],
style, options, node, el, i < l - 1);
Expand Down

7 comments on commit a1e1d91

@sorccu
Copy link

@sorccu sorccu commented on a1e1d91 Oct 27, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's a good idea to leave the whole "part" untouched if there's a missing character in it. Then again, doing the same for single characters would require a larger rewrite. Do you use this patch somewhere? I'd be interested to see it in real use.

@oori
Copy link
Owner Author

@oori oori commented on a1e1d91 Oct 27, 2010

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, on multi-lang site, i used to resolve this by an initialization function, that checks the string is english chars or not. But that was not bulletproof, it didn't really relate to the existing glyphs, nor did it do "parts".
see: http://www.kunsthalle-gwangju.com/assets/templates/khg/js/global.js function initFontReplacement.
switch to korean (in the top left) and you'll see it.

the patch i submitted is enhancing that idea - see which char "really" exists in the glyph and what not. (and keep it dynamic when using multiple glyphs).
It is currently in use in a large content site. most of it is member only, but i put a test string for you to see:
(url temporary removed - pm me to get it)
Look at "Some Test 1" - i added a non-english (hebrew) string to the title.
(that specific page is slow, but that has nothing to do with cufon or the above patch - validated with js profiler.. it has plenty of other reasons..).

about "leaving the whole "part" untouched if there's a missing character in it". I've tried different options, but i concluded with 'per-part' because:
a. design-wise it makes sense - as many times the rendered font and the browser font are so different..
b. "part" resolution is settable in cufon, and is respected by this patch. so anyone can decide as he wish.

The current cufon behavior ($missingGlyph) really doesn't do good to content, so even if you do not accept this patch - i suggest to find an alternative solution.

Thanks!

@groenroos
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm currently also using this patch in a project of mine. I cufónize user submitted input, such as names and titles. If you write a name entirely in hangul or kanji, absolutely nothing gets displayed. Still, the number of users who do is so irrelevant that I don't see myself including the 12 megabyte Korean font file into Cufón just for their benefit. So I think it's better to keep the Cufón font within western alphabet with accents and punctuation, and for everything else, fall back to regular ol' text -- substance over style, so to say.

@sorccu
Copy link

@sorccu sorccu commented on a1e1d91 Nov 6, 2011

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch will be pulled, but only after the experimental dev branch is stable enough. The new rendering method (in the dev branch) no longer messes up baselines if normal text and Cufónized text are placed next to each other. I'm not sure when this will happen but it'll be there.

@groenroos
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! :)

@tomasdev
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @sorccu any update regarding dev status of Cufon ?

@oori
Copy link
Owner Author

@oori oori commented on a1e1d91 Jan 5, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: this patch has been flawlessly used for over a year at www.platoon.org, a site that heavily depends on cufon.

Please sign in to comment.