Windows / font / text futures ...

[Martin Hosken]

I'm replying from the digest so the thread may mess up.

So much good stuff to agree with.

I think it's clear that there is a difference between the process of getting glyphs on a screen (rendering) and working out which glyphs should go where at the run level (shaping) and at the paragraph level (layout). They each have their own issues.

On rendering. I don't think it matters too much which approach one takes to get glyphs on the screen. Freetype is nice and cross platform but may not be the quickest library on the shelf. Local rendering is costly to maintain but can give you various goodies. I'm no expert here and I get very confused when I look at firefox. But then I am thinking that all applications in this space are carrying a fair amount of legacy baggage.

Onto something I think I know more about: shaping.

As one of the poor fools who has tried to create a SalLayout subclass (for Graphite), I agree that the current model is very broken and just about holds together. The layer violations are embarrassing and confusion abounds. I agree that we should come up with a good API for vcl and stop sw digging around in the mud.

Personally, I think kashida insertion is the job of something like harfbuzz. In fact justification is something the font wants to get involved in (do we expand a ligature here? use glyph ductility here? limit the amount of inter base glyph here and balance it against what is given to the space, and so on and so fifth). Justification is too complicated to be done by the application, it requires too much script knowledge. Better to have the application negotiate with the font to allocate an overall expansion/contraction for a run and let the shaper do the heavy lifting from there.

harfbuzz is nice in that it provides a plugin mechanism, in effect, to allow other shapers to get involved, but provides a single interface for the application. This is good. I would be happy for harfbuzz to win the day and have Graphite accessed under that, so long as we do it right ;)

As to floating point. Yes there are system differences, but they are so minor in this game as to be completely ignorable. I took care when doing my collision avoidance stuff, that does lots of maths, with floats rather than doubles, and found that once I got the thing overall correct, the need for rounding management was much less than I thought and that once you take an int(aFloat) the differences are gone between systems. While floats are used for shaping, it's more to save the effort of fixed point integer maths which is fiddly and with a modern CPU, much slower than floating point. If rounding were an issue, we would switch to doubles in a flash. No such need has been found.

The need for good fidelity in shaping across platforms is about line breaking, primarily and the results are generally good, certainly much better than native shaping, which almost guarantees you are going to be frustrated. I think we have to go with consistent shaping across all platforms if we want documents to have any hope of laying out the same across different platforms.

When it comes to layout, there are lots of fun things that can be done. The trendy direction at the moment is to implement the TeX paragraph layout algorithm and android has minikin which we could probably leverage to help there.

Why do I think we need to see change? Well, when it takes 20+ reshapings of a paragraph to get it onto the screen (as someone measured), one has to ask whether something might be wrong. Yes shaping is cheap, at least for simple Latin, but these things add up, and once you get onto Indic or Arabic shaping, they multiply up quite a long way. In the modern battery saving world, it must be possible to save doing quite so much redundant work?

Yes all this will take quite a lot of work to get right. The question is whether we have the will to make it right.

Thanks for listening!

Yours,
Martin