:( No hyphenation, kerning or leading. Knuth and Liang solved this problem decades ago. I dislike like having to hack it with Javascript. That lack is what makes web typography ugly, even in this demo.
You really have to remember it’s a demo – it’s not something that Adobe sells to publishers, today; it’s supposed to have the “wow” factor.
Incidentally, that article in the demo includes Adobe’s own glyph shaping&rendering solution, with things like stem darkening, subpixel rendering, linear blending of text. If you show it side-by-side with the “webkit rendering”, it’s relatively obvious that our text looks better. But guess what…. from all the people who see the demo live (because you can’t see this kind of text improvements on youtube) – nobody notices if we don’t explicitly show side-by-side text comparison. And even then, it’s a “meh, yeah, you’re right, it does look slightly better”.
Same for good justification – it’s computationally expensive. If we put better justification in a demo (we tried), the animation doesn’t look “cool”, it’s slower and the picture lags behind your finger. Maybe it wouldn’t matter in real-life because you don’t need to reflow text 10 times/second… but it makes a huge difference in a demo.
FWIW - my personal opinion is that it was a mistake to shoot the demo video on a mobile phone, the screen space is simply too small to render this kind of layouts. It should've been shown on a Galaxy Tab, it looks much better.
(oh, and AFAIK the demo does have hyphenation; it's just that the rendering space is so small, that hyphenation alone cannot solve the layout problems).
The good news is that at least it made a good first impression. As a technology it definitely looks cool and useful even if it doesn't do TeX quality layout at the moment.
I don't understand what you mean. I'm using the original vccv TeX algorithm in my Sweet Justice library and it works decently. There is also Hyphenator which uses Liang's algo and supports dozens of languages. The web case is very similar to the desktop publishing case.
Web/DTP is not the same thing at all. DTP is static. The web is dynamic.
You can envision some paragraphs of text in a blog post being re-flown but the web is more than that. What about interactive text? Text in SVG? Multi-language text in the same paragraph? Various stacks of text in varying z-indexes, css-3 animated? Text manipulated with Ajax? In a mobile browser AND in the desktop. Not so easy anymore when you have to cover all of those --and possibly in a W3C or HTML5 sanctioned way, compatible with concepts like "overflow" and all.
Can you point out some reasons the algorithms in TeX cannot apply to reflowing text in a browser, rather than a static page? It seems like a very similar context to me.
My understanding is that the reason WebKit does not use the TeX layout algorithm is performance. WebKit has a zero-tolerance policy on performance regressions; the only way the TeX layout algorithm will make it in is if it can do so without sacrificing rendering speed.
You tempt me to try submitting a patch. I suspect it's a bikeshed problem, but I could be wrong. There is no technical reason why you couldn't enable it only on elements with a "-webkit-hyphenation" CSS rule. Then it's not a regression, it's an optional feature.
You are right that there are real perf concerns. A web page reflows multiple (sometimes hundreds) of times during pageload, unlike a print document.
TeX was designed to work on computers of the late 1970's. It seems pretty reasonable to think that algorithms that were practical to execute then can be carried out more or less instantaneously on machines available today. If you think you can pull off a port, by all means try.
Web browsers could handle postscript in 1992, they should be able to handle tex now.
http://browser.is/?p=23
Disclaimer: The author of MidasWWW is my boss :)
This is an interesting demo, but it seems to focus more on "whizzy" things, instead of fixing more basic problem.
Now, in their defense, I thought the baseline alignment idea was pretty good. But if you look at their first demo of the "callout" text, you'll note that there are horrible rivers (open spaces) running through the type, making it look all clunky.
What's really needed is a straightforward wysiwig layout tool (like Quark or Illustrator, for example) that can generate clean CSS layouts.
Whoa. I'm surprised by John's rather dickish reply to this in the comments.
He totally could have (should have) taken the high road and recognized the lacking of good typography controls. And pointed out that this was just a tech demo and Adobe's excited to do all it can to improve type on the web.
Snark indeed. All of paragraph 5 could have been left out.
As for the communication part, there is a name which, because it is omitted with so much efforts, can only be noticed: Apple. They are working with Google to enhance Webkit, not Google and Apple, the originator of Webkit.
Apple was, apparently, so slighted by this ommission that we have to forget that Apple derived the WebKit code from KHTML. "Originated" is kind of a strong word.
Must admit, I was surprised to see all this publicity for the demo but they have not posted a patch nor shown their code changes to the folks who maintain WebKit's text layout code.
> The least they could do is have the q tag render with smart quotes
Fuck no. I will decide on the fucking quotes I want around my quotes, unless you decide to cleanly and perfectly support all international quote style guides[0], you do not touch the content I create and you do not start changing my quotes.
Web kit is a fail that has a tiny percentage of the browser use. Safari has too small of a % to be relevant (except mobile obv), and Chrome just screws up too many small things (despite being an otherwise overwhelmingly better browser than the alternatives).
And they're making deep inroads in libraries (QtWebkit, which means all of Nokia's future is likely linked to webkit as well) and embedded in software (Steam switched fully to webkit a while ago).
Webkit definitely isn't "a fail". Not in the long run (it will keep growing in importance) but not right now either, it's given a good kick to the 'nads to the Mozilla team, it iterates and develops fast (and is a standard driver), it's where innovation now happens in the OSS browserspace (the other source of innovation being mostly Opera) and the sole reason we have mobile browsers worth using these days is webkit. Webkit is a resounding success considering the first public release was 7 years ago and pretty dreadful.
I guess you ignored the part where I said except mobile obv.
My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with that both Safari and Chrome could've simply built a new UI around. Instead they gave us yet another OS to support.
Web developers complain all the time about supporting multiple browsers, yet support web kit?
And for the record, steam is a great example of what I'm talking about: completely mediocre rendering performance for really simple tasks (essentially a web browser). It's shocking how bad web content looks in steam, I'm kind of surprised you even brought it up.
Yes - Webkit long term will be good, it can't not (even IE9 is looking alright at this point). Right now though (ruling out IE6), > 50% of my web dev cross browser issues are dealing with web kit, not IE7+, and for a much less significant audience (ie: expensive).
So you're right, it's not a "fail," but I think how great the response is to it is really disproportional. I REALLY want to love chrome etc but I just can't - it's not ready yet.
> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with
Yes, KHTML. Ooops.
> with that both Safari and Chrome could've simply built a new UI around
Chrome is a new UI and JS engine tacked to webkit, they didn't create a new rendering engine.
> Instead they gave us yet another OS to support.
What?
> Web developers complain all the time about supporting multiple browsers, yet support web kit?
Web developers complain all the time about supporting shitty browsers, not multiple browsers. Since ~Safari 3, webkit-based browsers have been very, very good browsers, often superior to Gecko in terms of rendering quality and JS quality (and perfs). Furthermore, it got very fine dev tools by now, more than on-par with Firebug's in most arenas, to the point where a number of developers have switched to webkit as their main development platform and relegated Firefox to "also checked".
Not to mention, webkit-based browsers are the one offering the most new and interesting features for Making Cool Shit Easily (multiple backgrounds for instance). That's something web developers tend to dig.
> Right now though (ruling out IE6), > 50% of my web dev cross browser issues are dealing with web kit, not IE7+, and for a much less significant audience (ie: expensive).
You are doing it very, very wrong. This simply isn't something I observe. Quite the opposite in fact.
A year ago I got into a codebase which had been developed solely on and for Firefox for more than a year (crappers gonna crap), getting it into a useable form for Webkit took a few days, it's still barely useable for IE8 and entirely broken for IE7.
> So you're right, it's not a "fail," but I think how great the response is to it is really disproportional.
It's not.
> I REALLY want to love chrome etc but I just can't - it's not ready yet.
> My biggest issue with webkit is that there was a perfectly fine rendering engine to begin with that both Safari and Chrome could've simply built a new UI around.
You're right, there was. It was called KHTML, and they did.
Not that it really matters for the sake of the argument, because my point was that gecko was widely used already whereas KHTML was not and so they should've used it instead, but gecko was also around before KHTML.
He invented XUL, contributed to Gecko, wrote the initial version of Chimera (now Camino, one of the first real embeddings of Gecko), started the Firefox project, and started WebKit
He had a pretty fucking good idea of the pros and cons of Gecko when he decided not to use it again.
Actually, KHTML pre-dates even Gecko, given that it descended from the "KDE HTML Widget" KHTMLW. Even in 1997 this library was being developed (example email: http://marc.info/?l=kde-devel&m=88665877914652&w=3)
By 2002 or whenever Gecko was more widely used than KHTML but that doesn't really matter because it was harder to integrate into Apple's code. Apple even had to go so far as to write a KDE/Qt wrapper layer (KWQ IIRC) and it was still less work than integrating/fixing Gecko.
As another example, the lead Safari dev, David Hyatt is famous for (among other things) co-starting the Firefox project (called Phoenix at the time) so it is a very large stretch to claim that Apple simply ignored the better choice. Hyatt would have to go way out of his comfort zone to adopt something other than Gecko, and the fact that he did so anyways should say something...
When Apple announced that they were going to use KHTML in Safari (when they announced Safari) they stated that it was due to the library's small footprint. I assume that they didn't want to spend the time to reign in the Gecko engine to do what they wanted it to do (or hack/optimize it down to size).
Just because something exists and seems to be 'good enough' doesn't necessarily mean that it would be a good fit. Unless you develop for WebKit, Safari, Firefox and/or Gecko, I'm not sure any of us are really qualified to make those kinds of statements. Also remember that you can't compare the current state of the two codebases. You have to compare the state of the codebases at the time that Apple created Safari/WebKit.
> Not that it really matters for the sake of the argument, because my point was that gecko was widely used already
then maybe you should have said that
> whereas KHTML was not and so they should've used it instead
That's not really relevant, and Gecko's size and complexity make it a hard sell when you have long-term goals of appliances and embedded. Furthermore entrenched projects and interests means Apple would have had low if any say about the project's orientation, giving up heaps of control. So it made sense for technical, future-proof and business reasons to go with a KHTML fork rather than Gecko.
Gecko is not an HTML rendering engine, it's a Mozilla XUL+HTML rendering engine. It's a legacy codebase and not easily embeddable.
XULRunner and other developments are changing that but that still involves XUL. I'd love for a separate pure-HTML Gecko engine that competes with Webkit, but until that happens, there are technical reasons for choosing one or the either.
