bramstein

Would love to hear or read more about this if it is public.

You can, but then you're limited to a single font format and you would not gain any benefits from the browsers' ability to download in parallel.

A lot of this will improve when HTTP/2 becomes more common (you can push resource to the browser and parallel downloads will become more efficient).

There are several hacks. Almost all of them rely on using JavaScript to make a XMLHttpRequest to retrieve font data. This will force the browser to load the fonts earlier by working around the normal @font-face loading mechanism.

Because you already have the font data in JavaScript you can then also store the fonts in localStorage. This way you can avoid making a request for them on the next page load.

Smashing Magazine wrote a bit more about this technique: http://www.smashingmagazine.com/2014/09/improving-smashing-m...

I'm generally against this idea because you're basically reimplementing the browsers' caching mechanism. The CSS Font Loading API (http://www.w3.org/TR/css-font-loading/) will let you do this in a much nicer way and it already has pretty decent browser support (Chrome, Opera and Firefox beta).

I agree, hyphenation is crucial to proper line breaking. If you don't mind a JavaScript solution you can have a look at:

* http://code.google.com/p/hyphenator/ * https://github.com/bramstein/hypher/

My colleague Tim Brown maintains a website containing links to all sorts of web typography resources: http://nicewebtype.com/

As mentioned above, Knuth's algorithms are implemented in many professional typesetting and layout applications. I think the people implementing those applications have great respect for Knuth (and Plass.)

My impression is that the users of those programs are unfamiliar with the algorithms used, so I think it is the latter.

I'm not totally sure, but I think the linear time papers I've read sacrifice some of the aspects of the original Knuth and Plass algorithm. I think some of those are going to be necessary to properly implement the Knuth and Plass algorithm in browser (also, floats are going to be interesting.)

The performance isn't actually that bad, I can perform line breaking in JavaScript on some very large documents, with the only performance bottleneck being DOM node creation (which native implementations won't suffer from.) If necessary the linebreaking could also be done incrementally, with a first first-fit pass and then the Knuth and Plass algorithm.

I could be mistaken, but I'm fairly certain Internet Explorer implements the Knuth and Plass algorithm when using `text-justify: newspaper`. Unfortunately, I can't check because it isn't open source. The output however is pretty much identical to what my JavaScript version generates, so I'm inclined to believe it is the Knuth and Plass algorithm.

I'm really excited about this. While it is not the Knuth and Plass algorithm, it takes one of the nice features of it and proposes a simple algorithm to implement it. Implementing it should only be a minor adjustment to the text layout algorithms of browser rendering engines, and if implemented correctly it should not cause any reflows, only a repaint.

I've been maintaining a jQuery plugin for the text-overflow property for a while. It works well in most cases: http://www.bramstein.com/projects/text-overflow/

You can see a test page here, which only works in Firefox due to the feature detection: http://www.bramstein.com/projects/text-overflow/examples.htm...

