| 12:42 | <gsnedders> | Hmm… Coding, or "The Time Traveller's Wife"… |
| 13:35 | <Philip`> | gsnedders: I suggest playing games instead |
| 13:50 | <Philip`> | Every time I think my font stuff is working, I find more brokenness :-( |
| 13:51 | <Philip`> | Currently a font containing just "i" fails to draw the character's dot in Firefox on Linux |
| 14:07 | <hsivonen> | sigh. font-variant: small-caps; interaction with @font-face is borked in Gecko, WebKit and Presto |
| 14:09 | <Philip`> | Ooh, I made a font that crashes Firefox |
| 14:09 | <Philip`> | (on Linux) |
| 14:31 | <Philip`> | ...though interestingly it crashes when the text is 2em, but not when it's 1em |
| 14:32 | <wilhelm_> | Feel free to send me a list of the webfonts issues you find in Presto, and I'll follow up. |
| 14:36 | <hsivonen> | wilhelm_: Presto seems to have a bug analogous to https://bugzilla.mozilla.org/show_bug.cgi?id=475240 |
| 14:36 | <hsivonen> | (WebKit, too.) |
| 14:36 | <hsivonen> | the test case isn't great, since it depends on another bug being present (https://bugzilla.mozilla.org/show_bug.cgi?id=458634) |
| 14:40 | <hsivonen> | test case now fixed |
| 14:40 | <wilhelm_> | Thanks. |
| 16:01 | <Philip`> | http://lists.w3.org/Archives/Public/public-xhtml2/2009Jan/0080.html - "we were on a presentational-markup-purge kick for a while a few years ago." - hmm, does that mean they don't really mind presentational markup now? |
| 16:06 | <Lachy> | perhaps it means that some are starting to realise that a overzealous separation of semantics and presentation doesn't really solve any problems and can make the resulting language impractical in some cases |
| 16:18 | <Philip`> | It's really confusing writing code containing Hebrew/Arabic text, because my text editor likes replacing "{" and "(" with "}" and ")" when they're adjacent to RTL text |
| 16:23 | <Philip`> | roc: I see that Firefox isn't clever enough to handle "i<span style=color:red>̀</span>" correctly :-( |
| 16:32 | <Lachy> | Philip`, that depends what you consider to be the correct rendering. |
| 16:33 | <Lachy> | at least Firefox combines them correctly, even if it doesn't get the color right. Opera gets the color correct, but doesn't combine them |
| 16:33 | <Philip`> | Lachy: Clearly it should be an ì but the accent should be red |
| 16:34 | <Lachy> | if that's possible to implement, then sure. |
| 16:35 | <Philip`> | I don't care about whether it's possible to implement |
| 16:35 | <Philip`> | That's just an implementation detail |
| 16:36 | <Philip`> | Actually I'd be pretty surprised if it really was possible to implement |
| 16:37 | <Lachy> | it depends if it gets rendered as two separate glyphs overlayed on each other, or whether it gets rendered as the single i with grave character |
| 16:41 | <Philip`> | In the font I'm testing with, the font contains instructions that say i followed by combining-grave should cause the i to be replaced with a dotless-i glyph, and then gives instructions on how to position the combining-grave relative to the dotless-i |
| 16:42 | <Philip`> | which I suppose wouldn't make it as impossible to implement as it would be if i plus combining-grave was replaced with a single i-grave glyph which is composed of the dotless-i glyph and the grave glyph |
| 16:42 | <Philip`> | (which I think is what some other fonts do) |
| 17:18 | <Philip`> | Hmm, excellent - IE8 appears to render ligatures when my content is on a remote server, but fails to do so when exactly the same content is on my local server |
| 18:14 | <roc> | a lot of fonts have precomposed forms for common accented characters |
| 18:16 | <roc> | but you're right, we don't style the parts differently even when we could. |
| 18:17 | <roc> | still, the most important thing is that the combining marks be combined properly, which we do get right while other browsers (with the possible exception of IE?) do not. |
| 18:46 | <Philip`> | roc: IE doesn't seem to combine them properly - it draws an i with a dot and the accent |
| 18:47 | <Philip`> | As far as I can tell, WebKit pre-composes the combining marks with the previous character into a single codepoint before passing it to the font renderer |
| 18:47 | <Philip`> | (at least in cases like i-grave where there is a pre-composed codepoint it can use) |
| 18:49 | <Philip`> | (and at least on OS X; it seems to just go crazy on Windows) |
| 18:50 | <olliej> | Philip`: have you filed bugs? :D |
| 18:50 | <gsnedders> | olliej: Of course not :P |
| 18:51 | <Philip`> | olliej: No, I've just moaned on IRC :-) |
| 18:52 | <Philip`> | http://philip.html5.org/tests/font/combining-chars.html |
| 18:52 | <Philip`> | http://philip.html5.org/tests/font/combining-chars-safari-win.png |
| 18:52 | <Philip`> | are the problem, I think |
| 18:53 | <Philip`> | so I suppose I should stop being so lazy, and just file the bug :-) |
| 19:06 | <Philip`> | Oh, it works in WebKit nightlies |
| 19:11 | <olliej> | Philip`: victory! |
| 19:22 | <Philip`> | olliej: Don't think you'll get away with it that easily! |
| 19:24 | <olliej> | dammit |
| 19:24 | <olliej> | i had such hope :D |
| 19:27 | annevk | wonders if CSS defines rendering for i<span style=position:absolute;top:100px>̀</span> |
| 19:27 | annevk | assumes it does not |
| 19:29 | <Philip`> | http://philip.html5.org/tests/font/combining-chars-2.html - now what's all that about? |
| 19:30 | <Philip`> | In Safari on Windows, all the hashes in the second line have vanished |
| 20:18 | <annevk> | http://webbackplane.com/mark-birbeck/blog/2009/01/rdfa-means-extensibility o_O |
| 20:19 | <annevk> | "The WHATWG for example are pursuing a much more monolithic approach with HTML5; they see no need for extension points, since the language itself will cover everything." |
| 20:21 | <annevk> | He doesn't even explain what the concerns are with the RDF approach, just some musings on that the microformats and WHATWG community are against it |
| 20:24 | <Dashiva> | adding a footer element to a language takes time, and requires jumping through all sorts of hoops (...) But adding a footer role value takes no time at all, and you don't need to ask anyone. |
| 20:26 | <Dashiva> | How to reconcile this with "we need namespaces for everything to avoid collisions" |
| 20:35 | <takkaria> | hm, Drupal is incorporating RDFa |
| 20:35 | <takkaria> | with faux-namespaces |
| 21:54 | <Dashiva> | Two lastweek entries in a row without references to bodily functions, oh ho |
| 22:18 | <Philip`> | http://news.bbc.co.uk/1/hi/uk/7850173.stm - "... The disk, which was mislaid in December by courier firm TNT, contained names, salaries, national insurance numbers and bank account numbers. But the British Council said the data could not be accessed as the disk was securely encrypted." |
| 22:19 | <Philip`> | It seems pretty silly to complain about people losing data when the data was encrypted |
| 22:19 | <Philip`> | because the whole point of encryption is that it doesn't matter if other people end up with a copy of your data |
| 22:20 | <Philip`> | and if you complain anyway, you remove the PR incentive for people to use encryption |
| 22:22 | <danbri> | there's some pretty lame encryption around though |
| 22:24 | <danbri> | & there are tools like http://www.softsea.com/review/Zip-Key.html if the encryption uses a lame password |
| 22:24 | <Philip`> | I suppose that's a good point |
| 22:25 | <Philip`> | but it seems the more reliable solution is to make sure you have decent encryption and decent passwords, rather than attempting to stop humans losing discs |
| 22:25 | <Philip`> | but then the encryption process has to be set up and maintained by humans, who will probably do it wrong |
| 22:25 | <Philip`> | We should just get rid of humans |
| 22:26 | <Philip`> | and as a bonus there wouldn't be any people whose data you could store and then lose |
| 22:34 | <annevk> | there's a fallacy in there somewhere |
| 22:34 | <hsivonen> | so many @font-face bugs in so many browsers :-( |
| 22:39 | Philip` | has given up trying to make his test page work on OS X without crashing |
| 22:39 | <Dashiva> | hsivonen: They're outsourcing the QA |
| 22:39 | <Dashiva> | (to you) |
| 22:44 | <Philip`> | Oh, and now Firefox is rendering the word "Deja" with no dot on the j :-/ |
| 22:44 | <Philip`> | (s/Firefox/Pango/ probably) |
| 22:44 | <Philip`> | Seems like there's a lot of cases where the OpenType spec doesn't prohibit weird things, but implementations break if you do those weird things |
| 22:44 | <Philip`> | e.g. if you have empty glyph-classes |
| 22:46 | <hsivonen> | we need OpenType5, clearly |
| 22:51 | <Philip`> | Or we need to only have experts producing OpenType files |
| 22:52 | <Philip`> | which seems to have worked alright for the past decade |
| 22:53 | <gsnedders> | And not assholes like Philip` |
| 22:55 | <Philip`> | Indeed |
| 23:00 | <Philip`> | Hooray, 'j' works |
| 23:01 | Philip` | is getting fairly quick at guessing what Pango objects to, and hacking his code so it outputs something just slightly less weird |
| 23:19 | <Lachy_> | Hixie, yt? |
| 23:20 | <Lachy> | Hixie, I started writing up a draft for the about: URI scheme http://lachy.id.au/dev/specs/about-uri/draft-lachy-about-uri-00.txt |
