Windows / font / text futures ...

classic Classic list List threaded Threaded
24 messages Options
Next » 12
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Windows / font / text futures ...

Hi guys,

        I've had the (mixed) pleasure of digging through the windows font
rendering in recent days; and I must say - I'm not thoroughly thrilled
with it =)

        Let me highlight a few of the problems. First we are using GDI for text
rendering, and this is ~obsolete. Several interesting problems  are
pointed out here:

http://blogs.msdn.com/b/text/archive/2009/04/15/introducing-the-directwrite-font-system.aspx

        Let me excerpt the rather charitable summary of what I've been falling
over:

        "For applications that need to work with fonts at a lower level,
         GDI does have some functions that can really be thought of as
         physical font APIs. Examples are GetFontData, GetGlyphIndices,
         and even ExtTextOut when used with the ETO_GLYPH_INDEX flag.
         Yet these “physical” font functions still use an HFONT to
         specify the font. This means font mapping still occurs under
         the hood, though since no text is specified there is no font
         fallback and the same HFONT always maps to the same physical
         font internally. While this model works, the lack of a true
         physical font object in GDI can make it harder for application
         developers that use these low-level functions to be sure of
         what is going on."

        Something of an under-statement there =) As far as I can see the
SimpleWinLayout - which we use sometimes (in place of the UniScribe layout)
and which has a number of fun comments in it like:

        // TODO: support surrogates in rewritten strings

        Essentially re-uses the non-obvious, not-really-physical-font
logic with built-in windows font fallback. In contrast the UniScribe
layout engine does not.

        The particular issue I'm looking at is that it appears really hard to
get genuine ABC widths (ie. underhang, black-width, and overhang
information) for those fall-back glyphs that are actually not in the
physical font - but that Windows (un)helpfully includes from elsewhere.
Asking for metrics via 'GetCharABCWidths' yields the 'default character's
metrics:

        "The ABC widths of the default character are used for characters
    outside the range of the currently selected font."

        Where by font, they mean physical font ignoring fallbacks it seems.

        After lots of nice drawings - thanks to Tor for his nice font rendering
foo, of this kind; notice the '$' character appears from another font,
with inaccurate ABC width - hence the overlap.

info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:540: DX:offset : 17:1 10:2 11:1 9:2 11:0 0:1
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:266: this=0CC6A0E8 32 old: {[43..48],[182..187],[286..291],[9832..9837],[9858..9863],[55356..55361]}
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:357: ABC widths: 0:1:14 3:3:3 1:8:1 0:16:0 1:8:2 0:22:2
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:431: OpenSymbol: Escapement=0 Orientation=0 Ascent=23 InternalLeading=0 Size=(87,29) totWidth=82
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:533: this=0CC6A0E8 now: {[32..37],[43..48],[182..187],[286..291],[9832..9837],[9858..9863],[55356..55361]}
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:176: Bitmap 7705322A: 82x33:
info:vcl.gdi.opengl:4212:3344:vcl/win/gdi/winlayout.cxx:205:      |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |       7X29  92X7   |            |
     |  719  |  3X0880X3  |       3X5   9108   |            |    3XX19         925
     | 80X3  |  3X0880X3  |      92X7   8029   |      818   |  92199219        53
     | 7XX29 |  3X0880X3  |      9108   5X3    |      818   |  7X5  7X3       829
     | 7XX29 |  3X0880X3  |      8029   3X5    |    80XXXX7 |  3X7  8019     927
     | 7XX29 |  3X1991X5  |      5X3   9208    |   5XXXXXXX3| 91X7  8008     53
     | 80X3  |  7X2992X7  | 92XXXXXXXXXXXXXX5  |  80X58187XX|791X7  9108    829
     | 80X3  |  803  508  | 92XXXXXXXXXXXXXX5  |  5X3 818 3X|391X7  8008   927
     | 91X5  |            |     9108   5X3     |  3X5 818   |  3X7  8019   53
     | 92X7  |            |     8029   3X7     |  3X3 818   |  7X5  7X3   829
     |  3X7  |            |     5X3   9208     |  7XX5818   |  92199219  927
     |  308  |            |     3X5   8019     |   5XXXX29  |    3XX19   53
     |  519  |            |    9208   7X29     |    92XXXXX5|           829   92XX19
     |  729  |            |  3XXXXXXXXXXXXXX3  |      8160XX|5         927   92199208
     |  84   |            |  3XXXXXXXXXXXXXX3  |      818 3X|29        53    5X5  7X3
     |  95   |            |    5X3   9208      |      818 80|19       829   92X7  8019
     |       |            |    3X5   8019      | 91X7 818 80|19      927    91X7  9108
     |       |            |   92X7   7X29      | 92X3 818 5X|29      53     91X7  9108
     | 92X7  |            |   9119   5X5       |  7XX58187XX|5      829     92X7  8019
     | 7XX29 |            |   7X29   3X7       |   3XXXXXXX3|      927       5X5  7X3
     | 92X7  |            |   5X3   9108       |    80XXX08 |      53        92199208
     |       |            |                    |      818   |     719         92XX19
     |       |            |                    |      818   |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
     |       |            |                    |            |
