Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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

Attachment: signature.asc
Description: Digital signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.