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)