[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-fontconfig
Subject:    Re: [Fontconfig] Revisiting FcFontMatch and FcFontSort
From:       Matthias Clasen <matthias.clasen () gmail ! com>
Date:       2021-02-23 23:19:37
Message-ID: CAFwd_vCML=4R_ux7nd-4t+oTgEcrqee=wxh0ZNtX3V+YCPNnQg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tue, Feb 23, 2021 at 1:00 AM Werner LEMBERG <wl@gnu.org> wrote:

>
>
> Can you give an example?


We were talking about examples like combining a base glyph with a
rare mark. If the mark is missing in the font, you have different options
what to do - look for a precomposed glyph, find a suitable variant of the
mark, or go for all fallback font. Maybe Behdad has concrete examples.

Again, please give an example.  It seems to me that you are actually
> thinking of improving Pango, not fontconfig per se.  I only wonder
> whether the approach you are envisioning has drawbacks to applications
> that are not using Pango.
>

Sure, this is about improving font rendering. The high-level parts of it are
implemented in Pango. But it needs suitable font enumeration apis, which
is where fontconfig comes in.

I don't object to using harfbuzz – this is what FreeType is actually
> using for getting glyph coverage for its auto-hinter.  However,
> harfbuzz has some quite massive dependencies that might not be wanted
> by the user.
>

Great, this might be a more or less solved problem , then.

From the Pango perspective, a harfbuzz dependency is not such a big
deal - we use harfbuzz anyway. And using harfbuzz directly, instead of
via freetype, might have other advantages for fontconfig.

Matthias

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Feb 23, 2021 at 1:00 AM Werner LEMBERG &lt;<a \
href="mailto:wl@gnu.org">wl@gnu.org</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br> <br>
Can you give an example?</blockquote><div><br></div><div>We were talking about \
examples like combining a base glyph with a</div><div>rare mark. If the mark is \
missing in the font, you have different options</div><div>what to do - look for a \
precomposed glyph, find a suitable variant of the</div><div>mark, or go for all \
fallback font. Maybe Behdad has concrete \
examples.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Again, please \
give an example.   It seems to me that you are actually<br> thinking of improving \
Pango, not fontconfig per se.   I only wonder<br> whether the approach you are \
envisioning has drawbacks to applications<br> that are not using \
Pango.<br></blockquote><div><br></div><div>Sure, this is about improving font \
rendering. The high-level parts of it are</div><div>implemented in Pango. But it \
needs suitable font enumeration apis, which</div><div>is where fontconfig comes \
in.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I don&#39;t object to \
using harfbuzz – this is what FreeType is actually<br> using for getting glyph \
coverage for its auto-hinter.   However,<br> harfbuzz has some quite massive \
dependencies that might not be wanted<br> by the \
user.<br></blockquote><div><br></div><div>Great, this might be a more or less solved \
problem , then.</div><div><br></div><div>From the Pango perspective, a harfbuzz \
dependency is not such a big</div><div>deal - we use harfbuzz anyway. And using \
harfbuzz directly, instead of</div><div>via freetype, might have other advantages for \
fontconfig.</div><div><br></div><div>Matthias<br></div></div></div>



_______________________________________________
Fontconfig mailing list
Fontconfig@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/fontconfig


[prev in list] [next in list] [prev in thread] [next in thread]