01234 0123456 012345678901 01234567890123456789 012345678901 01234567890123456789012345

        Anyhow - that's my problem #1. I'll carry on working away at it,
but it highlights the mess.

        The next issue I looked at is font anti-aliasing; and I notice we
previously use either DEFAULT_QUALITY or NONANTIALIASED_QUALITY fonts
cf. vcl/win/gdi/salfont.cxx

        The documentation:

        https://msdn.microsoft.com/en-us/library/ms901140.aspx

        suggests that DEFAULT_QUALITY can do odd and exciting things to font
metrics =) ie. "Appearance of the font does not matter." vs.
CLEARTYPE_COMPAT_QUALITY which "Enables ClearType® text for the font
using compatible widths. A compatible width produces text that has the
same spacing as non-ClearType text."

        Which is also somewhat concerning. I fear that we have perhaps encoded
more platform specific font rendering information into our text than expected.

        Anyhow - what to do ?

        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.

        While we could switch to DirectWrite on windows, which may solve some
of our problems; this will be 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.

        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 =)

        Thoughts appreciated,

        ATB,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

Hi Michael,

you write:
> 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 - as long as so much low-level layouting is still
happening in Writer (dx arrays, kashida filling etc).

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

> 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. 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...

> 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? 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. ;)

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

Hi Thorsten and Michael,

Am 04.03.2016 um 00:43 schrieb Thorsten Behrens:
Hi Michael,

you write:
	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 - as long as so much low-level layouting is still
happening in Writer (dx arrays, kashida filling etc).

On the danger no-one wants to hear it :-) - Primitives. If all text rendering would use them, all text rendering could be handled in system-specific renderer implementations.
Similar for layout, I have already 'isolated' text layout stuff needed for primitive text handling in a class called 'TextLayouterDevice' that has a small number of interface method and uses OutputDevice in the background. That class can be implemented system-specific or based on an external tooling dood on all systems.
Rendering can also be system-specific or use such unified external tooling.
Think about something mixed like: No longer layout each char of a word, but the whole word. On rendering, check how long would it be painted, adapt with width zooming slightly to get the same width. When layout of single word width is done system-independent that might give good results.
This would require to go forward with converting all EditView visualizations to use primitives, though.
Just my 2ct :-)


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

Incidentally - why that?

	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. 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...

Office is mostly a text tool, so from my POV there is no way around using the *best* font rendering on every system. Having (well-optimized) ClearType on a system and not using it in an office application will not be accepted, esp. not when telling 'but that way it is better on a system you do not use'.


	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? 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. ;)

Cheers,

-- Thorsten


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

 
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Michael Meeks-5
On Thu, 2016-03-03 at 13:44 +0000, Michael Meeks wrote:
> Hi guys,

> Anyhow - what to do ?

> While we could switch to DirectWrite on windows, which may
> solve some
> of our problems; this will be in itself disruptive.
>
> So - I believe that we should switch to using harfbuzz and
> freetype consistently everywhere.

So, like chromium and firefox etc do, I'm very much in favor of using
our harfbuzz text shaper on all platforms to unify that complexity and
have equal layout problems on different platforms :-).

If you look at the vcl/unx/generic/glyphs/gcach_layout.cxx getFontFuncs
thing (and the firefox equivalents) then harfbuzz has mechanisms to
allow us to integrate with CGFontRefs on MacOSX, FT_Face under Linux
and presumably (?) hook into our existing Windows stuff to swap out the
two windows shaping engines and keep (one of) the existing render paths
?

So layout wise I'm comfortable with harfbuzz everywhere. Window text
rendering is as clear as mud to me though. Right now under Linux (and
similar platforms) at the moment we are using cairo to render glyphs
(from freetype faces) rather that using freetype to do that directly.
And under Linux we render visually differently, albeit with the same
positioning, depending on what features of the underlying freetype are
enabled or disabled and all mediated by what desktop-wide font options
are set. My experiences there suggests that if your text doesn't look
like everyone else's on that platform there's constant moaning and
complaining.