Author of the JS implementation here. Let me know if you have any questions about the implementation or problems integrating it. I was hoping someone would pick it up and integrate it with Readability-like service. (I've slowly been working to add support for it to Treesaver http://www.treesaverjs.com/.)

For hyphenation you might also want to check out my Hypher project (https://github.com/bramstein/Hypher) which is a minimal hyphenation engine written in JavaScript. In my benchmarks it is about 4 times faster than Hyphenator.js (and a lot smaller.)

Thanks for the reference. I have also recently released my own JavaScript hyphenation engine:

https://github.com/bramstein/Hypher

It is quite small and fast, and mostly aimed at integration with other libraries, unlike Hyphenator.js (which comes with a partial DOM library.) An example integration can be seen in the Treesaver library (https://github.com/bramstein/treesaver/tree/hyphenation) where it is used to hyphenate magazine columns.

I had a look at the problem and it seems to be related to the page transition animations (the amount of flicker seems corresponds to the animation steps.) I've created a ticket for this issue: https://github.com/Treesaver/treesaver/issues/issue/148

We'll fix it, thanks for reporting it.

That looks like a bug, I've created a ticket for this issue: https://github.com/Treesaver/treesaver/issues#issue/147

Thanks for catching and reporting it.

I would also highly recommend "Digital Typography" by Knuth. It contains a more detailed description of the algorithm as well as many interesting historical and technical chapters on TeX, MetaFont and computer typesetting in general.

It is the whole paragraph as far as I can tell (I haven't seen the internals, just the output.)

As far as I know, this is the only implementation in JavaScript. It might be possible to turn this into a jQuery plugin at some point, but there are probably quite a couple of bugfixes and changes needed to turn this from a tech demo into a drop-in plugin.

Internet Explorer actually has this through the (almost standardized) text-justify CSS property. It still doesn't do hyphenation, but Hyphenator.js (http://code.google.com/p/hyphenator/) fills that gap pretty nicely.

Performance isn't a good argument in my opinion. The algorithm isn't that expensive. The most expensive part right now is retrieving all the text metrics, but you would get that a lot cheaper in the browsers rendering engine.

I briefly looked at hacking it into Webkit, but then gave up due to a lack of time.

I have the same Chrome version, but I'm running Ubuntu. Perhaps it is a font issue. I will check it out later when I have access to a Mac. Thanks for reporting.

You probably could get it working, but the implementation isn't (yet) capable of dealing with arbitrary HTML. It only expects paragraphs and images. This is only a matter of implementation though, the core algorithm should be able to deal with most of the content found on websites.

I'm talking to Filipe Fortes of Treesaver about implementing it as part of his Treesaver technology (demo: http://treesaver.publicintegrity.org/smoke_screen) Perhaps a general implementation will roll out of that.

I honestly hadn't thought about printing it out yet. I had a quick look, and I think the issues you are seeing can probably be fixed. My initial plan was to render PDFs server-side, instead of relying on the browser's print mode.

Zooming is problematic, I haven't quite figured out a reliable way of fixing it yet. The problem is most apparent in Webkit based browsers, Firefox seems to handle it much better (though there are still some small problems--most can be fixed though.)

Yes, this is an application of dynamic programming. The computation is actually quite fast, most of the time is spent in retrieving the text metrics (put each word in a span, retrieve width and move on to the next word.) If that can somehow be alleviated it would become a feasible solution.

I agree with you that browsers should support this natively (Internet Explorer actually does.) If you are interested, I've written a bit on this subject in this Typophile thread: http://typophile.com/node/71247

That's probably a bug, what browser and operating system are you using?

If you're bothered by rivers and lack of hyphenation, check out a project I worked on a while ago, which implements the Knuth and Plass line breaking algorithm in JavaScript. Combined with Hyphenator.js, the results are nearly indistinguishable from TeX output.

http://www.bramstein.com/projects/typeset/flatland/

Earlier incarnations made it to HN before, but unlike the old version this renders in plain HTML instead of Canvas, so text can be selected, copied, etc.

Very interesting. Are you also planning to go after the eBook market?

On the technical side: are things like hyphenation and justification also on your todo/feature list? I've been thinking about putting my work on justification and hyphenation [1, 2] to good use, as the "rendering engine" of a HTML/JS based eBook reader. I haven't given much thought to page layout and scrolling, but I like the direction you are taking it for mobile and iPad users. I would personally prefer a different layout for reading on my desktop machine though (granted I prefer reading on my Kindle.)

[1] http://www.bramstein.com/projects/typeset/flatland/ [2] http://www.bramstein.com/projects/typeset/

I played with the same idea a couple of years ago and published a library for it: * http://www.bramstein.com/projects/jfun/ * http://www.bramstein.com/articles/pattern-matching.html * http://www.bramstein.com/articles/advanced-pattern-matching....

Although the implementation works great, I couldn't get past the (obvious) syntax issues and never actually used it in production code. It was an interesting experiment though, especially when combined with Sjoerd Visscher's algebraic data type library (http://w3future.com/weblog/stories/2008/06/16/adtinjs.xml).

You hit the nail on the head. The library is meant for applications that can not use CSS layout, because the algorithm they need is not possible in CSS, or because they are rendering to a context that does not have layout management such as Canvas or SVG. Think of projects like Mozilla Bespin (https://mozillalabs.com/bespin/) which uses Canvas for drawing its editor. Having standard layout algorithms available would be a great help there.

I was quite hesitant about making the jQuery plugin public because I was fearing reactions such as this. It was meant as a demo, and a nice way to test the layout managers. For a long time I had a message on the jQuery plugin page stating something along the lines of "please, please, consider using CSS before you use this plugin."

The nice thing about programming against a layout manager API is that you can easily write new algorithms while the (DOM) interface remains the same. It would be trivial to write a layout manager that does layout like Masonry. As another example, I'm currently working on a pack layout which can be used to pack small images into a larger one (e.g. CSS sprites,) and a layout manager that implements the CSS box layout module. I was also considering a text layout based on my TeX line breaking work (http://www.bramstein.com/projects/typeset/.)

Nice, I would be particularly interested in the conversion from PDF to HTML, and how you handle the word-spacing and line breaking. I've been doing some work on rendering TeX-like data in HTML (http://www.bramstein.com/projects/typeset/) and it would be great to see how you are solving similar problems (assuming you're willing to share these kind of details.)

Can anyone recommend a good online accounting application for small businesses in Europe? Most of the ones that are mentioned here are quite USA centric. Tax requirements in Europe are a bit different, which I guess also presents a problem as they differ from country to country.

I'm trying to find something that works with the Danish tax system (where I currently live), and the only one I have found so far is: http://www.e-conomic.com/, but it seems a bit heavyweight for my needs (small freelancing business.)

From what I read, the latter. Like you said, overdoing it quickly makes a text look bad, and it also ruins the (presumably) carefully created kerning tables that are supplied by the font. I assume you have read Hàn Thế Thành's paper on microtypographic extensions to TeX (http://www.pragma-ade.com/pdftex/thesis.pdf)?

I tried it in Photoshop which since CS2 (or so) has an implementation of the Knuth & Plass algorithm. I found it quite distracting myself. Granted, I was on the lookout for text jumping around and had hyphenation disabled.