Windows / font / text futures ...

[Thorsten Behrens]

Michael Meeks wrote:
> 	I missed your mail; please do maintain the CC if you want a prompt
> reply =)
> 
Setting Reply-To would help me to remember that next time. ;)

> 	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.
> 
Nah. The problem is that boxes-for-glyphs in a linear array are the
wrong abstraction (it gets quite funky for ltr-rtl and other complex
text layout mixes), and having them integer-only

a) gives you AA-bleed into the next glyph's box, and/or
b) ugly whitespace jumpiness for smaller font sizes (check a line of
   WaWaWaWaW with an 8pt font...)

The way it's implemented (Writer does the layout, passes DX array
down) also *really* kills the nicer font features like alternate
glyphs.

> > > 	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 ;-)
> 
Nah - I meant, why is that in itself disruptive? ;)

> > > 	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 ?
> 
The 'develop once, run everywhere' promise. ;)

> > 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.
>
You're getting different rounding even depending on the flags your OS
(or driver that happens to be in your process) sets. Seriously - I'm
too lazy to dig out references, but consider floating point math to be
inherently non-similar from one box to the next, *unless* you're
extremely careful across the entire calculation chain (which is the
case in Calc).

> 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.
>
C.f. chart2.

> 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 ? =)
> 
Unless you convert from register to mem and back for every calculation
step, you've no real portable control over intermediate values. And
the precision argument is moot, e.g. when facing catastrophic
cancellation.

> 	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.
> 
Ah well. That's really a re-hash of an old discussion - perhaps
something then for a non-email exchange of ideas. ;)

Anyway - as I wrote to Caolan, if there's a Uniscribe/DirectWrite code
path in your proposed solution, my concerns are moot (the above issues
will remain, but it's no worse than today).

> >  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.
> 
I'm afraid we're in for that regardless. Norbert, Khaled, Tor IIRC & a
number of other hackers all came to the conclusion that the vcl font
API / the way Writer is doing layout is in serious need for rework,
before any amount of font layouting/rendering happiness can be
attained.

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20160307/b593658a/attachment.sig>