On Windows, peer apps like firefox and chromium etc seem to follow the
pattern of eventually rendering their harfbuzz layouted text with the
DirectWrite apis, whether directly, or through skia or through a forked
cairo, that *seems* be where things end up. So that seems to be a
fairly well trodden route.

C.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

Caolan McNamara wrote:
> On Windows, peer apps like firefox and chromium etc seem to follow
> the pattern of eventually rendering their harfbuzz layouted text
> with the DirectWrite apis, whether directly, or through skia or
> through a forked cairo, that *seems* be where things end up. So that
> seems to be a fairly well trodden route.
>
Ah, that would address most of my concerns. Shame wrt. the forked
cairo though...

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Thorsten Behrens
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.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks-5 Michael Meeks-5
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Armin Le Grand-2
Hi Armin,

        Interesting mail; please do CC me on replies =)

On Fri, 2016-03-04 at 11:25 +0100, Armin Le Grand wrote:
> On the danger no-one wants to hear it :-) - Primitives. If all text
> rendering would use them, all text rendering could be handled in
> system-specific renderer implementations.

        If we could cache de-compositions of primitives instead of constantly
re-generating them, I think it'd be great to have a list of glyphs and
positions for a given string - continually re-shaping the same text as
we measure, render, etc. as we currently do seems (to me) particularly
pointless and inefficient - particularly when you have some really
complex text shaper.

> Similar for layout, I have already 'isolated' text layout stuff needed
> for primitive text handling in a class called 'TextLayouterDevice'
> that has a small number of interface method and uses OutputDevice in
> the background. That class can be implemented system-specific or based
> on an external tooling dood on all systems.

        Sure - abstraction is nice; but not having to abstract - by sharing
more of the rendering infrastructure is even more ideal IMHO =)

> Office is mostly a text tool, so from my POV there is no way around
> using the *best* font rendering on every system. Having
> (well-optimized) ClearType on a system and not using it in an office
> application will not be accepted, esp. not when telling 'but that way
> it is better on a system you do not use'.

        Hmm; I'm not so convinced that with today's higher-dpi screens and
better rendering / hinting algorithms there is so much in it. ClearType
is rather (oddly) situation specific too - mostly good for mostly black
text on a mostly white background ;-) Amusingly - I wanted to demo that
so I fired up Office 2016 on Windows 7:

        https://people.gnome.org/~michael/office2016.png

        Not knowingly configured Office at all since I installed it. Notice
that this is indeed a ClearType setup - cf. the Calibri preview in the
widget. If I was a betting man, this would be down to the horrible
complaints that people no doubt make - since copy/pasting eg. formulae
between word & excel these days results in a bitmap - which used to be
complete with false colour but ... no time for a more systematic test.

        ATB,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

Hi Michael,

Am 07.03.2016 um 15:29 schrieb Michael Meeks:

> Hi Armin,
>
> Interesting mail; please do CC me on replies =)
>
> On Fri, 2016-03-04 at 11:25 +0100, Armin Le Grand wrote:
>> On the danger no-one wants to hear it :-) - Primitives. If all text
>> rendering would use them, all text rendering could be handled in
>> system-specific renderer implementations.
> If we could cache de-compositions of primitives instead of constantly
> re-generating them, I think it'd be great to have a list of glyphs and
> positions for a given string - continually re-shaping the same text as
> we measure, render, etc. as we currently do seems (to me) particularly
> pointless and inefficient - particularly when you have some really
> complex text shaper.

AFAIK Text primitives are currently not decomposed at all, they are all
directly handled in the VCL-Renderer. If they would be decomposed, they
would be fully buffered, that is the default for primitives.
An external renderer would also handle them directly, so also no need to
decompose. If needed, results can be buffered at the primitive itself.
All possibilities are given.

>
>> Similar for layout, I have already 'isolated' text layout stuff needed
>> for primitive text handling in a class called 'TextLayouterDevice'
>> that has a small number of interface method and uses OutputDevice in
>> the background. That class can be implemented system-specific or based
>> on an external tooling dood on all systems.
> Sure - abstraction is nice; but not having to abstract - by sharing
> more of the rendering infrastructure is even more ideal IMHO =)

Abstraction is of course a question of weighting. This abstraction is
for 'hiding' FontLayout from OutputDevice - a separation that is missing
from the beginning. It is just hiding stuff, not even virtual function
calls involved.

