Re: Windows / font / text futures ...

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