CSS3 Fonts at TypeCon ========================
Here are my rough notes from the TypeCon CSS day with John Daggett. Nothing should be taken as a direct quote of the speakers who are supposedly associated with this text as my own thoughts are interwoven with their points, the person switches around between they and I and we all the time… Basically trust nothing. I made them for my own reference and publish them in the hope you might find them interesting but they must not be relied on. If anyone wants anything changed, please email me! dave@lab6.com. Happy hacking :P
John Hudson: CSS3 font module has 2 key aspects, @font- face and OpenType Font selection; we want to focus on that today and not web font formats.
John Daggett: I have a slide deck but feel free to interject questions. Some things are mundane - its a spec afterall - but hopefully some of it is interesting.
I am a developer working on FireFox, and working on the CSS3 fontspec. Discusion happen online, on www-font@w3.org mailing list. That's a good reference.
I'm going to cover:
* W3C Spec process * Font selection in CSS * mechanics of @font-face (but not font formats or rendering) * New OpenType feature support
W3C Spec process -------------------
CSS 1 (1996) was very basic CSS 2 (1998) was very sophisticaed, with @font-face, font- stretch came in CSS2 CSS 2.1 (2002-) was started to slim down all of CSS2 into what was actually implemented; @font-face was one of these things removed CSS 3 (2002-) is a set of independently evolving modules CSS 3 Fonts (2008) is such a module with @font-face and OpenType modules.
CS3 fonts will defint @font-fac emore narrowly than CSS2, for better interoperabilty and consistency between browsers, and richer typographic controls.
dev.w3.org/csswg/css3-fonts/ is te Editors Draft, where you can see the latest version I am working on.
Font selection in CSS -------------------
Choosing a font starts with font-family, a fallback list where the first that exists is used, and if none exist you use a UA defined default
37signal.com uses this, on Mac you see Helvetica and on Win you see Arial.
A font family name is definied in TrueType funky. TrueType can have multiple localisations, which is used in Japan - latin only and japanese names for same font. Browsers use platform APIs for font family matching, and they allow broad matching..... so you will have to say "Arial Bold" "ArialBoldMT" with font-weight:normal to select that font family. APIs also don't support locales properly; a Japanese locale machine will match a japanese named family but an english locale won't match.
Win GDI limied family groups to "normal, bold." But you have numeric values, 100 ... 900 and bolder/ligher relative values. But most apps only have bold/italic toggle buttons for selecting font fmaily members.
So there's "M+" a libre font for japanese with 9 weights. http://en.wikipedia.org/wiki/M%2B_Fonts
Helv Neue has a range. Helv Neue LT Std in Font Folio 11 has 8 weights, but the weighting starts at 250 not 100, and this allows GDI autobolding to "helpfully" adjust the weight for members with a value <= 200. . So Apple treats the usWeightClass as unreliable, and sniff the name for the weight value.
Q: Where did 100...900 come from?
I think ISO. If you have a font with more than 9 weights, some will be hidden/dropped. Or if you add new intermediate weights and then the numbering changes... If you have a specialised app relying on this weight classification you have a problem. There mny kinds of bolds...
So when you use the strong tag you want it to be bolder than the surrounding text. Idea is you adjust the weight of the parent, but in a 2weight world bold is on or off. So the weight to be used depends on the content; if you have japanese text among a latin paragraph, they may have different numbers of weights. This generated a lot of disccsionss, and the solution is to have a fixed mapping:
inherited value bolder lighter 100 400 100 200 400 100 300 400 100 400 700 100 500 700 100 600 900 400 700 900 400 800 900 700 900 900 700
John Hudson: what if you have a fmaily with more than 9 weights?
Adam T: If you have 100,300,500, and from 500 you say lighter, it will become 100 not 300?
Yes. This is a potential problem. But you can always specif the weight, not use relative, to get 300.
Adam: If you ask in CSS for 400, and the platform has 350 and 450, what happens?
We dont specify how to round down, we just say that they must not be out of order; they must count up from light to heavy
Okay.
Then there is font-style, and that can be normal, italic, oblique, and oblique is usually treated as synonymous. Families with both are rare. Computer Modern from TeX has both, and its important to distinguish for maths. That's the sole reason this exists here, and that has been ecliped by Unicode having ranges for those chars.
So we have this problem with rendering APIs have always said that they can synthesise the bold and italic. Authors say "I was unaware there was no bold futura on my machine" - and there is no typographic tradition of italics in Japan, but now if they are not supplied, users will complain.
Adam: Photoshop added "faux bold" options because people wanted it!
Its a troubling situation, browsers will use them. If a font has 100 and 400 weights, sometimes a browser will synthesise
Raph: WebKit adds horizontal space when synthetically bolding fonts, Firefox doesnt. Is making that consistent in scope for CSS?
Interesting point. There is existing behaviour and its hard to change that. I'd rather make it explicit for people to use real font familys and not use faux ones.
Futura on OSX10.5 has no bold; it has 4 faces: condensed extar bold, condensed medium, medium, medium italic. So browers fake a bold by smearing a regular face, and fake italics by obliquing. The bolding is done by drawing twice, and now we have transparency in CSS, fake bolding mixed with a blend changes the color!
font-stretch is really the width, its new in CSS3, and uses valuesin the usWidthClass names (condensed, expanded) - and I _do-not_ wnt synthetic.
Q: whats wrong with that?
The selection algos get complex. and you may not want to fallback to something autogend, like in latin it might be ok but in japanese it wouldn't be good.
Synthetics could be fine, but it should be a separtate property; geometric/styling ones. there are transforms you can apply to text, synethics should belong there.
So for large font famile, OSX ha "nameID1" only. Windows has 3, first is nameID1 with the family name but only the basic 4 members. then you have nameID16 with 16 members. Then when there are really large families, you need ANOTHER name, nameID21 for WWS family names: "all the face in a family, weight/width/slope, are grouped." Arno Pro has optical sizes.Bold, Bold Caption, Bold Display, Bold Condensed, are hidden into "bold" on windows. Similar in Japanese Osaka and Osaka-Mono can't be distinguished.
Font Family Name has to map to the nameID1 since that's what users see and know.
JH: not many nameID21 fonts are out there
Adam T: FontLab 4.next will support this better, certainly will in FL5. nameID1 is equal to the combination of nameID16.
So we could say browsers must respect these names, but people will put the name they see in their OS menus and expect it to work.
Tom Phinney: if mac users design sites to work on windows, they will need to know differences.
Yes, and the other way.
Mechanics of @font-face (but not font formats or rendering) ---------------------------------------------------------
CSS2 had intelligent font mapping; panose numbers, etc, and when you went through fallback you coul dpick more intelligently what to use.
This was too complex for what people wnted to do. the spec wasn't the sole point of faliure. font develoers fought to make a 50k file 30k back then.
Chris Lilley: PANOSE isnt veyr good except maybe for latin. we got half way on PANOSE2 but fossilised. you could have a huge @font-face with many things.... it was good to remove it.
@font-face has a child font-fmaily that DEFINES a string to be used in real font-family properties. and so was a whole . Its totally under author control, and mnothing in the font data effects it. So I can say "arial" and browsers should use this for all arial instances on the page.
Adam: This has been used: Tim Ahrens did FontFonter, a tool that allows you to enter a URL and you get a FontFont wbefont as your body type. it injects a CSS that overwrites all system font names with a url() src'd font. Ikea Futura website ;)
THis is not system-wide, it per-document, and this this for security, and also what proprietary font vendors want.
Richard Fink: If a document never uses a font, will the font referenced in the stylesheet be downladed?
I think thats for UAs to decide.
Chris Lilley: FOUC?
Q: will fallback stop being common?
In latin maybe, in non latin probably not.
Q: how to obsolete this?
Vendors to ship platforms with presinatlled font libraries.
JH: or offer fonts for download and installation.
Yes, BBC supports many languages no longer have to provide a font to download and install.
Web video is using a lot of bandwidth, fonts are pretty small today.
So heres a way to define multiple weights, you had 3 @f- f stanzas for reg bold and black, where the name, url and weight values are set. Some font services dont match the font to the css properties correctly. Some hand off to the platform API to do this, which is unreliable.
I did a test case where you invert the weight values; firefox is the only one that gets it right. For local its more likely to fail. The point it it should match based on what the CSS author has defined, not on what the OS says.
format hints can be added to src: properties in @ff. unknown formats are skipped and truetype and opentype are synonymous. if you dont mark it, the browser will detect it, but if you mark it and a brwoser thinks it doesnt know how to handle that format then it will skip the download.
Phinney: a WOFF can be either OT or TT?
Adam: a WOFF capable UA must understand both OT and TT.
ChrisL: PFR/EOT war meant it was there because it could have mattered, now its a historical footnote.
Vlad: OFF sets different conformance levels.
Jhudson: can we reference an OFF conformance level in the WOFF spec?
Vlad: Sure.
Phinney: we care about distinguishing these, to ship OT to mac and directwrite, and truetype to older browsers. we'd like to make this ditinction in WOFF.
Adam: We know how to sniff already, anything we add to WOFF will not be specific enough.
WEbKit will not download a .EOT file. UAs are not meant to do this.
Adam: one web font service generates URLs without extensions.
The real problem is that there are no font mime types. that will eb the best way to detect it. the ideal is to have font-ttf font-* but the top level of mime type is set.
vlad: i was told if we have enough real support, a strong interest from W3C and members, and the groundwork was laid in ISO, as much as MIME dont like it they might do it.
adam t: can we add this to the Web font WG agenda?
vlad: charter has an 'toerh deliverables' section.
right, so if you can look at the mime type you can do more stuff. PFR has a mime type! application-something.
vlad: you could argue that some formats have a specific application attached, so applicatiln is a proper place.
adam t: if woff is a w3c standard it cant be like that.
chrisl: font format top level mime type was proposed, and when that got serious push back we added this to CSS, but now it seems things have hcanged
i and howcome talked to them too and martin dutst (?) siad it would take a long time.
You can use Local Fonts if available with """ src: local("Gentium"), url(fonts/gent.ttf); """ and download if not. defined using fullname or Postscript name. it allows access to ALL faces.
So if you want to ue Gentium Bold, you have to say "Gentium Bold" as a font has localised family names and you dont want the UA to maintain a database of all fonts' localised names.
The Mac is Postscript name based, that's there unique name scheme, and you can search on fullname too; GDI can only use fullname.
So: Put the fullname, put the postscript name. and you'll be good.
When you have a font-family name, its mapping to the whole family, and local is mapping to a unique member of the family with a uniqe name.
Composite fonts with unicode-range. actual rane is the charmap in the font, intersected by the ranges specified with this propoerty.
jh: many scripts use latin punctuation. you'll want punc from thai font when in thai text. language tagging can do this?
...
same origin restrictions: WOFF spec will say this is required, CSS font spec defines the mechanim but doesnt require it. this means fonts will only be loaded from the same domain. if you run a font library you must allow anuone to do so with CORS. same protocol, domain and port! so you need to serve fonts over https or use CORS to allow.
# apache exmaple <FilesMatch "\.(ttf|otf|woff)$"> <IfModule mod_headers.c> ...
Font Loading: timing of font loading? common page structure is to link to a JS and CSS file. this happens fast, the resources lik eimagesn and fonts take a while.
Safari how a blank page with default metrics. (underlines will be shown on those default metrics ;) Firefox shows fallback fonts. I think we'll end up with a hybrid thing with blank for X seconds and then fallback for more than that until the font arrives. Problem is latency is mostly things other than downloading data. so smaller filesize doesn't win too much.
Japanese font handlind: Japanese fonts are LARGE. 23,000! They fonts are print orientated. OTF, fewer TTF. complexity of glyphs means cost is high. not all browsers support vertical layouts and metrics. web fonts are very different to print fonts in japan; latin can be more easily converted. hinting is a huge process!
Microsoft sent out a ClearType Meiyro promoting.
www.decomoji.jp is the japanese typekit. So you could take the top 3,000 chars by frequency of use and put them into a "jis-1" font and associate that with a jis-1 unicode-range property, then the rest in a much bigger jis-2 font, and use unicode-range "jis-2" for tat. so that the big jis-2 font would only be downlodaed if it is needed by the chars on the page.
New OpenType feature support --------------------------------------
So this is the big thing.
Howcome and Adam Twardoch and Tal Leming started it. Etan Wexler also proposed something similar.
idea was ot have properties to enable AAT or OpenType featuers. AAT can be compressed with WOFF when its in SFNT format. starts with OT but can be extended.
** WHAT ABOUT GRAPHITE FONTS? :) **
font-variant becomes shorthand for subproperties.
no sythesising (except for compatiblity) - prefer to fallback to default glyph if variant glyph/feature isn't available. Smallcaps is such an exception.
font-kerning: normal|none|auto - i wanted kerning on by default, safari wanted off by default, and auto allows them to do what they do. author can say "normal" and even safari will use kerning.
JH: can we use something other than "auto" - autokerning means something unusual to type people...
thats usual in this area. if text engines get faster, auto will mean ON more likely.
JH: a useragent with an autokerning system could misinterprit it?
authors want to evaluate the reults by looking at a browser and finding similar results in another brower.
font-varient-ligtuares: control over common, descretionary and historical ligatures. no value impled by default, common on by default and decr+hist off.
font-variant-alternates: see the editors draft URL for examples of all of these. some take a numeral selector and if none is used (1) is implied.
font-variant-caps: "small caps" "petite caps" etc. Note that all-small-caps is differnt to small-caps+text- transform:lowercase
adam: you can use the low level setting to set smcp(0) and then it wont use it.
chrisl: worth noting in the spec's examples?
...
font-variant-east-asian: control over CJK variants and WIDTH features. but some are not defined as im not sure this is the right place.
font-feature-setting: still in flux, but allows arbitary control of low level faetrures. id like this to be as simple as possible, and extensible... but not defining something does not make it extensible. you can set this in an @f-f rule and that sets the default features "on" for all uses, that can be overrridden further down the cascade stack. ... having this is convenient, but it will complicate things.
language support: OT fonts can have lang specific features, like turkih ligatures, etc.
** Firefox 4 Beta supports these font-featrure setting! **
I expect IE9 to implement as the system API is there.
adam t: harfbuzzng?
yes, complex script for arabic and indic is handled by platform shapers at the moment, latin/cjk/etc is harfbuzz (????)
okay, font security!
iphone unlocking exploit was done with a font in a pdf for code injection. as downloadable fonts are more common, we'll see more of this. coretext and uniscribe hasnt been tested. hackers are very smart, they will play with font tech.
so, a bug in a font engine will crash on a bad or malformed font data. sometimes brower core, sometimes system code. some crashes just suck, some are lethal when a buffer overflow happens, when random data is executed. they can form that rnadom data so when a bug is hit their code is run. you can do "font fuzzing" to tweak fonts to find crashes, and they dont do it very fancy. charlie miller will run 5 lines of python to fuzz 4 applications and find all kinds of things. firefox security team is working on this kind of thing, perhaps uniscribe on windows is better than coretext on osx/ios.
*** how does this effect a font developre? browsers will get stricter with fonts! minor validation errors may cause your font to be rejected. today chrome has an opentype validator; it will strip out the main table and rebuild it, throw out unkwnon tables including GDEF GPOS GSUB (which is a problem for internaional scripts!)***
Raph: you can run your fonts through chrome on the command line, I recommend this. its on code.google.com "OTS" and international fonts are being worked on.
Security matters. recently in the news, cars have wireless tire pressure sensors that can be hacked and could lead to a car being crashed!
A few other ideas!
* size baed font selection - david berlow led this. * better hyphenation - some JS techniques for this * font-scale, font-extend? - jkew said that scale would be a specific property for synthesisiing sizes (?)
jh: some engines use no hinting, some use hints selectively in some directions... david berlow has suggested PPEM specific outlines. (?) here are my slides for my presentaiton. ... an issue is that textblocks can reflow with different outline and metrics, so zooming in the textblokc changes, thats annoying.
adam: gvar and multiple master? ;)
hrant: if the zoom is 100%, use the native ppem font; otherwise use the default outline
jh: yes, if you can be sure that you can tell what 100% is. with adaptive layouts we might be unable to be sure. there are many ways to specify size in CSS and none specify PPEM. you must know size and resoltuion
adam: px?
sergey: no. are device pixels in the spec?
jh: ive said "size specific outlines" - they could all be inthe same font file with a mechanim to select them. the difficulties of getting it work mean its unlikely to happen. but the effect is so much clearer, its really better this way.
adam: iphone renders veradna worse on iphone4 than iphone3; the stroke are too thick. the pixels on iphone3 give a good weight.
jh: 96-100dpi screens will stay around a long time.
hrant: is a 300dpi printer good enough?
jh: yes if your font is designed for 300dpi!
hrant: we want this because we're not achieving the potential of screens today. its a technical issue with reflow and scaling; perhaps it can be solved. but the point is that we are not doing what we could.
jh: with @f-f i expect the wbe to be less readable; naievity of font selectoin by web authors, also the first offerings of font developers rushing to market, licensing fonts for the web, people havent come up with font as good as verdana and georgia. stuff going to market now isn't as good and it will take time for the market to improve. until we see serious revenue, how much will we invest in web font families with high levels of readability?
raph: veranda poor at hig res? when you move to a hi res world the tradeoffs are different. font scaling technology gave a poor mans optical scaling, so the contrast was increased as you went into larger sizes. so the ability to do this poor mans optical scaling with hi res screens mean you lose this. so a veradna like font LOOKS different to the outlines in a low res world. so you need to rbing back 500 year old technology, with thicker outlines and different spacing, for fonts used at small sizes. at 96 dpi, you dont see nmuch, but at 100-200dpi displays, you get a big payoff. i'd like to see that supported.
csyle: what about the fonts made for 300dpi printers?
raph: 300spi printers had specific things; 2 outlines for optima and how that was problematic we can remember. the need for optical scaling isn't device limitations, thats what best for the human eye. we still want the benefits of optical scaling.
adamt: printer is 300dpi shades of grey reflective media, screens with 300dpi are different. you had fixed point sizes in metal too. fluid moving and scaling of text is not discrete jumps between siezes.
raph: this is a deeper discusison, i want to vote for size specific PPEM with a narrow technology window. if we do it right at 96dpi, but the need for optical scaling has a longer time frame and i would love to see plannig for that, maybe not this spec.
jh: i agree, these are separate things. optical scaling is more adressable. you could do it now, you have Adobe optical pro font, and you specify in CSS what to use.
raph: yes, we want CSS to give you the sepatrtion beween contenta nd presetnaiotn. so in css3 we want family choice to maintiant content-pres sepataoin, and also DEFAULTs are important. we want templated sytlesheets that naieve designers can drop in and find thtat body text uses a goo dbod font, and headlines use good headline fonts. optical scaling being baked ino the family name means that islost.
jh: the sizefeature in OTL is a hack; itsnot teh right place. GPOS features are run late in the text layout. ... we have talked about a SIZE table. when we were planning OpenType 1.6, david below drafted an idea for a size table, which was complicated. we need a simple solution to do what you are talking about. something to revisit. vlad, is OFF due an update at any time?
vlad: nothing atm, process works by sufficient number of feature/improvements needed, then it will happen.
jh: from a technical perspective for speccing a table, who would like to be invovled?
tal: is that addressing a real problem?
jh: opticla scaling, yes
erik vb: its decided that its a table and so on seems blazing ahead
raph: i hitnk its more in css than opentype; its about selecting the right font for ajob. when you are 36pt you want headline fonta nd at 8pt you want caption fonts.
vlad: if you scale brower window, css wont know its scaled....
raph: i recommend the prezoom size... this is a deep conversation.
jh: where it intersects with opentype, weight numbers, data in the font can be mapped to CSS.
hrant; optimal size differs depending on how far away you hold it.
jdag: this sounds like font technology, not css
adamt: the OFF format claims to be scalable; but thats just simpoly geometric. we tried glyph variations in Multiple Master. weight isn't something to happen in fluent MM way, but scaling is. you want to adjust it fluently; having a set of dicrete outlines is a complete dead end. bringing back MM or GVAR for optical scaling only, is I tihnk the only sensible solution to the problem.
hrant: screen is made of dots.
tom phinney: its 1730, should we block time in typecon to chat size stuff for an hour?
jh: okay, this session is over, tonights event starts at 7pm.