>
>> Office is mostly a text tool, so from my POV there is no way around
>> using the *best* font rendering on every system. Having
>> (well-optimized) ClearType on a system and not using it in an office
>> application will not be accepted, esp. not when telling 'but that way
>> it is better on a system you do not use'.
> Hmm; I'm not so convinced that with today's higher-dpi screens and
> better rendering / hinting algorithms there is so much in it. ClearType
> is rather (oddly) situation specific too - mostly good for mostly black
> text on a mostly white background ;-) Amusingly - I wanted to demo that
> so I fired up Office 2016 on Windows 7:
>
> https://people.gnome.org/~michael/office2016.png
>
> Not knowingly configured Office at all since I installed it. Notice
> that this is indeed a ClearType setup - cf. the Calibri preview in the
> widget. If I was a betting man, this would be down to the horrible
> complaints that people no doubt make - since copy/pasting eg. formulae
> between word & excel these days results in a bitmap - which used to be
> complete with false colour but ... no time for a more systematic test.

Luckily indeed this gets less important with growing resolution. Still -
I am convinced that it is expected that we use the best FontRendering on
each system.

>
> ATB,
>
> Michael.
>

--
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Michael Meeks-5
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

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Noel Grandin-2 Noel Grandin-2
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

On 7 March 2016 at 18:22, Thorsten Behrens <[hidden email]> wrote:
> 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).
>

While this is an issue for actual math on potentially very large or
very small numbers (which is, I assume, why calc is careful with it),
and an issue for games with large 3D worlds, it can hardly be an issue
for the magnitudes of numbers we deal with in the font rendering
paths.

> C.f. chart2.
>
Even chart2's world-geometry is relatively small in the grander scale
of things. And issues there have far less impact than the glaring font
rendering issues elsewhere.

> 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.

Surely that orthogonal is to the font-rendering down in the VCL layer.
We can fix the one without making the other any worse.
I would assume that attempting to fix both at the same time would be a
boiling-the-ocean type problem, much better to work on them
independently.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Khaled Hosny Khaled Hosny
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Caolán McNamara
CONTENTS DELETED
The author has deleted this message.
Khaled Hosny Khaled Hosny
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Michael Meeks-5
CONTENTS DELETED
The author has deleted this message.
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Michael Meeks-5
On Mon, Mar 7, 2016 at 8:04 AM, Michael Meeks
<[hidden email]> wrote:
>
>>  - 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;

Not quite. Dx array associate width to characters, not glyphs... a
glyph can represent multiple characters and conversely a given
character may be represented by multiple glyphs...
so DX array is fundamentally broken when used in a non read-only fashion.

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Thorsten Behrens
On Mon, Mar 7, 2016 at 10:22 AM, Thorsten Behrens
<[hidden email]> wrote:
> 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,

My conclusion was that writer trying to mess with the layout directly
is an heresy
vcl should be doing the layout and writer and other may want to query
information about it (like the position of things for caret handling
purpose etc.. but should _never_ try to 'tweak' the positoing of
individual glyphs, even less via positioning individual character (to
the the n-n relation with glyphes)

I do think that the first step is to push the layouting tweaks/hacks
out of writer and into vcl itself,
make dxarray read-only,
and _then_ we are free to implement/improve stuff in vcl as desired.

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Chris Sherlock Chris Sherlock
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Khaled Hosny
On 8 Mar 2016, at 5:38 AM, Khaled Hosny <[hidden email]> wrote:

>
> On Mon, Mar 07, 2016 at 02:04:41PM +0000, Michael Meeks wrote:
>> 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:
>>
>> Hmm; the dx array as I understand it is just a simplified form of glyph
>> widths;
>
> The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I
> have been told), you basically convert individual glyph advance widths
> to absolute (from start of line IIRC) “character widths”; the x position
> after the Nth character from the start of line, which is not so horrible
> so far, except that when drawing the glyphs you take those absolute
> character widths and try to convert them back to glyph
> positions (that you already had but thrown away, remember) with all
> sorts of bugs and rounding errors left and right (and hundreds of hacks
> to work around the rounding errors).

I have to agree with this assessment. The comment in the code for ApplyDXArray (I
think was this from you Khaled? I added some info to it) is interesting:

// To justify a text string, Writer calls OutputDevice::GetTextArray()
// to get an array that maps input characters (not glyphs) to their absolute
// position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an
// array of character widths that it converts to absolute positions.

// Writer would then apply justification adjustments to that array of absolute
// character positions and return to OutputDevice, which eventually calls
// ApplyDXArray(), which needs to extract the individual adjustments for each
// character to apply it to corresponding glyphs, and since that information is
// already lost it tries to do some heuristics to guess it again. Those
// heuristics often fail, and have always been a source of all sorts of weird
// text layout bugs, and instead of fixing the broken design a hack after hack
// have been applied on top of it, making it a complete mess that nobody
// understands.

