- From: Richard Fink <rfink@readableweb.com>
- Date: Tue, 8 Sep 2009 16:19:17 -0400
- To: "'Jonathan Kew'" <jonathan@jfkew.plus.com>, <info@ascenderfonts.com>
- Cc: <www-font@w3.org>, "'Sylvain Galineau'" <sylvaing@microsoft.com>, "'Tal Leming'" <tal@typesupply.com>, "'Erik van Blokland'" <erik@letterror.com>
Tuesday, September 08, 2009 Jonathan Kew <jonathan@jfkew.plus.com>: >Sorry, Mozilla "try-server" builds expire after two weeks, so this is no longer online. Jonathan, Color me confused and concerned. I've been using the Minefield build with EOTL support all weekend, freshly downloaded from here: https://build.mozilla.org/tryserver-builds/jkew@mozilla.com-try-cdcb63f9c65c /try-cdcb63f9c65c-win32.zip But I had a bit of trouble with using the raw files all by themselves and, first, had to use the windows installer package of Minefield located here: https://build.mozilla.org/tryserver-builds/jkew@mozilla.com-try-cdcb63f9c65c /install/sea/try-cdcb63f9c65c-win32.installer.exe I installed it under a separate profile to prevent messing up my other FF installs, overwrote the contents of c:\program files\Minefield with the zipped files, and it's been working great. Thanks. What a pleasure not to have to bounce back and forth between IE and FF. I've just written about EOTL (or should we begin calling it CWT at this point?) at http://readableweb.com and was going to follow up in a few days with instructions for those looking to install Minefield and if those files are going south I'd really like to know. If they do disappear, are the ones I've downloaded redistributable? Further along these same lines, I understand from https://bugzilla.mozilla.org/show_bug.cgi?id=507970 that you've done a build with WOFF support. Great. However, although I know you've published the spec, is there, as yet, a tool for converting TTF or OTF files into WOFF files for testing? And lastly in this vein - the $64,000 question - how soon can we expect a build with support for WOFF and EOTL(CWT) side-by-side? >I took a quick look at the "Mayberry" page (sample 3), and I notice >that the "preview" code displayed on the page does not in fact >correspond to the CSS that is actually used for the extended family. >For the latter 4 faces, the CSS actually uses separate family names, >rather than using the true family name and relying on the descriptor >values to identify the proper faces. Is this an oversight, or was it a >hack that turned out to be necessary in order to get the desired >rendering? Quick catch. I'm just getting into the CSS syntactical issues and IE's behavior in regards to EOTL as opposed to the standards-compliant syntax and behavior. However, my first impression of the Mayberry Sample 3 page is that those involved decided to present the CSS for each weight as if that weight was the only Mayberry font being used on the page. In that, I think that Ascender's page might be somewhat misleading to those who would use it as a guide to working with multiple weights of the same name using EOT in IE, let alone squaring that with what Firefox and other standards compliant implementations can and will do with the same syntax. But frankly, font-linking as a practical proposition is so new, I don't know of anybody who's mastered all the ins and outs. I'm also under the impression that IE has some issues with numerical weight properties, period, which might complicate matters. Time to go digging and get the facts. Of course, this "differential" between FF's implementation and IE's @font-face implementation and/or other CSS shortcomings needs to be thoroughly understood and explained. As I said before, this issue seems to be getting solved by the font services folks, so I assume - hell, *I know* - that DIY folks like me will also figure it out and codify what's best practice. Something akin to "@Font-Face: A Guide To The Perplexed" can't be far off. And insofar as font-linking using EOT files in IE goes back to when most web developers I deal with were still in puberty, the word "hack", I feel, is unfairly negative given the long history. We've known since day one that workarounds were going to be necessary. But the benefits are great. We've had to work around worse. And I can't believe IE won't get @font-face in line with the spec in IENext. (Sylvain?) Please, please let us know about the status of WOFF tools, WOFF and EOTL(CWT) side-by-side, etc. as soon as is practical. I don't want to do anybody a disservice by publishing incorrect info. I've heard of the five second rule (http://en.wikipedia.org/wiki/Five-second_rule), but the two week rule is a new one! ;) Regards, rich -----Original Message----- From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Jonathan Kew Sent: Tuesday, September 08, 2009 12:56 PM To: info@ascenderfonts.com Cc: www-font@w3.org Subject: Re: EOT Lite (Compatibility Web Type) - sample web pages On 7 Sep 2009, at 23:45, Bill Davis wrote: > We made a variety of web pages to demonstrate EOT Lite fonts in > action. They showcase simple headline fonts, extended font families > and fonts with larger character sets. > > http://www.ascendercorp.com/web/web-font-examples/ > > The pages can be viewed in Internet Explorer and the Firefox > minefield version that Jonathan Kew posted a few weeks ago (but the > download link does not appear to be active). > > I know some folks have noted issues/challenges with formatting font > families in IE - not sure if our approach is 'correct' but it > appears to work fine in our testing. We made it easy to preview the > code. Look forward to comments from you all. > I took a quick look at the "Mayberry" page (sample 3), and I notice that the "preview" code displayed on the page does not in fact correspond to the CSS that is actually used for the extended family. For the latter 4 faces, the CSS actually uses separate family names, rather than using the true family name and relying on the descriptor values to identify the proper faces. Is this an oversight, or was it a hack that turned out to be necessary in order to get the desired rendering? JK
Received on Tuesday, 8 September 2009 20:21:30 UTC