Windows / font / text futures ...

[Armin Le Grand]

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
> LibreOffice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20160304/905389e9/attachment.html>