Re: Windows / font / text futures ...

Hi Thorsten,

        I missed your mail; please do maintain the CC if you want a prompt
reply =)

On Fri, 2016-03-04 at 00:43 +0100, Thorsten Behrens wrote:
> >     Having looked at this heap; and worse - the two different heaps for
> > Windows text rendering, and also the big pile of strange cross-platform
> > issues with stacking diacritics, emojis etc. I'm pretty convinced that
> > we cannot do a good job of consistent text shaping and/or rendering
> > cross-platform while using the Windows font rendering infrastructure.
>  
> Yeah, I suppose. But that alone won't fix the kind of issues you show
> in your ascii art

        Sure; the ascii art is the tip of one iceberg ie. not being able to get
accurate ABC widths and/or metrics for what we're rendering, and hence
having overlapping glyphs and broken selections in many corner-cases.

>  - as long as so much low-level layouting is still
> happening in Writer (dx arrays, kashida filling etc).

        Hmm; the dx array as I understand it is just a simplified form of glyph
widths; we could use rectangles for those instead of non-linear
selection handling to be more cute ? ultimately an intimate view of text
seems quite inevitable to me in writer - but I'm no writer expert.

> >     While we could switch to DirectWrite on windows, which may solve some
> > of our problems; this will be in itself disruptive.
>  
> Incidentally - why that?

        Switching to DirectWrite ? its a better API cf. the link I gave, it is
part of the Universal Windows Platform (UWP) - but note that using
freetype/cairo for rendering is also UWP compatible ;-)

> >     So - I believe that we should switch to using harfbuzz and freetype
> > consistently everywhere. This would have the huge benefit of precise
> > cross-platform font rendering and metric fidelity, give us a font and
> > shaping stack that is fully introspectable, drop some legacy Windows API
> > usage, and allow all development work and fixing on all platforms to
> > share the same underlying code.
> I think that promise cannot be kept. 

        Curious - which promise ? the font rendering and metric fidelity across
platforms ?

> Let's evaluate the merit of switching to some truly great floss libraries
> based on other aspects - you're not even getting consistent floating point
> math between different CPUs, let alone different operating systems...

        I would hope that the OS' impact on floating point math is rather
small; I'm also extremely curious about the inconsistent floating point
math problems people posit here. IEE754 is pretty helpful - and when it
comes to rendering rather small glyphs - and accumulating their metrics
via a few adds & subtracts across any feasible page size - it seems
incredible to me that this would cause issues. For sure depending on how
the compiler handles the FPU registers we could have only 23 bits of
fraction instead of the 32 we'd expect to retain if left on the GPU -
but really ... 2^23 is reasonably large for rendering a 40 pixel square
glyph surely ? =)

        Then again - perhaps I'm completely mistaken.

        Other people seem to be able to do this: one example might be the Acid
3 canvas rendering test: http://acid3.acidtests.org/ cf.
https://en.wikipedia.org/wiki/Acid3 - which (I hope) runs on your
browser - and includes both text (with shadow), and a pixel-by-pixel
compatibility requirement; at least it looks like text.

        Now of course for complex text, it's not just rendering simple, US
ASCII strings - it's a font fallback / shaping nightmare =) but if the
glyph rendering can work cross-platform, I'm optimistic the shaping can
too. This underlies my confidence that we can do reliable layout unit
test across platforms - assuming we can nail down shaping & font code.

> >     There will of course also be some corner-cases where we may simply not
> > be able to replicate the tangled old layout behaviour - which is
> > (anyway) inconsistent across platforms - but - I think this is a one-off
> > risk that is well worth taking to get us to a fully consistent, Free
> > Software rendering stack. It is interesting that Microsoft also used freetype
> > for their Office / Mac rendering in the recent past =)
>  
> Oh - got some reference for that ?

        Sure; of course quite possibly I was gotcha'd by some photo-shopping
weenie =)

http://tech.slashdot.org/story/10/08/30/1419227/freetype-lands-in-microsoft-office

>  Since I guess for most complaints about layouting problems I hear about,
> it's the different between MSO and LibreOffice, rather than between LibreOffice
> on different platforms. ;)

        Sure; but unfortunately, the stack is such a mess now that fixing this
(really non-intuitive) code and/or adding features multiple times and
testing across <N> platforms is really a very long way from ideal.

        ATB,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot