We now have version control and bug tracking at launchpad:

    https://code.launchpad.net/typeface.js

Launchpad uses Bazaar, which is an easy, straightforward distributed version control system.  Here's a five minute introduction: 

  http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html

To get a checkout of the latest version of 'trunk' (like head in cvs) you can do like this:

    bzr branch lp:typeface.js

In 'trunk' there are most of the changes from here, everything except the :hover changes, which I needs some reworking:

    http://typeface.neocracy.org/forum/topic.html?id=153

These changes from Pete Bex are also merged in:

    http://typeface.neocracy.org/forum/topic.html?id=203
    http://typeface.neocracy.org/forum/topic.html?id=205
    http://typeface.neocracy.org/forum/topic.html?id=206

I'd also like to take a closer look at other patches that have been posted, and see about merging those in.  It would also be nice to get full support for IE8 soon too.

Hello, using a SCM is a very good idea !
I just want to give my contribution by adding support for IE8 :
I haven't installed Bazaar, so cannot make a patch, but the changes are really small:

Change the lines 657 to 665 to :

if (backend == 'vml') {
document.namespaces.add("v","urn:schemas-microsoft-com:vml","#default#VML");

var styleSheet = document.createStyleSheet();
styleSheet.addRule('v\\:shape', "display: inline-block;");
}

And add this between lines 357 and 358 :
parentNode.innerHTML = parentNode.innerHTML;

This is a stupid hack to make IE render the VML, there are maybe better ways to do that, but only the first word is renderer without this.

(David: did you receive my e-mail ? I sent it to you 1 or 2 weeks ago, I'd really like you to answer me)

Hi Fabien, thanks, that's great.  Those changes are checked in. 

I've been looking at this issue today.  It's too bad we have to use innerHTML there, but if it works, it works.  No other project seems to have a better solution at this point, including excanvas.js, from what I can tell.

Great thing david!

Long life to typeface =)

a simple workaround for IE8, in the meantime, could be include this meta to force ie8 emulate ie7:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

as told here http://blogs.msdn.com/ie/archive/2008/06/10/introducing-ie-emulateie7.aspx

Obviously that's not the final solution.

@avastreg
Typeface.js now works on IE8 with the latest trunk ;) and without the IE7 emulation

Yes, and it even works.  I'd like to make a release with all these new improvements, but I'd just like to do some benchmarking first.  Rendering on IE6 and IE7 now seems slower to me. 

If that's really so, we can just have separate paths in the code, keeping what we have in 0.11 for IE6 and 7, and then the new bits just for IE8.

I'll try and add timers to the test cases so we can see for sure.  Those are using HTML::Mason now, and I'd also like to make them pure javascript and HTML so other people can try them out more easily.

I saw you didn't remove the CSS rule with the default behaviour for the VML backend when you added the support for IE8, it isn't needed anymore (because it is present in the namespaces.add call), that's maybe the reason why it is slower, or the ugly innerHTML we had to add. I'm sure there is a better way to do that, maybe by only using innerHTML, or something else.
If you need help to find the reason it is slower, I can help.

I'm probably stating the obvious here, but my performance patch made it faster in all browsers but IE6/7, because they don't have the replaceChild method on Node objects.
The patch didn't make it _slower_ on IE6/IE7, though.

So if you do some benchmarking, be sure to compare the old version of Typeface with the new one on IE6, but don't compare the new version of Typeface on IE6 with the new version of Typeface on IE8.

Oh yes, I remember something now.

One thing that came to mind while I was hacking on the performance of Typeface, but didn't get around to trying out, was that Typeface is doing some parsing of the glyphs using String.split. It seems to me that it should be much faster if we can let the Javascript engine do the parsing; so we would have the Perl script that runs on the server generate a different file format - a JSON encoded glyph.

This means that we can cut out the code that parses a glyph and stores it in a cached_outline property, because glyphs are objects and do not have to be cached anymore. The "Math.round step" for IE would still need to be done of course, but it should speed things up across the board, for all browsers.

I didn't try it out because I think that the code isn't spending a lot of time in this piece of code, actually. Most of the time is spent in the actual rendering of VML strings or executing canvas commands. On the other hand, if the glyph outline is stored in actual objects, we don't need to keep an incrementor around anymore, we can just read out named properties of the object. This could make it just a bit faster again. It would also cause all loaded fonts to use half the amount of memory they do now.