http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/sallayout.cxx#901 

Regardless of who wrote that comment, this is pretty insane.


Chris
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Chris Sherlock Chris Sherlock
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Norbert Thiebaud
On 8 Mar 2016, at 8:39 AM, Norbert Thiebaud <[hidden email]> wrote:

>
> On Mon, Mar 7, 2016 at 10:22 AM, Thorsten Behrens
> <[hidden email]> wrote:
>> 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,
>
> My conclusion was that writer trying to mess with the layout directly
> is an heresy
> vcl should be doing the layout and writer and other may want to query
> information about it (like the position of things for caret handling
> purpose etc.. but should _never_ try to 'tweak' the positoing of
> individual glyphs, even less via positioning individual character (to
> the the n-n relation with glyphes)
>
> I do think that the first step is to push the layouting tweaks/hacks
> out of writer and into vcl itself,
> make dxarray read-only,
> and _then_ we are free to implement/improve stuff in vcl as desired.
>
> Norbert
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

Do you have any code pointers where writer modifies the layout?

Chris
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Khaled Hosny Khaled Hosny
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Chris Sherlock
CONTENTS DELETED
The author has deleted this message.
Chris Sherlock Chris Sherlock
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

Not a criticism, when I was trying to follow the code I was feeling the same way! Your comment was very helpful, and I went from frustrated to amused :-)

Chris

Sent from my iPhone

> On 8 Mar 2016, at 10:35 AM, Khaled Hosny <[hidden email]> wrote:
>
>> On Tue, Mar 08, 2016 at 10:18:47AM +1100, Chris Sherlock wrote:
>>> On 8 Mar 2016, at 5:38 AM, Khaled Hosny <[hidden email]> wrote:
>>>
>>>> On Mon, Mar 07, 2016 at 02:04:41PM +0000, Michael Meeks wrote:
>>>> 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:
>>>>
>>>>    Hmm; the dx array as I understand it is just a simplified form of glyph
>>>> widths;
>>>
>>> The DX stuff is pure madness (it is inspired by a Windows 3.1 API as I
>>> have been told), you basically convert individual glyph advance widths
>>> to absolute (from start of line IIRC) “character widths”; the x position
>>> after the Nth character from the start of line, which is not so horrible
>>> so far, except that when drawing the glyphs you take those absolute
>>> character widths and try to convert them back to glyph
>>> positions (that you already had but thrown away, remember) with all
>>> sorts of bugs and rounding errors left and right (and hundreds of hacks
>>> to work around the rounding errors).
>>
>> I have to agree with this assessment. The comment in the code for ApplyDXArray (I
>> think was this from you Khaled? I added some info to it) is interesting:
>>
>> // To justify a text string, Writer calls OutputDevice::GetTextArray()
>> // to get an array that maps input characters (not glyphs) to their absolute
>> // position, GetTextArray() in turn calls SalLayout::FillDXArray() to get an
>> // array of character widths that it converts to absolute positions.
>>
>> // Writer would then apply justification adjustments to that array of absolute
>> // character positions and return to OutputDevice, which eventually calls
>> // ApplyDXArray(), which needs to extract the individual adjustments for each
>> // character to apply it to corresponding glyphs, and since that information is
>> // already lost it tries to do some heuristics to guess it again. Those
>> // heuristics often fail, and have always been a source of all sorts of weird
>> // text layout bugs, and instead of fixing the broken design a hack after hack
>> // have been applied on top of it, making it a complete mess that nobody
>> // understands.
>
> That sounds like a frustrated me.
>
> Regards,
> Khaled
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Chris Sherlock
On Mon, Mar 7, 2016 at 5:20 PM, Chris Sherlock
<[hidden email]> wrote:
>
> Do you have any code pointers where writer modifies the layout?

sw/source/core/txtnode/fntcache.cxx

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Windows / font / text futures ...

In reply to this post by Noel Grandin-2
On 03/07/2016 06:08 PM, Noel Grandin wrote:

> On 7 March 2016 at 18:22, Thorsten Behrens <[hidden email]> wrote:
>> 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).
>>
>
> While this is an issue for actual math on potentially very large or
> very small numbers (which is, I assume, why calc is careful with it),
> and an issue for games with large 3D worlds, it can hardly be an issue
> for the magnitudes of numbers we deal with in the font rendering
> paths.

Are you sure?  TeX for example is very careful with its calculations to
ensure consistent layout across implementations, regardless of available
floating-point functionality.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12