On Fri, Mar 04, 2016 at 12:04:38PM +0000, Caolán McNamara wrote:
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
?
HarfBuzz has callbacks to get some of the stuff it wants from fonts,
char to glyph mapping, etc. This can be hocked into FreeType, Core Text,
DirectWrite or even GDI APIs, so you can keep loading/rendering fonts
with platform “native” API and use HarfBuzz for shaping and positioning.
Recent versions of HarfBuzz even has its internal font functions and you
just give it a memory blob representing the font file and it will read
the font tables on its own (Chrome has recently switched to using that,
for example) this means even more consistency since, for example,
FreeType can return different metrics in different versions.
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.
Not using the “native” font rendering APIs is indeed more controversial
as it means you don’t respect system wide font rendering/hinting etc.
options which will be very visible especially on Windows since
FreeType’s support for ClearType hinting is rather incomplete. Shaping
difference on the other hand is more subtle, and HarfBuzz tries to
maintain computability with MS implementation (this does not help with
Mac OS X implementation, but usually differences there are considered
bugs in Apple implementation).
Another problem with using FreeType is it can be tricky to integrate it
with platform font searching APIs, there is no direct way, for example,
to create an FT_Face from a CTFont as FreeType wants either a filename
and face index (for font collections) or the full font memory blob and
CTFont has no API that gives this. Even if it has, you will end up
loading the font twice in memory, though this might not be such a big
issue.
Regards,
Khaled
Context
- Re: Windows / font / text futures ... (continued)
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.