If someone has the time to test this, it would be an interesting little improvement, though. I don't think I'll get around to this unless we start using Typeface more heavily in other projects.

If I'm not expressing myself clearly here, just let me know and I'll try to explain.

Hello Peter,
I understand what you mean, and that's a good idea, but ...
Using JSON to store the glyphs would make the face files much bigger, like 50% or 100% more than it is now. They are already big enough, IMO.
Of course, it would make rendering in IE much faster, but the download time (this first one would) really longer (except for fast connections).
I think we should try to find other ways to make it faster, but we won't be able to make IE a good browser.

Hi Peter, I actually did start out having the outlines in JSON so we wouldn't need to parse.  The code is nicer to look at that way, but IE6 actually performs much worse.  It seems incredible, but I found IE6 could actually parse strings with String.split() an order of magnitude faster than it could parse JSON natively.  For other browsers, they were only negligibly slower at parsing strings. 

As Febien mentioned too, it is nicer on the download sizes for the font files to use space-delimited strings.



Yes, I'm comparing IE6/7 against IE6/7.  It's the VML namespace changes / innerHTML hack that had me worried.  But in actual fact, things do seem to be a bit faster with the version in 'trunk'. 

Thanks again for the performance patch.  I actually meant to ask though -- this forum truncated your post so I couldn't read the last bit, having to do with using VML's native quadratic bezier paths.  When I try just using "qb" there with the end points and control points directly from the outline, at larger point sizes the rendering looks incorrect.  Curves that should be smooth end up having straight segments.  Is there something I'm missing?

I'm not sure about those larger segments, I didn't notice anything special but then again I didn't test it extensively either.

I hadn't realized my post was truncated :(  I'd post the code I have right now on Launchpad, but you haven't enabled Launchpad's bugtracker...

OK, I checked out the latest version of Typeface and it looks like you've successfully integrated all my changes except for the native quadratic bezier paths usage.  That code looks like this:

By the way, I created an Ohloh project page at https://www.ohloh.net/p/typeface

You can claim your maintainership there if you want, David.

Re: JSON-encoded glyphs; did you try encoding them as arrays, like they are decoded now?  That shouldn't bloat the file size much (string open quotes are replaced by left square brackets, spaces by comma's and string close quotes are replaced by right square brackets. It grows a bit because the commands ('q', 'l', 'm') are still surrounded by quotes).

I have a feeling that maybe IE object instantiation is slow.  If we make it _one_ array instead, it should be much faster.  Of course it doesn't change the code at all except removing the string parsing prelude, making it slightly faster.

Ok, I was wrong and in fact the font files could be just a few bytes longer (if not shorter). Even the quotes around 'q', 'm' and 'l' could be avoided, by just adding a few variables :



The new variables are in the global scope, a solution would be to use :



Note I also removed the double quotes around the glyph properties, as they are not required at all (but they must be kept for the font characters, of course).
So, not parsing anymore, and no object initialization. To be tested, but it could be a good evolution of the typeface font face format.

Interesting, I don't recall if I ever tried making the whole of each outline an array.  That seems like it's worth a shot.



Here are some screenshots -- the left column is using 'qb' and 'c' VML paths; the right column is cleartype's rendering.  It looks like 'qb' gets us close, but not quite all the way there:

http://typeface.neocracy.org/images/vml_qb.png
http://typeface.neocracy.org/images/vml_c.png

By the way, bug tracking is now enabled here:

http://bugs.launchpad.net/typeface.js/

You're right, that _is_ ugly.  Let's stick with the calculated cubic curve then :)

I just tested the optimization I mentioned above, and in fact it isn't worth it. I is a very little bit faster on Firefox and very similar under IE 8 (didn't test it on other browsers, but I can send you the font face file I hacked.
The optimizations in this topic : http://typeface.neocracy.org/forum/topic.html?id=216 are far more efficient and don't imply a typeface.js font file format modification.

I'd like to see it in IE6. Performance there is still extremely bad and any performance gain we can get away with would be nice.

Of course, if it's only marginal there too, it's not worth changing the format.

I will always be surprised by this "browser" : it is twice slower with this new format. I didn't forget to remove the split and the Math.round calls, of course.

Wow, funky!  Well, I guess we'll be best off keeping the format as it is :)

I've tested the trunk including 19 changes with IE8. It runs well except the letter-spacing. The spaces in between are very big. Where could I change the spaces in between?

I have double fonts. How  to crack  this problem? http://portfolio.mig-studio.net/test.html Thanks.